<iyzsong>daviid: hi! I'm the 'someone', need that for guix, where the guile search-path is versioned (.../site/2.0). <iyzsong>ofc, we can add un-versioned one, need ludo's judgement :-) ***ozzloy_ is now known as ozzloy
<peterbrett>Wow... still *really* struggling to build a Windows guile that has a compiler that actually works :( <peterbrett>I built a host Guile and cross Guile with *exactly* the same dependencies and configuration settings <peterbrett>ERROR: In procedure bytecode->objcode: bad bytevector size (8875 != 8792) <peterbrett>At this point I think I'm actually completely stuck <peterbrett>Could the problem be that GUILE_FOR_BUILD is x86-64, but I'm trying to compile an i686 guile? <peterbrett>To be more specific... I'm building a build guile with --host=x86_64-pc-linux-gnu and --build=x68_64-pc-linux-gnu... and then using it as GUILE_FOR_BUILD in a cross build with --host=i686-w64-mingw32 --build=x86_64-pc-linux-gnu <peterbrett>I'm going to spin up a 32-bit VM and spend another hour trying again... <madsy>peterbrett: i686-w64-mingw32 is a 64-bit host triplet, no? <madsy>Ah, nevermind. The first part is the cpu, yep. <wingo>i thought the sound didn't work, but i tried on a different machine and it's fine <mark_weaver>the file did change, by the way. I saved a copy of the old one with no sound. the new one is over 50% larger, for one thing. <mark_weaver>maybe the other files will be fixed as well? one can hope :) <peterbrett>Argh. When I cross-compile Guile for i686-w64-mingw32 on i686-pc-linux-gnu I get *another*, different, "bad bytevector size" error on startup in bytecode->objcode <peterbrett>I wish it would just tell me what the problem is <wingo>peterbrett: startup of the cross-compiler or the built w64 binary? <peterbrett>Built w32 binary (the "w64" in the triple is confusing) <peterbrett>Interestingly, it looks like guile 2.0.11 is allergic to spaces in $GUILE_LOAD_PATH and/or $GUILE_LOAD_COMPILED_PATH ***karswell` is now known as karswell
<peterbrett>When I moved the build stuff into a short path with no spaces, it started running and compiling .scm files <mark_weaver>wingo: for background, this is on an LLP64 system where longs are 32 bits but pointers are 64 bits. <peterbrett>I was getting that working before trying out mark_weaver's patch <mark_weaver>wingo: however, I didn't "make clean". I touched module/ice-9/eval.scm and compiled from there. previously I had built successfully from a month or two ago. <wingo>ah, then it's possible that's not an error then <wingo>i think the bytecode changed in significant ways, i should have bumped the version but i assumed git folks would be making clean periodically <wingo>concretely i think that one was fixed in 620b640a4eccf6fdaa9cda8dc77c415e975a1834 <djcb>wingo: that was as super interesting talk at fosdem! <djcb>should be twice as long though! <djcb>can we expect that some time soon? :-) <djcb>wingo: would be great to hear about the items you didn't have time for <djcb>of course, you've been blogging it as well <wingo>yeah most of it has hit the blog, only the lambda representation thing that hasn't, and i'm working that one into a post <amz3>paroneayea: a framework for extending microkanren with constraints <paroneayea>amz3: I haven't seen that paper specifically but I've wanted to look into ckanren... <peterbrett>The wingo log has been pretty top-notch recently <linas>when I say (define x (display "adsf")), what is the type of x? How can I find out? <linas>(list x) says (#<unspecified>) <linas>How can I create something of value #<unspecified>, aside from the above define? <mark_weaver>the scheme standards say that various things like (if #f #f) return an unspecified value. <mark_weaver>what that really means is that it could be anything. it could be #f or 137 or '(blah blah) <mark_weaver>guile has a special value that we currently use in cases like that, but I'm reluctant to promise that we always will. <mark_weaver>when we have native compilation, it will probably cost us something to maintain that promise <mark_weaver>linas: (if #f #f) is the usual way to return an unspecified value, though. <mark_weaver>and *unspecified* is identifier-syntax that expands into that. <linas>thank mark_weaver, If found myself in a hacky place, where the guile prints something, and I then pipe stdout to a chatbot <linas>I just discovered that if I make (display "") be the last line of my function, then nothing is printed (which is what I want) <linas>but if I make the last line be #f or '() or (list) then guile prints $42 = #f or whatever <linas>I probably should not be using stdout, except that guile sometimes invokes other programs which print to stdout, and whose output I need. <linas>Its a total mess. Bad design I suppose, but hard to figure out a better way. <mark_weaver>linas: it's true that Guile's REPL special cases when the special unspecified value, and prints nothing in that case. <mark_weaver>now that scheme has the ability to return an arbitrary number of values from a procedure, we could handle these cases by returning no values at all, via (values) <linas>when you say "now that scheme..." is this something other than srfi-8 and the related call-with-values, etc <mark_weaver>but historically, things like (if #f #f) returned an unspecified value from the time when everything had to return one value, and at this point it would probably break a lot of software if we changed those things to return zero values. <linas>ah OK. I'm running guile-2.2 ... <linas>you also said "native compilation" .. is this a hint that there's a plan to compile GIL to Intel assembly? <wingo>mark_weaver: i think there's no significant impact of native compilation on this, fwiw <wingo>linas: in some future. it will be a couple years tho <mark_weaver>linas: GIL is long gone, even in 2.0. but yes, we plan to compile to machine code. <mark_weaver>wingo: well, only that when we compile to native code, overheads that were lost in the noise before will start to become significant. <wingo>mark_weaver: yeah, could be. i guess my point is that you rarely see actual undefined values except from subr returns <wingo>because inside a function if an expression would produce an undefined value it's rarely used and so it's not reified <mark_weaver>wingo: well, I haven't thought deeply on this, but C compiler writers seem to feel motivated to take advantage of unspecified behavior as much as possible, presumably because it has allowed them to optimize the code more. and we might be able to gain something by not promising to always return a specific value in those cases. <mark_weaver>having said all of that, it may be that it would break too much code for us to do so, or have bad effects on space safety, etc. <wingo>in many ways i would love to return 0 values :) like you tho i don't know if that will work. <mark_weaver>but subr returns are quite common in scheme, more common than in analogous C code. <wingo>hey mark_weaver at fosdem paroneayea brought up a really nice point that with the upcoming 2.2 releases we'll naturally get a surge in interest <wingo>and we need to be able to handle it, probably makes sense to plan for it a bit <wingo>i need to return to the mailing list, but i can do that now <wingo>but another thing we probably need is to grow the set of people that can land patches <wingo>that we trust to land patches to guile <wingo>and that are able to help contributors with patch review etc <mark_weaver>yeah, obviously the three of us don't have enough time to keep up with it. <wingo>i don't know what the immediate answers are, but i think it's probably the challenge of guile this year, so we should figure out some kind of plan anyway <mark_weaver>combined with not having enough time. bad combination <wingo>heh i think you do a great job mark_weaver :) i really admire your empathy with folks that come both with problems and solutions, and i would like to cultivate that more in myself <wingo>anyways, maybe the mailing list is a good place to discuss it <linas>nurturing capable potential future volunteers is critical for success <wingo>i am hoping that if we communicate more about where we see guile going in the next year or two that people can find ways of fitting into that. right now we don't do a great job of that i think <wingo>so people that would be happy taking some responsibility aren't aware that it's a possibility <wingo>i would really love it as well if we could improve the diversity of our contributors too, but i think having a plan at all about how to work better with contributions probably needs to happen first; dunno <linas>many "traditional" open source projects seem to be hanging by a thread. All the hot action seems to be on the cloud or on phones <linas>But even there, ... forces seem disorganized. <amz3>that's the bazaar theorem ;) <linas>I don't recall if there was any discussion of marauding armies laying waste to random villages. <linas>Because, after all bazaars were usually located outside of the safety of the city wall <vanila>im just watching the fosdem guile talk <daviid>playing with the dyn ffi, to learn, and try to bind this def: <daviid>GtkWidget * gtk_clutter_window_new (void); <daviid>... (pointer->procedure '* (dynamic-func "gtk_clutter_window_new" %libclutter-gtk) (list void)) but i get an error In procedure pointer->procedure: Wrong type argument in position 3: 0 <daviid>so I guess it is this (list void) which causes the problem, any hint? <daviid>I wonder why in C they define "GtkWidget * gtk_clutter_window_new (void);" and not "GtkWidget * gtk_clutter_window_new ();" [please excuse my ignorance]