freenode/#clasp - IRC Chatlog
Search
19:12:46
drmeister
I'm thinking building work-flow graphs in the FEP demo is a little weird because I have two kinds of nodes: "processing" nodes and "file" nodes and the graph is constructed so it goes processing-node -> file-node -> processing-node -> file-node and so on.
19:13:26
drmeister
Perhaps I should be mimicking Cleavir more closely and have processing nodes have successors and predecessors rather than just inputs and outputs.
19:15:09
drmeister
I'm wondering if it would be easier to specify the graph if I treated it like a control flow graph. There is a flow of control from one job to the next. What do you think?
19:16:06
drmeister
Here are the "file" nodes: https://github.com/cando-developers/cando/blob/dev/src/lisp/fep/ti.lisp#L523
19:16:53
drmeister
We are about to embark on implementing a second approach to carrying out FEP calculations. One that appears to be significantly better than the one I currently have.
19:17:18
drmeister
We can use the same graph structure - or we can improve it to make it easier to build the graph.
19:17:43
drmeister
It would be good for us to come up with a clear and simple way to build the graphs programmatically.
19:18:11
drmeister
I've been looking back at my old code - and I can figure it out - but I wonder if we could do better.
19:18:38
drmeister
The code looks like this: https://github.com/cando-developers/cando/blob/dev/src/lisp/fep/script.lisp#L185
19:19:33
drmeister
We make instances of job nodes and specify inputs that are generated as outputs from a previous step and specifying new outputs that are instance of file nodes.
19:27:09
drmeister
Think about how we might make this more concise. What we have feels to me to be a bit low-level and verbose.
19:28:29
drmeister
This graph approach to setting up the calculations and then specifying generic functions that generate a concrete directory structure with a makefile, scripts, input files is powerful.
19:34:35
drmeister
Maybe some make-<job-node> and make-<file-node> functions with defaults will clean things up.
19:36:44
drmeister
Bike: We catch signal 11 (segfault) now I see. Is there anything I can do after that other than whatever I can and then restart?
19:37:45
Bike
in my branch i'm doing fancier stuff... we could isolate the faulty instruction from the siginfo_t
19:37:56
Bike
i forget if you can look at the stack or not. if not we could probably pull that off too
19:41:54
drmeister
How did you end up implementing this? Signal handlers and C++ exception handling incompatibilities being what they are.
20:10:00
Bike
as for exception handling, just doing it seems to work, mostly, but i haven't worked out the kniks