IRC channel logs


back to list of logs

<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>And I still get the dreaded
<peterbrett>ERROR: In procedure bytecode->objcode: bad bytevector size (8875 != 8792)
<peterbrett>when I try to run it
<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
<wingo>so wheee, yay
<peterbrett>Same here
<peterbrett>Maybe the reencoded and reuploaded?
<iyzsong>Happy chinese new year :-)
<mark_weaver>wingo: oooh, that's good news about the video!
<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 :)
<mark_weaver>Happy new year!
<civodul>iyzsong: happy new year :-)
<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>This is driving me nuts
<peterbrett>I wish it would just tell me what the problem is
<peterbrett>Does anyone have any suggestions...?
<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
<peterbrett>I will investigate further
***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
<peterbrett>Which is... good progress!
<mark_weaver>wingo: for background, this is on an LLP64 system where longs are 32 bits but pointers are 64 bits.
<peterbrett>No -- this is LP32
<mark_weaver>oh, nevermind :)
<peterbrett>I was getting that working before trying out mark_weaver's patch
<peterbrett>(Which I haven't forgotten about!)
<mark_weaver>that's fine, no rush
<peterbrett>On the basis of walking before running!
<mark_weaver>makes sense
<mark_weaver>wingo: also, fwiw, building tag v2.1.2 from git on i686, I got this error:
<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
<mark_weaver>okay, I'll try make clean and report back. thanks!
<wingo>concretely i think that one was fixed in 620b640a4eccf6fdaa9cda8dc77c415e975a1834
<wingo>not sure tho
<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? :-)
<wingo>djcb: heh, tx ;)
<wingo>no immediate plans :)
<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
<djcb>oh great!
<amz3>paroneayea: have you seen,
<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
<wingo>heh tx
<linas>when I say (define x (display "adsf")), what is the type of x? How can I find out?
<linas>(nil? x) says #f
<linas>(list x) says (#<unspecified>)
<linas>How can I create something of value #<unspecified>, aside from the above define?
<mark_weaver>linas: out of curiosity, why do you want it?
<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>*value is returned
<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)
<mark_weaver>that's probably the cleanest solution
<linas>when you say "now that scheme..." is this something other than srfi-8 and the related call-with-values, etc
<mark_weaver>linas: multiple values were added to R5RS scheme
<mark_weaver>so I guess it's not exactly recent...
<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>ACTION nods
<mark_weaver>and maybe not even buy us much, dunno :)
<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
<mark_weaver>do what now?
<mark_weaver>yeah, that's a good point!
<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>yeah totes
<mark_weaver>and I'm probably too much of a perfectionist
<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
<mark_weaver>yes, indeed, we should talk about it
<wingo>anyways, maybe the mailing list is a good place to discuss it
<mark_weaver>thanks for being kind :) heh
<mark_weaver>sounds good
<linas>nurturing capable potential future volunteers is critical for success
<linas>easy to say, hard to do
<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>ah. but of course.
<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
<vanila>this peval thing looks amazing
<daviid>playing with the dyn ffi, to learn, and try to bind this def:
<daviid>GtkWidget * gtk_clutter_window_new (void);
<daviid>as this
<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]