22:22:22Bikedrmeister: 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:22ColleenBike: 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:49:25Bikeoh, 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.

23:01:42Bikethe 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:01:56Bikeobviously with fastgf it's different, but it could be similar

3:13:00robinkdrmeister: 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:23:50robinkThe 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:55:49drmeisterrobink: 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

3:56:24drmeisterIn the github directory I see a Manifest file and the clasp-9999.ebuild

5:15:53drmeisterrobink: 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:30:10drmeisterWe still have some speed bumps in gf calls that will mask the effect of fastgf - we will get rid of those next.

5:32:24drmeisterI 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:56drmeisterI say I think because I can't think of anything else at the moment. I was very, very careful to avoid generic function calls.