freenode/#clasp - IRC Chatlog
Search
18:07:06
drmeister
kpoeck: Hi - I couldn't reproduce the crash that you saw - did the problem go away?
18:41:11
Bike
ok so the problem _might_ be that it's hitting a #., and the *package* isn't set to read it right... i'm really not sure
18:52:22
Bike
drmeister: also- the function-info contains a docstring, right? I tried it out and i can't seem to retrieve it. is that something else the merge broke?
18:53:00
drmeister
The function-info contains an integer index into the root vector for the module that contains a docstring.
18:55:02
attila_lendvai
Bike: would you like ./waf -f some-feature to work so that ./waf configure stores it, and subsequent waf invocations will use the value stored at configure?
18:57:30
attila_lendvai
hrm... it seems useful when people experiment with stuff, though. but I'm not sure with what semantics I should add. drmeister, any opinion on this? forget it for now? or add as a direct copy of ./waf -f foo to clasp -f foo, i.e. not have ./waf configure store it?
18:58:42
Bike
if i wanted to store it in the configuration i think i'd rather just write it in the configuration myself
19:01:24
attila_lendvai
my idea is that you add something to the codebase that slows things down, but enables better debugging. then sometimes you start a build by ./waf configure --feature heavy-debugging-stuff and until the next ./waf distclean all clasp invocations will have that feature
19:02:46
attila_lendvai
./waf -f debug already does this (it enables 4 features), except that it's not stored in the configure phase
20:25:11
Bike
if i turn inlining on and uncomment inline.lisp it dies silently, but it's going okay without that (so only inlining lets and local functions i guess)
20:31:05
drmeister
Could it be that the criteria for inlining functions is incorrect? Beach said this was something we needed to be very careful of.
20:36:46
Bike
it dies silently when bclasp+cleavir gets toinline.lisp, i.e. when it's actually using the compiler for the first time
21:21:13
attila_lendvai
ACTION is back at playing with his staged-bootstrapping idea, stripping down stage-1 to contain only what's need for iclasp
21:25:39
attila_lendvai
I may be missing something, but it makes a whole lot more sense to me to have separate codebases managed by the VCS for the separate bootstrap stages. similar-looking, cherry-picking commits, yet free to diverge when needed. we'll see how much of the complexity I'm not aware of and how much it will bite me on the way, though...
21:32:07
attila_lendvai
Bike: I'm hoping that git cherry-pick can help manage that. and I also hope that it will happen fewer and fewer times when stage-n-1 needs to be touched to build stage-n. keep in mind that it will be easy to "escape forward" and introduce a new stage for a new feature. some stages can even continue building using an ancient version of cleavir...
21:33:18
drmeister
I did a full build this morning - on ubuntu - there was no problem. That's why I'm perplexed.
21:34:32
karlosz
ill just do cleavir-mir: for now but it seems like thats just like any other hir modification
1:27:24
karlosz
no wonder i had to recalculate the dominance relation every time i wanted to find the input associated with a predecessor
1:36:26
karlosz
so to work around the bug i had to recalculate which input corresponded to which predecssor every time
1:58:15
drmeister
Bike: Is there a way to turn debug frames on for all new compiled functions? I don't have the change I made earlier turned on yet.
3:54:49
karlosz
https://paste.gnome.org/po5rpykk1 and https://paste.gnome.org/pbhb5r6k4 can both be proved to be what they return in cleavir but sbcl still has to do the computation