<jralls>sneek: later tell spk21 Thanks, I pulled that and tried. It doesn't experience the DT_GUILE_ENTRY problem and manages to compile modules/bootstrap with no errors, so progress. But the first compilatoin in ice-9, and-let-star.scm, crashes and ends up with throwing (I guess in analyze.scm) while printing the backtrace: Value out of range 0 to 4294967295: 1854266240. <jralls>sneek: later tell spk21 Of course 1854266240 (aka 0x6e85db80) *isn't* too big for a uint32, so it's a bit mystifying. Something must be getting clipped. FWIW I'm building i686, not x86_64. <spk121>jralls: I believe your and-let-star error comes from needing a complete clean <sneek>Welcome back spk121, you have 3 messages. <sneek>spk121, jralls says: Thanks, I pulled that and tried. It doesn't experience the DT_GUILE_ENTRY problem and manages to compile modules/bootstrap with no errors, so progress. But the first compilatoin in ice-9, and-let-star.scm, crashes and ends up with throwing (I guess in analyze.scm) while printing the backtrace: Value out of range 0 to 4294967295: 1854266240. <sneek>spk121, jralls says: Of course 1854266240 (aka 0x6e85db80) *isn't* too big for a uint32, so it's a bit mystifying. Something must be getting clipped. FWIW I'm building i686, not x86_64. <spk121>jralls: you may be picking up an and-let-star from the bootstrap directory or something <spk121>I don't recall exactly, but, in my notes I wrote that system-file-name-convention has different logic in the compile-time case with regards to window vs linux files, and I worked around it by cleaning out all the .go files and doing the whole painful 2 hour build. <spk121>also, some of the out of range errors when reading compiled files come from CR vs CRLF errors in mkstemp! <spk121>which was one of the patches, so another reason why everything has to be rebuilt from scratch <rekado_>making a game with chickadee is great fun <rekado_>I’m a little uncomfortable with GOOPS. It’s great, don’t get me wrong, but it makes me write code that I don’t find pretty. <rekado_>there are way more instances of “set!” than in any other Scheme project I ever worked on. <manumanumanu>rekado_: it is drafted after CLOS, which I suppose means that is what you get <rekado_>I was also surprised that there is no define-method* that would allow me to use keyword arguments or optional arguments. <rekado_>it’s missing a couple of convenience features, but it’s easy to hack around that. <wingo>rekado_: yeah goops needs a bit of love i think. it's had maintenance but not much in the way of new development in the last 15 years <wingo>in a way it's remarkable that it still makes sense, as much as it does <wingo>i also feel strangely attracted to and repulsed by it :) <wingo>some parts are really beautiful, some are not so much <civodul>i went from being a big fan to avoiding it, in part due to the programming style it encourages <civodul>but every time i C-M-x a record type, i dream of the class redefinition protocol :-) <wingo>ACTION makes vm operations to tier up to jit <brendyn>wingo: I don't understand it but I think you're doing great work! <brendyn>wingo: Did you end up looking at my code that makes ,trace crash? I was wondering why that happens. <wingo>brendyn: heh tx :) no, haven't had time to look into that <wingo>all the trace code is in scheme tho so you might find poking around those modules to be interesting <brendyn>i'll try but it's probably too advanced for me. I could try tracing trace <civodul>i may use it for a few things in Guix at some point <civodul>using vhashes and alists for everything is not great... <dsmith-work>rlb: Did you ever get your Debian Guile issues resolved? <rlb>FAIL: SMOB mark function called for each SMOB <rlb>ERROR: asyncs.test: preemption via sigprof - arguments: ((vm-error vm-run "Unrewindable partial continuation" (#<vm-continuation aaab0dc4afa0>))) <rlb>(those are ppc64el and arm64 respectively) <rlb>When I have time, I'll probably go ahead and incorporate 2.2.4 and try again. If that doesn't help, then I'll either need upstream help of some sort, or to wait until I have time to delve myself (which may be a while). <dsmith-work>rlb: Thanks for the info. Wish I could help. I'd hate to see Debian drop Guile. <rlb>Well, I think we're quite a way from that -- the key deadline will be the buster freeze, but I sure hope we can get things sorted out much sooner. <rlb>This is just guile-2.2 being dropped from testing (buster) for now -- once we can get a version into sid (unstable) that passes all the tests, it'll automatically propagate back into buster after a while. <jralls>sneek: later tell spk21 Thanks, but it's a clean build in a freshly-created build directory from a freshly-cloned guile branch tracking wip-mingw-guile-2.2. <privacynewbie>I just found out about Guile while digging into what GNU was about <privacynewbie>So I'm just going to chill here while I try to convert all my digital presense (OS, applications, subscriptions) to free software <manumanumanu>rekado_: I have two different versions of define-method*, one that uses the method dispatch to define all the methods with optional args, and one that uses lambda* <manumanumanu>I liked the first version when the define-metod* has to play nice with other methods, but for most part the define-metod* using lambda* is probably what you want most of the time ***unCork is now known as Cork
<daviid>fwiw, define-methods* is part of grip too ... <daviid>manumanumanu: you are not implementeing a real dispatch, you only dispatch on arity, is that correct? fwiw (again :)), I would not do that, which is why I prefer the impeentation offered bu grip (and actually written by Mark H. Weaver himself :)) <daviid>those who want diffent methods based on arg list should write the methods manually, imo. optional kw are other beats, that should not be treated (not even be seen) by goops, againm imo, but of course one does what they want ... it's a free world <manumanumanu>daviid: I have both versions. I don't remember how the grip version is, but I dispatch rest arguments to lambda* <daviid>manumanumanu: but your 'dispatch' version does not dispatch on arg type, only because of the method arity, iiuc <manumanumanu>the goops version uses goops dispatch ("typed"), and the lambda* one passes rest arguments to define-method to lambda* <manumanumanu>I have used both, and for most cases the grip-style ones are what you want <daviid>manumanumanu: the macro you wrote and that I did read does not dispatch on the argument type, since it is not passed in the first place ... <manumanumanu>I allow (define-method* (blah (hej <integer>) #:optional (hopp <integer> 3) (snopp <integer 3)) (+ hej hopp snopp)) <manumanumanu>but I have a second one (which I wrote after our discussion) that dispatches to lambda* <daviid>and that is like the one written by mark, included in grip ... <manumanumanu>I tried for a long time to make it work using case-lambda and keyword parsing <daviid>manumanumanu: imo, that effort isn't worth it, users must/should write these maually,and only using the define-method* for optional keywords, that goops does not see ... but I understand you made that a challenge :) somehow ... <manumanumanu>I made it work, but then I realized I was doing the same thing as lambda*, and the lambda* version was a _lot_ faster