freenode/#clasp - IRC Chatlog
Search
21:11:24
robink
Bike: Well, the build process is *complaining* about the fact that it can't write to /tmp/dispatch-history/dispatch-miss.log
21:12:42
Bike
drmeister: there a switch or something to flip so that it doesn't write out the fastgf stuff?
21:24:18
drmeister
robink: It's just on for the short term while I test things - do you need it off right now?
21:24:46
drmeister
Ooops - sorry - I thought it was dormant until I turned it on - but not the debugging part I guess.
21:25:16
drmeister
(format nil "~&THIRD!!!! Condition of type: ~A~%~A~%" (type-of condition) condition)
21:40:48
drmeister
So my problems for the last week were incorrect updates to the specializer-profile.
22:07:21
drmeister
::notify Bike Could you check that when we add parameter arguments that they start counting at 1? I'm 99.999% certain they do - but it's an off-by-one error...
22:21:28
drmeister
It was on [180 of 301] total memory is 1.2GB and 2951 dispatch functions have been generated and then it went nuts.
22:22:22
Bike
drmeister: for parameter attributes there's an addParamAttr that takes a parameter number rather than an attribute index, and that's what clasp is using
22:22:22
Colleen
Bike: drmeister said 15 minutes, 1 second ago: Could you check that when we add parameter arguments that they start counting at 1? I'm 99.999% certain they do - but it's an off-by-one error...
22:23:01
drmeister
https://github.com/Bike/SICL/blob//Code/Cleavir/Intermediate-representation/datum.lisp#L9
22:23:11
drmeister
https://github.com/Bike/SICL/blob/dev/Code/Cleavir/Intermediate-representation/datum.lisp#L9
22:23:27
drmeister
https://github.com/Bike/SICL/blob/master/Code/Cleavir/Intermediate-representation/datum.lisp#L9
22:24:12
drmeister
That's all there is - (DEFCLASS datum ...) do classes get redefined at compile time?
22:25:24
drmeister
Could it be redefining the class - making a LOT of datums in the HIR out of date?
22:27:05
Bike
and i wouldn't expect that the class is redefined in the middle of the compile i.e. while there are datum instances around.
22:30:26
Bike
i don't know what you mean by trapping. i think the lldbrc already has something set up to break on simple_error.
22:49:25
Bike
oh, that might be basically the same problem i ran into... which is that when you redefine a class, it tries to take away the old methods and slots and things before reinstalling them, but since it's part of the compiler it might try to use the compiler and then you're hosed.
22:59:32
drmeister
Should I somehow tell the build system that it should use the bclasp compile-file for datum.lisp?
23:00:00
Bike
well i don't know exactly what it's doing. it seems like fastgf doesn't really invoke cleavir.
23:01:42
Bike
the problem i ran into was, when building cleavir, it would hit that file, then the defclass, and that would undefine the class and accessors and such, and then with all that stuff undefined it would do make-instance, which with my changes could trigger the compiler, which would then find datum undefined and die
23:04:45
drmeister
Does INTERRUPTED-ERROR mean anything to you? It's the something I see in the dispatch-miss.log
23:08:58
drmeister
What about %gid? That's the stealth mixin stuff I put in - you were having issues with that weren't you?
23:14:44
drmeister
It may be trying to invoke a gf called NAME and then asking for a stealth mixin that may not be set up
23:24:41
Kevslinger
ACTION is reading a book about astronomy and gets confused every time he reads "Jupiter" instead of "Jupyter"
1:43:30
drmeister
I found them very useful when I was debugging cleavir's hir and mir generation but I haven't looked at them for a long time.
1:44:11
drmeister
If they are very useful, maybe beach would consider adding them to the instruction and datum classes - or add them as a feature.
1:45:39
drmeister
I'm thinking it might be a combination of (1) stealth mixins in a compiler class (2) building the compiler using the compiler (3) the debugging code that I had turned on.
1:46:12
drmeister
No - I don't know exactly what the issue was. We can turn them back on and debug the problem.
1:52:14
drmeister
This is such a relief - it's only generating a few hundred dispatch functions and they have negligible impact on memory usage
2:00:31
drmeister
Hmmm, there is still something going wrong. At the very end of the build it's generating a lot of these warnings:
2:01:06
drmeister
These mean that generic functions are generating dispatch-miss and when they try to update the call-history the selector is already in the call-history.
2:08:15
drmeister
There are many generic functions generating that warning. I'm going to try a complete rebuild to see if that clears it up.
3:04:02
robink
https://github.com/Haifen/robinkverlay/blob/master/dev-lisp/clasp/clasp-9999.ebuild https://raw.githubusercontent.com/Haifen/robinkverlay/master/dev-lisp/clasp/clasp-9999.ebuild https://raw.githubusercontent.com/Haifen/robinkverlay/master/overlay.xml
3:08:48
robink
First link is HTML GitHub blob view of ebuild, second link is raw ebuild file, third link is raw overlay.xml file (for adding the robinkverlay overlay)
3:09:37
robink
drmeister: Yep. Given that Gentoo is a from-source distro, that ebuild "is" the package.
3:09:56
robink
drmeister: You can build up a binary package from that ebuild, but it's not the default behavior of emerge.
3:10:15
drmeister
Will anything change once I push my current changes that no longer write to the /tmp/dispatch-history directory?
3:10:54
robink
Yes, I'll drop the addpredict line, since the upstream build process will be 100% sandbox-friendly.
3:13:00
robink
drmeister: If I make sure to follow source releases to see if there's something that's on-par with the current 'dev' HEAD, I'll be sure to have it fetch from GitHub have your source release in the Manifest along with the rename-bump.
3:15:26
robink
Can also file a bug to increase the likelihood that something (not necessarily my ebuild) will be upstreamed into repo/gentoo.git.
3:20:29
robink
https://gist.github.com/Haifen/f85e77c4a100ade09e39ac85cdbed537 (built by ebuild from commit d744dd536ae0861338870cd4f12bc11045847e3b)
3:22:34
robink
The waf-utils eclass is calling '"${S}/waf" configure', which doesn't show in my ebuild.
3:22:59
drmeister
I updated 'dev' a couple of weeks ago and then nothing and then in the last two days I pushed all my latest code with problems in fastgf and debugging on.
3:23:50
robink
The git-r3 eclass automatically (and recursively) fetches and checks out all submodules. Obviously update_submodules is necessary to concatenate one of the needed build (LISP?) files, but it's run in the src_prepare() phase.
3:28:47
robink
drmeister: I can put it in 'dev-lang' (or, heck, even 'sys-devel') if you'd like, it's just that most of the CLISPs live in dev-lisp.
3:29:19
drmeister
So - should I - could I - copy these files into say... clasp/tools/package-managers/gentoo ?
3:31:00
robink
drmeister: Erm, either way is fine. I don't need credit, and not only are they GPLed, I'm happy assigning copyright somewhere else.
3:31:39
robink
drmeister: but I can stick my name on a README, I suppose. I think I'll leave the copyright assigned to the Gentoo Foundation, just in the hopes that it'll get upstreamed quicker.
3:55:49
drmeister
robink: I don't see the overlay file that you posted above: https://raw.githubusercontent.com/Haifen/robinkverlay/master/dev-lisp/clasp/clasp-9999.ebuild https://raw.githubusercontent.com/Haifen/robinkverlay/master/overlay.xml
4:37:57
drmeister
Argh - there is still a problem with the build - now it's faulting when compiling this method... https://github.com/drmeister/clasp/blob/dev/src/lisp/kernel/lsp/pprint.lsp#L115
5:12:32
robink
drmeister: Hm, interesting. The overlay file is at https://raw.githubusercontent.com/Haifen/robinkverlay/master/overlay.xml
5:15:53
drmeister
robink: I have to head to bed - I restarted the build here with debugging turned on to see if I can figure out from the debugging output what is going on with that print-object-method that is causing the build to fail. I'll check it out in the morning and push a fix once I figure it out.
5:22:20
drmeister
Hi beach - I got fastgf working with cclasp - although there appears to be some kind of satiation problem with print-object at the moment.
5:26:19
beach
From stassats' remarks, I can tell that he is skeptical about it, but I can't tell the reason for his skepticism.
5:30:10
drmeister
We still have some speed bumps in gf calls that will mask the effect of fastgf - we will get rid of those next.
5:32:24
drmeister
I think my current problem is the printer invoking PRINT-OBJECT somewhere in the fastgf compiler. It's going into a recursive loop when it compiles a certain PRINT-OBJECT method and that overflows the stack.
5:32:56
drmeister
I say I think because I can't think of anything else at the moment. I was very, very careful to avoid generic function calls.