freenode/#clasp - IRC Chatlog
Search
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.