17:35:16Bikeand using a generic function instead of subclassp is indeed faster
23:05:06Bikeit occured to me we could eliminate the special fastgf compiler but putting in a special fastgf operator instead. not that i want to do that right now
23:05:16Biketoo bad making the compiler better isn't as easy as making clos go faster
23:21:55drmeisterYou mean a special operator to generate fastgf dispatchers?
23:25:52Bikeyeah, so the dispatchy part can still be specially done like now, but the outcomes could be arbitrary code
23:32:08drmeisterDoes it generate an instruction like an enter-instruction?
23:37:12Bikeno, it would just do the dispatch part
23:42:15Bikeso the call history is made up of (selector . code), and instead of codegen-dispatcher it's (compile nil `(lambda (&va-rest args) (discriminate ,call-history))) or so
2:07:14stassatsis your LOOP crippled at that point?
2:07:14drmeisterIt creates a widget, displays the widget and then launches a thread that has a jupyter notebook cell dynamic environment and can update widgets.
2:15:08drmeisterWell, the key point is I can set up complex dashboard of jupyter widgets and have them updated asynchronously from a thread that watches a bunch of processes, directories and files to monitor their progress.
2:15:23drmeisterWhether this is a good idea - I'm not so sure.
2:15:44drmeisterI just didn't like the idea of evaluating a jupyter notebook cell and having it go off into la la land for hours and days.
2:16:30drmeisterI could put a button into it that would exit the evaluation.
2:16:52drmeisterI'm still mulling over approaches of how to develop an "application" in a Jupyter notebook.