On Wed, 2007-12-19 at 02:45 +0100, Daniel Fischer wrote:
I believe instead of return $ foldr... you should use evalStateT $ foldM (flip buildTree) Map.empty entries
This seems to have done it: evalStateT $ (foldM (flip buildTree) Map.empty entries)) Map.empty (the second argument to evalStateT being the initial state).
where does 'dir' below come from? should the pattern match not be
Sorry for that, 'dir' should be 'entry'.
I believe here you want something like modify (Map.adjust (Map.insert pid procInfo) pPid) but perhaps you also want to insert pid into the PsMap?
Almost that. procInfo is (PsInfo procData procChildren), procChildren being a map where pid should be added. pid is inserted in the PsMap in the call to insertProc.
return tree else do tree' <- insert pPid in the process tree modify (new psMap with pid appended pPid's children)
Insert pPid in the PsMap before that?
Well, the "insert pPid in the process tree" part should actually be a recursive call to insertInTree, so that should be taken care of.
I think, you can treat both cases at once using Map.insertWith.
Thanks, I'll have a look at it.
I'm not sure what the design is, what's the role of PsMap and the PsTree, respectively?
The idea is to have a map (the PsMap) where pids are keys and the process information are values. The process information includes a map that has a key for each child of the process, which should point to the other entries of the map. The PsTree then would just point to the entry in the PsMap that corresponds to pid 1, which is the root of the tree. Now thinking about it, I guess there's no need for PsTree to be a map... Thanks a lot for your help, Andre