<mark_weaver>apparently at least one of the bombs was made from a pressure cooker packed with shards of metal, nails, and ball bearings. <ArneBab_>When trying to run the webserver example, I get an error: web/server/http.scm:58:0: In procedure module-lookup: Unbound variable: AF_INET <ArneBab_>(if you answer, please mention my name: I normally read my backlog) <dsmith-work>What happens if you fire up a guile and eval AF_INET ? <dsmith-work>I wonder if that guile was ./configure'ed --disable-networking <ArneBab_>ERROR: In procedure #<procedure ce21a0 ()>: <ArneBab_>ERROR: In procedure module-lookup: Unbound variable: AF_INET <ArneBab_>besides: should I configer it with threads? <dsmith-work>Threads should be fine. I think the only people with threads issues are mingw or bsd or something. <dsmith-work>ArneBab_: What's your libgc ? The have been issues that go away with 7.2d <mark_weaver>ArneBab_: interesting. any idea why it was built with --disable-networking? is that how it's built by default on gentoo? <ArneBab_>I think that is likely the default: In Gentoo the user gives the USE flags he or she needs. The base system tries to stay minimal <mark_weaver>it seems kind of extreme for a modern scripting language to be built without networking support. is python built without networking by default? <ArneBab_>actually guile 2.0.7 is still hardmasked… *dsmith-work has suspicions <mark_weaver>I find this really obnoxious. As if Guile didn't already have enough of an uphill battle, Gentoo builds us with one leg cut off. <ArneBab_>that means “don’t use it, if you’re not willing to fix breakage” <mark_weaver>networking is an extremely important thing for a language to support in today's world. <ArneBab_>I think the simple reason is that “networking” is not in a default profile (as most packages don’t even have a switch for it) <ArneBab_>there is exactly one package in the whole tree which uses the useflag networking and that’s guile. *ArneBab_ needs to go to bed - it’s 01:37 over here… <ArneBab_>mark_weaver: for the packagers that’s actually a 1-character fix: Just add a + in front of the useflag :) <ArneBab_>cu, and many thanks for working on guile! <mark_weaver>thanks for bringing this issue to our attention, and for filing the bug report :) <ArneBab_>I actually hit it when I played with my wisp indentation-to-brackets preprocessor :) ***fangism is now known as fangism-hungry
***adu_ is now known as adu
<mark_weaver>pretty well, I think. we seem to be picking up momentum lately :) <adu>nice, anything I can do to help? <adu>I've been puting the finishing touches on my compiler, and now I have no libraries, and the thought of writing lots of libraries scares me <mark_weaver>it's hard to pick jobs for other people, but there's certainly lots to do. <adu>and btw, my compiler is written in guile :) <adu>did I ever show it to you? <adu>* VM instruction to lisp canonicalize (#f or '() => #nil) ? <mark_weaver>I think you showed me an early version of it. I seem to have forgotten the details. <mark_weaver>yes, as I recall, I noticed that the guile-emacs project could make use of such a VM instruction, though I've forgotten the details of that too :) *mark_weaver looks at droscheme again <adu>especially the "it's not working yet" <adu>the compiler is working great <adu>but until I figure out how to make the interpreted and compiled languages the same, I'm a bit stalled <mark_weaver>I don't understand how that helps. Does gccgo guarantee that tail calls will be optimized into gotos for all the code that you produce? <mark_weaver>really? very interesting. for C code at least, gcc tries to do the optimization, but in practice you can't count on it except in very simple cases. <adu>oh, then I was misinformed <mark_weaver>did you have to make a big compromise in your generated code to make that possible? <mark_weaver>there was an academic article written on this topic. let me see if I can find it. <adu>cool, I'm certainly interested <adu>can you show me an example of C code that is tail-recursive that gcc doesn't optimize? <mark_weaver>lots of people have wanted this for a long time, most notably people who write compilers for functional languages targetting gcc as a back end. <mark_weaver>granted, that thesis looked at GCC circa 2003, but if it had changed, I think it would have been big news in this community. <adu>I've read a lot of ASM produced by gcc, and every tail call I've seen has been a goto <adu>alloca() would screw up things <adu>hahaha, that article should have been called "uses of unary & foil tail-call optimization" <mark_weaver>I suspect there are simpler cases that fail as well, but I don't have much time to spend on this right now. <adu>do you have time for another thesis? <mark_weaver>propagators? yeah, I know about them. very exciting work. <cky>mark_weaver: I'm staring at the SRFI 41 code again. In stream-match, in the make-matcher procedure, I'm thinking of changing the (var . rest) case's match clause to use stream-pair? instead of (negate stream-null?). Comments? <mark_weaver>adu: your 'string-escape' procedure doesn't work properly. <adu>that was a hack, I'm welcome to suggestions <cky>mark_weaver: Originally I used (negate stream-null?) to complement the stream-null? case with the () match clause, but, stream-car and stream-cdr (as used in the (var . rest) match clause) won't ever work with anything that isn't stream-pair?, so this expresses the intent more directly. I think. <mark_weaver>cky: yeah, I think you're almost certainly right, but I'd like to fully grok this code before I comment further. <mark_weaver>cky: I think I'd like to completely rewrite 'stream-match' to generate better code. <mark_weaver>cky: well, for now, I definitely agree that changing (negate stream-null?) to stream-pair? would be a significant improvement. <mark_weaver>the reason I say "significant" is because using 'negate' is (unfortunately) very inefficient. <cky>mark_weaver: Please do feel free to refactor stream-match as you please. I just did the simplest thing I could think of that actually made use of (ice-9 match) (rather than the home-grown matcher in the reference implementation). <mark_weaver>don't get me wrong, what you wrote is perfectly reasonable, and the code isn't bad. <mark_weaver>but look at ,optimize (stream-match strm ((a . b) (list a b))) <cky>I will, once I build Guile 2.0.9. (I know, still not gotten around to it. I wanted to upgrade to a libgc 7.2d deb on my Squeeze system first, but that turned out to be too much work---the only 7.2d deb was from Ubuntu, and it requires multiarch (which Squeeze doesn't have).) <mark_weaver>there are four type checks on a single item: one at the beginning, one in the 'stream-pair?', and then two more in 'stream-car' and 'stream-cdr'. <mark_weaver>adu: a simple solution is to use 'string->list' to create a list of characters, then 'map' to map each of those to a string, and then pass the resulting list to 'string-concatenate'. <adu>mark_weaver: ok, I'll try that <mark_weaver>'string-concatenate' is very well implemented in Guile, btw. <cky>Yes, and much more readable than ''.join(...). ;-) (That's the standard way to concatenate a sequence of strings in Python that doesn't exhibit O(n^2) runtime.) <cky>(More seriously, we have a lot of Java code at work, and I cringe whenever I see string += being used in a loop.) <mark_weaver>cky: I forgot to respond to your mention of racketcon, but yeah, if you're going to be in the area, it would be great to meet you :) <cky>mark_weaver: Oh cool. :-) <mark_weaver>yeah, the code for string-join before 2.0.9 make that same mistake, and the results were rather disastrous for large lists. <cky>Yes, I hope to actually have Rackona fully fleshed-out by then. :-) <cky>The Rackona I presented was what I had hacked together in 2 days. <cky>...which was all the time I could put towards it, at the time. <mark_weaver>how hard do you think it would be to adapt Rackona to work on Guile? <cky>It shouldn't be hard, but I haven't tried yet. :-) <cky>Obviously, we'll have to find another coffee-related name that relates to Guile. :-) <mark_weaver>well, on the main page anyway. elsewhere your full name is shown. <mark_weaver>it's nice to see the graphs showing a prominent upward trend after our mid-2012 lull. <cky>Yes, let's hope the trend continues. :-) <cky>(I linked my Guile contributor profile to my main Ohloh profile now. Yay!) <mark_weaver>the man in the cowboy hat is actually holding on to the man's femoral artery, pinching it to prevent blood loss. <cky>Yeah, poor guy looked like he lost enough blood already. <sneek>Welcome back sw2wolf, you have 1 message. <sneek>sw2wolf, mark_weaver says: apparently stable-2.0 can now be built with threads on freebsd :) <jmd>I keep getting this warning: <jmd>WARNING: (guile-user): imported module (srfi srfi-19) overrides core binding `current-time' <cky>jmd: What version of Guile are you using? This message shouldn't appear. <wingo>i think he's still on 1.8 for some reason <jmd>What is the easiest way to write a procedure to generate a string which is a copy of an input string, but with all instances of X replaced by Y <jmd>thanks. I didn't know about string-map <wingo>there is also string-replace, which is documetned in the manual. <civodul>i'm sure there are many more projects that could be listed there <civodul>maybe it's not a medium people find interesting? <civodul>figl, guile-json, pfds, guildhall, etc. <add^_>Yay, The Reasoned Schemer just arrived! :-D <civodul>add^_: it's one of the two CS books i ever bought, and i enjoyed it <civodul>(the other one is about C++ programming ;-)) <add^_>If you liked it, I'm pretty sure it's good :-) <civodul>and then you can grab minikanren from guildhall to practice <ijp>I worked through a couple of chapters of it on paper first <ijp>except for the few occasions where they ask you a question you can't possibly know the answer to, it worked quite well <ijp>hmm, psyntax has taken a suspiciously long time <add^_>ijp: Really? How long does it have to be before it's suspicious? ***ijp` is now known as ijp
<dsmith-work>It can be *quite* a long time. Depends on the machine. <ijp>well, it was past the 90 minute mark when I killed it <ijp>and it's not like this is my first time compiling psyntax, I know roughly how long it should take on this computer <ijp>anyway, I'm leaving it for now <dsmith-work>Ok. I've had builds run for a *long* time, that went fine after a clean. ***serhart1 is now known as serhart
<mark_weaver>ijp: I'm doing a clean rebuild of master to see if I can reproduce the problem you're seeing. <mark_weaver>ijp: my clean compile has already gotten past psyntax. <wingo>i have experienced that problem as well <wingo>seems to go away if i simply retry the build. terrible. ***fangism-hungry is now known as fangism
<davexunit>mark_weaver: there appears to have been an arrest made related to the bombings. <mark_weaver>davexunit: interesting. do you have a link with more info? <davexunit>I'm following a twitter feed with a lot of people reporting similar things *mark_weaver wonders if people saw uncensored images such as this more often, if they would be more opposed to the rather frequent use of US bombs elsewhere. <dsmith-work>civodul: What was the sizes that sendfile() stopped at, if you remember? <davexunit>mark_weaver: yeah those images, especially the man with the missing legs, are hard to look at. <mark_weaver>apparently, even for normal files, linux always seems to stop at 0x7FFFF000 bytes <ijp>well, it built on the third attempt, anyway <ijp>I've previously had trouble with threads.test on master, but I don't think this is related <dsmith-work>that's one page (4k) less than max positive 32bit int. <dsmith-work>mark_weaver: Oh, and internally, sendfile sets up a pipe and runs splices to/from that pipe. <mark_weaver>apparently that limit is imposed in the upper layers in case there are bugs in the lower layers. <shizzy0>Has anyone done or worked with the google summer of code thing? <shizzy0>I'm thinking about proposing a project that uses guile. <shizzy0>Good to hear. I shot wingo an email asking if he might be interested. <shizzy0>Any guilers interested in possibly mentoring I'd be happy to hear from. <wingo>but as the delay indicates, i think i'm in general a terrible mentor -- not very responsive :P <wingo>and i don't see that changing in the next few months unfortunately <wingo>i could help in some adjunct capacity but unfortunately i'm not able to offer the kind of time you would deserve <shizzy0>Totally understand. It's always difficult to find time. <wingo>yeah, really sorry about that <shizzy0>No worries. But if you do have someone else you might recommend as a mentor, I'd be happy to hear it. <wingo>if you can convince civodul or mark_weaver, they would be ideal; also bipt, a former SoC student that worked on emacs stuff, if bipt has time <shizzy0>I'm doing my Ph.D., I'm 33, so I don't think I'd require a lot of hand holding, but there are a few technical challenges that'd be fun to sort through. <wingo>there are a number of other project members that could also do it; just look down the git log to see someone's work ***davexuni` is now known as davexunit
<shizzy0>Awesome. I'll follow up with them. Thanks again for all your work on GNU Guile! I've been working with it and I've been pretty amazed with what it can do. <wingo>glad you are having fun, and see you around :-) <shizzy0>civodul: not yet. I wanted to ask around about possible mentors first. <civodul>i've never mentored, but that might be doable <wingo>shizzy0: if you can't find anyone else, i would be willing to do it -- but with the understanding that my availability is a bit spotty. best if you could find someone else in addition. <dsmith-work>civodul: 64k? That's actually exactly what I expected. <shizzy0>civodul: yeah, totally understandable. And thanks! <mark_weaver>I don't think I want to be an official mentor, but I'd be willing to help answer any questions you might have. <civodul>dsmith-work: well, it's a power of two :-) <civodul>shizzy0: ah yes, i did read about it back then <dsmith-work>civodul: It uses pipe buffers, which are 16 pages. Pages are usually 4k. <cordawyn>is there a way to re-export bindings from another module without having to list them all over again? <civodul>cordawyn: there's an undocumented API, with module-for-each, module-export!, etc. <mark_weaver>shizzy0: no problem! I try to help most people anyway :) <cordawyn>not that I can't read the source, but how stable is that undocumented API? <shizzy0>I figure, I need one official mentor for GSoC, but the true burden will be on #guile. <civodul>i should say it's community-documented <civodul>because Guilers have known it for decades <wingo>that api used to have a comment above it saying "this api is unstable" <wingo>that comment was there for 15 years :P <civodul>i do avoid it too, because the declarative approach is more amenable to Good Things <wingo>it said "this is unstable and will change soon", what's more :P <cordawyn>civodul: so it's likely to stay there? I don't want to use undocumented API all over the project just to find it gone one morning :) <mark_weaver>wingo: well, if we tell people they can safely use that api, then it constains us in the future. <wingo>cordawyn: clearly the solution is to submit a patch documenting that api ;) <mark_weaver>wingo: also, the problem texinfo is having with Guile 2.0 seems to be largely due to them using too many low-level module interfaces. <wingo>mark_weaver: true, but personally i've gone through it quite a bit and it seems fine to me <cordawyn>wingo: I wouldn't mind making a patch, really. Just wanted to make sure it's not something experimental (and undocumented because of that) <civodul>cordawyn: it's here to stay, i think <civodul>what is "the problem texinfo is having with Guile 2.0"? <wingo>i agree that a doc patch will clarify things for good <wingo>we can argue over the interface then commit to something <mark_weaver>IMO, it's better to use declarative interfaces than imperative ones, especially for something like a module system, especially if the only reason is to save the programmer from writing out a list of bindings. <wingo>mark_weaver: no argument there! <mark_weaver>if it's deemed useful to reexport the entire interface from another module, maybe we should just add that feature to the 'define-module' API? <wingo>or add a re-export-module form <wingo>anyway, agreed, but sometimes it's good to muck around in modules, and having a documented interface for that would be a good thing <wingo>while preferring higher-level interfaces of course <shizzy0>One vote for re-export-module. I wrote a procedure to do a similar operation. <wingo>shizzy0: i think i've written that one on quite a number of occasions ;) <wingo>fwiw, it's (module-use! (module-public-interface (current-module)) (resolve-interface other-module-name)) <cordawyn>ok, thanks for the help, guys. I'm back to the grind. <mark_weaver>civodul: sorry, I meant to say "the problem texmacs is having with guile 2.0" <cky>Oh look, it's a bipt. :-) <cordawyn>mark_weaver: IMHO, it makes sense to add #:re-export-module feature to define-module :) <ijp>I don't see how a re-export-module would be very helpful in general unless you also had a way to filter that list <wingo>let's say you have a scheme module that binds some library <wingo>there are types and functions <wingo>you want to export everything <wingo>but you have to implement the functions in terms of the types <wingo>so you have separate modules and re-export the types module <wingo>that's a pretty classic case IME <wingo>that said it has also been the case for me that sometimes my use of re-export-module has corresponded to sloppy API thinking <cordawyn>btw, doesn't "require" from SLIB automatically re-export bindings from the "require"d module? <cordawyn>s48-interfaces.scm here defines one "rdf-graph" interfaces, while the library has 2 modules with different graph implementations (and identical API). <cordawyn>So one can choose one of the implementations in his/her own project. <cordawyn>just load the main module with interface definition, then load one of the submodules? <cordawyn>I'm pretty sure that "main" will complain that there's "no code for (main rdf-graph-*)" :-) <mark_weaver>sounds like you want higher-order modules, which we don't yet support.. but ijp did some work on that. <cordawyn>I seem to tread upon "problematic" cases every time I dig deeper ;-) <mark_weaver>though scheme doesn't really have "interface definitions", does it? <ijp>the reason I never finished that was because I wasn't quite sure of how the module system worked at the time <mark_weaver>I've never really studied Scheme 48's module system, but apparently it is based on ML's module system, which as I recall supports higher-order modules. <cordawyn>mark_weaver: it's close to the case described in that message, right. But not precisely like that. <cordawyn>to put bluntly, "main" exports function "x", but there's no code for it in "main" <cordawyn>rdf-graph-2 does the same as rdf-graph-1 <cordawyn>while rdf-graphs just define it, without exporting <cordawyn>so, main combined with either of them provides a complete export + definition combo <mark_weaver>in scheme 48, how does the user choose which rdf-graph implementation to use? <mark_weaver>it sounds like the easiest solution is to simply make 'rdf-graph-1' and 'rdf-graph-2' export 'x', and to remove the export from 'main'. <cordawyn>(I'm coming from ruby and haskell land, no scheme experience whatsoever) <mark_weaver>and then users should simply import both 'main' and 'rdf-graph-?'. <mark_weaver>(main) seems like a very bad name for a module though. <mark_weaver>well, if you use the low-level module interfaces, you can certainly do whatever you want. but it might be the only option that uses the high-level interfaces. <mark_weaver>'use-modules' does not provide a way to pass parameters to modules that are being imported, so there's no way to specify which underlying rdf-graph implementation to use when importing 'main'. <cordawyn>1) I have a "main" module which re-exports all modules (well, almost all) <cordawyn>2) I have a module that, let's say, *doesn't* depend on anything, named "rdf" <cordawyn>3) and I have 2 graph implementations that depend on "rdf" <mark_weaver>the other obvious way to do this is to wrap the entire 'main' module within a procedure, where that top-level procedure accepts as argument(s) the rdf-graph procedures. <mark_weaver>that top-level procedure could return another procedure that let's you access all of the inner procedures that you want to export. <mark_weaver>something like (define (make-main-module rdf-proc1 rdf-proc2 ...) [define all inner procs] (lambda (name) (case name ((inner-proc-1) inner-proc-1) ...))) <mark_weaver>it's kind of a classical technique in the scheme world. I don't know off hand how common it is. <cordawyn>I'd like to follow the principle of least surprise, if possible ;-) <mark_weaver>but it shows that scheme doesn't really *need* a module system at all. the main advantage is that it allows you to put more things at top-level, which in turn makes interactive development and debugging more convenient. <mark_weaver>better yet, instead of passing 'rdf-proc1', 'rdf-proc2' ..., just pass in the rdf-module itself, which is itself a procedure that accept a symbol and returns the associated exported procedure (just like the inner lambda in 'make-main-module' above) <mark_weaver>this is one way of making a module system out of closures. <cordawyn>uh, let me copy it all into my notebook :) <cordawyn>mark_weaver: thanks a lot for your help! I'm off to give it a good thinking over ;) <cordawyn>I think I'll go with separate graph modules for now, but will add those tricks to the todo list <mark_weaver>given that main doesn't even use the rdf-graph modules directly, I think that makes sense here. 