<Madsy>Sweet. My assoc list made in C works <Madsy>didi: C bad but fast, Scheme good but slow <Madsy>lol.. evaluatin a bytevector prints the whole thing <Madsy>If you evaluate a bytevector in the REPL <Madsy>It prints all of its contents, no matter the size <Madsy>All I'm saying is that printing the whole bytevector at evaluation is excessive when it's huge <Madsy>When printing other types of lists and arrays, the print function respects a guile limit you can set <zacts>zRecursive: guile2 FreeBSD port almost ready to send as a PR <nalaginrut>mark_weaver: I think open-input-file in r6rs io/simple doesn't define the encoding issue, no? <mark_weaver>it's supposed to be textual. the bug report is spot on. <mark_weaver>the (native-transcoder) argument is being passed where the buffer mode is expected. <mark_weaver>so the transcoder argument to open-file-{input,output}-port is not given, which means binary, which is wrong. <nalaginrut>I think it's because people use open-input-file of toplevel, which could pass #:encoding <nalaginrut>I don't know there's another one in r6rs if I don't see the report <mark_weaver>right, probably not that many people use guile in r6rs mode, and most of them are probably european. <nalaginrut>yes, I use call-with-input-file, but I check the existence of file before <nalaginrut>although I'm willing to accord to RnRs, I think I can't avoid the specific things, for example, keywords, and delimited-continuations <nalaginrut>ok, I confess keywords could be changed with read options <mark_weaver>ideally, I'd like to get in the habit of writing code mostly for R6RS + SRFIs, but using some guile-specific things where needed. <nalaginrut>yes, at least avoiding the portable trouble as possible, now I'm loving record-type in r6rs <nalaginrut>but I still have the habit to use guile specific hashtable <nalaginrut>but anyway, when you picked OOP, you can't avoid Guile specific anymore <zacts>mark_weaver: hey, some FreeBSD porters noticed that guile-2.0 seems to eat up a lot of CPU during the poudriere parallel build process. <zacts>and if it's a guile issue could running a non-parallel build possibly solve the problem? <mark_weaver>so, the issue early in the build is that guile's compiler is written in guile itself. so early in the bootstrap, the compiler itself has not yet been compiled, and is being interpreted. <zacts>mark_weaver: oh sorry, yeah meant to post a link about poudriere <mark_weaver>it is probably true that you'll use fewer CPU cycles total if you build non-parallel. <zacts>cool, I'll test a non-parallel build next. <mark_weaver>zacts: have you heard any reports of compiling 2.0.10 on MacOS X? <zacts>mark_weaver: no, that is outside of my domain. I don't own any OSX computers or virtual machines. Although, I may ask the pkgsrc guys to test guile2 on pkgsrc on OSX when I get around to porting it there. <zacts>my friends who do use OSX either are too busy, or don't know how to build programs. <mark_weaver>(I remember you posting a chat log where people were talking about compiling guile git (master) on OSX) <zacts>mark_weaver: oh yeah, that was probably #freebsd-clang. I didn't attend that. <zacts>let me try asking them, was it dim or someone.. <zacts>oh, and let me try importing i3wm to guix sometime soon. <zacts>I've actually gotten a lot done in regards to porting free software to various platforms. <mark_weaver>zacts: don't spend any time on the OSX thing, I just thought you might already know. <zacts>mark_weaver: oh, nah.. It's not a big deal, dim will let me know, and also pkgsrc automatically tests OSX builds. ***linas_ is now known as linas
<civodul>mark_weaver: so does it sound reasonable to re-release tonight? <mark_weaver>civodul: yes. it might be good to fix the duplicate mkstemp issue, but that's about it. <mark_weaver>(though I'm still confused why Madsy and I didn't run into that. maybe that issue only showed up after f1a13268fdc55a78700317b0e5d68649547db744) <civodul>mark_weaver: re mkstemp, perhaps it depends on the MinGW version <civodul>would be good to see config.log for your build and for the other one <civodul>nevertheless, it's clear that our mkstemp.c is now redundant with Gnulib's <wingo>you have time-zone superpowers :) <mark_weaver>well, I sent the patches I was working on to guix-devel, now it's time for me to sleep. <Arne`>How can I use foof-loop in guile? <Arne`>Is it already shipped, so I can just activate it? <Arne`>I get an error when trying to load it like this: guile -l let-values.scm -l syn-param.scm -l foof-loop.scm <Arne`>foof-loop.scm:865:27: source expression failed to match any pattern in form (in-list lists) <wingo>do you also get that error if you run with GUILE_AUTO_COMPILE=fresh ? <Arne`>GUILE_AUTO_COMPILE=fresh guile -l let-values.scm -l syn-param.scm -l foof-loop.scm <wingo>there is a port of foof-loop in guildhall i think <Arne`>I tried to google that but did not find it <Arne`>but I did not find out how to get the packages <Arne`>(do I need to install guildhall to be able to get the packages?) <civodul>"guild list-packages" shows "wak-foof-loop" <Arne`>I did not find guildhall in Gentoo, so I have to install it manually… <Arne`>After installing guildhall, I get compile errors when trying to run guild <Arne`>ok, found the reason: I executed guild in the guildhall directory. <jmd>How can I represent a newline character in a string? <jmd>thought I tried that ... <ft>it prints as "foo\\nbar" in the repl too. Maybe that confused you. <Madsy_>mark_weaver: What didn't I run into? :) <Madsy_>mark_weaver: Yeah, weird. I've never seen that. Maybe it happened because of how he built libgc? <Madsy_>To see if there are any differences <jmd>What's the easiest way to do a string search and replace? <civodul>mark_weaver: actually Panicz didn't mention when the link error happen :-/ <mark_weaver>civodul: yeah, I noticed that. it would have been helpful. <jmd>A version which takes a list of search/replacement pairs would be even better. <Madsy_>Someone should tell Panicz that if he cross-compiled libgc with ./configure, he's doing it wrong <Madsy_>Bah.. I wish there was a math/linear algebra srfi module <mark_weaver>jmd: it would be much more complex to write if you wanted the obvious semantics of multiple-search/replace pairs, but it's easy to run it more than once (not quite the same thing). <mark_weaver>jmd: I'd be reluctant to make it more complex without going all the way to a shiny new regexp library, and I'm waiting for SRFI-115 for that. <mark_weaver>it's too bad that SRFI seems stalled for the last 3 months. ***didi` is now known as didi
<wingo>anything i can do to help a re-release? <mark_weaver>hmm, dunno! I think it's mostly in civodul's hands now. you could ask him. <civodul>mark_weaver: as far as i can see, libguile/mkstemp.c is actually unused <civodul>so if there's a problem, it's a Gnulib problem <civodul>i'm tempted to punt on that one and rerelease like this <mark_weaver>fwiw, I don't think we should block the release for this. <davexunit>I picture guile releases like a hose with a kink in it. <mark_weaver>davexunit: I think I'm failing to understand the analogy :) <davexunit>the water builds up, and when the kink is removed it all comes rushing out. <mark_weaver>for those who don't use guile from a git checkout, I guess that's what it's like :) <wingo>davexunit: are you saying that 2.0.24 is just around the corner, is that what you're saying <mark_weaver>now, if only we could get more people to test things *before* the release :) <civodul>i read that IPython article in LWN, and thought that we need more eye candy in Geiser <wingo>anyone running master? does the test suite pass for you? <civodul>davexunit: images at the REPL prompt (Racket does that too), plots, etc. <davexunit>civodul: wouldn't we need to add image support to guile like racket has? <mark_weaver>there's an emacs mode for Maxima (a free computer algebra system written in common lisp) called IMaxima, which handles showing images in the emacs interaction buffer with maxima. that might be a good starting point. <mark_weaver>e.g. it can display plots, and also render the results (often equations) using tex and display them inline. <davexunit>gotta go catch the train. I hope those things can be added to geiser! <mark_weaver>with the help of guile-cairo, it should be fairly easy, actually. <lloda>wingo: I've tried master on two boxes. On OS X 10.6.8 w/ gcc 4.8, segfault at test-language and then it hangs (many minutes, I stopped it) in test-stack-overflow. On Ubuntu 12.04, segfault in test-stack-overflow after may 'GC Warning: Failed to expand heap ...' messages & Out of Memory!. <wingo>lloda: i assume it worked for you until recently? <mark_weaver>civodul: it would have been good to mention the R6RS ports fix also, but no biggie :) <tupi`>mark_weaver: opening and displaying image is easier using guile-clutter, imo <tupi`>[which uses guile-cairo of course] <wingo>lloda: if it's 7.4 recall that you need git <wingo>because of a patch that went in there <mark_weaver>sometimes I think we ought to update NEWS with each commit, instead of postponing that job until release time. <wingo>mark_weaver: sure, we can give that a try <wingo>tough to string together a narrative for the release that way, though <lloda>libgc from master. ff6c3d9fb8e7065ffe74cb780b2c1f54868152e2 on one box and 2473707be5dec4cb480b11377a5c4f98edf8a479 on the other when I tried. <wingo>lloda: did master work for you recently? <wingo>test-stack-overflow is new, fwiw <mark_weaver>wingo: well, it would still be good to make some changes to the NEWS at release time. <wingo>i wonder if the setrlimit calls there didn't work for some reason <lloda>I think it did just after the array patches where commited. Can't be sure, but can try. <wingo>lloda: ok, will look into it. thanks :) <wingo>lloda: haha, it's a classic bug regarding order of operands to < <wingo>lloda: on one of your boxes, if you do (getrlimit 'as), what does it return? <lloda>scheme@(guile-user)> (getrlimit 'as) <wingo>so what happens if you (setrlimit 'as (* 100 1024 1024) #f) <lloda>scheme@(guile-user)> (setrlimit 'as (* 100 1024 1024) #f) <lloda>scheme@(guile-user)> (getrlimit 'as) <wingo>and then if you do a (let lp () (lp) #t) it ends up consuming more than 100MB of memory usage? <lloda>scheme@(guile-user)> (let lp () (lp) #t) <wingo>what if you ,o interp #t and try again <civodul>mark_weaver: in the old days NEWS with updated along with each commit <lloda>scheme@(guile-user)> ,o interp #t <lloda>scheme@(guile-user)> (let lp () (lp) #t) <lloda>Warning: Unwind-only `stack-overflow' exception; skipping pre-unwind handler. <wingo>so that's the thing that it should do <wingo>i wonder why when running from make check that they hang or whatever <mark_weaver>civodul: seems to me like a better way to do things. when you make the commit, the issues are fresh in your mind, and it's easier to write a description suitable for NEWS. also, it's incremental, as opposed to a large unpleasant job at the end of the release cycle. <mark_weaver>(I wonder how long 2.0.10 was postponed because no one wanted to do that job :) *wingo doesn't mind doing NEWS at release-time, fwiw <wingo>i find it's easier to place various commits in their place of importance when looking back <mark_weaver>that said, I still like the idea of rearranging and maybe rewriting some things at release time. <mark_weaver>well, it's not that important to me, just an idea :) <wingo>ok will keep it in mind in my commits :) <wingo>lloda: not sure why that is happening tbh; will follow up later on <wingo>for now i need to go afk, happy hacking :) <civodul>mark_weaver: OTOH, one misses the big picture when doing NEWS incrementally <lloda>wingo: sure, let me know if there's something else I can try. <madsy>mark_weaver: Question: Should the bytevector print function really print the whole thing, not matter the size? <lloda>works for me, except on traces... I don't know how to do it on traces. <lloda>well I find the dimensions more useful than a piece of the contents, most of the time. But that's a matter of taste :) <zacts>mark_weaver: segfault on bash-$ guile <zacts>you'll have to do another new release <mark_weaver>there is a print hook, which could do the same job in a much more future-proof way. <mark_weaver>look at 'repl-print' in system/repl/common.scm for the procedure that's replaced by that monkey patch. notice how it looks for a 'print' repl option and calls it to do the printing if it exists. <mark_weaver>it's possible that hartwig did that before the print hook existed. <zacts>so is guile just a scheme wrapper around nix, or does guix now recently reimplement nix also? <mark_weaver>it's much more than just a wrapper. the only common piece is the daemon. <mark_weaver>zacts: I assume you meant to write 'guix' not 'guile'. <zacts>mark_weaver: oh yes, wrong channel also <zacts>I misread the channel list and had a dyslexic moment <zacts>may be FreeBSD/architecture related, but I don't know if this is a known issue. <mark_weaver>zacts: did libgc pass its test suite on that architecture? <zacts>mark_weaver: I'll have to make a new vm and try it. <zacts>(if a vm will work for this) *zacts will test it in a few minutes. <mark_weaver>so that's i386-portbld-freebsd10.0. any other examples of systems that lead to coredumps? <zacts>mark_weaver: yeah, once the rest of my builds are done I'll post the results, but so far FreeBSD-10 i386 and FreeBSD-11 i386 coredump on me. I'll also do another redports build to see if it's possibly just a redports bug. ***linas_ is now known as linas
<zacts>so far I'm getting success on FreeBSD-* amd64 architectures. <mark_weaver>it's possible that there's an issue on i386, in either guile or libgc. it's fairly rare to generate code for that architecture. most use i686 nowadays for 32-bit. <zacts>mark_weaver: well, I highly doubt that i386 FreeBSD is truely i386 and not i486 or i686.. <zacts>NetBSD i386 arch is actually i486 and beyond for example, even though they retain the i386 name <mark_weaver>zacts: well, the configure script outputted: "checking host system type... i386-portbld-freebsd10.0". <mark_weaver>I'm not an expert on build systems, but generally that first component specifies the baseline that limits what instructions can be emitted. but the more relevant question is what that first component was when the compiler was built. <mark_weaver>although clang may interpret those things differently. <mark_weaver>but it might affect the code included by libgc, for example. and i386 might not be very well tested. <mark_weaver>interesting that it's only the newer versions of freebsd that have a problem in i386. <zacts>yeah, that's what I thought. <mark_weaver>what compilers are used in those version of freebsd? <zacts>mark_weaver: I'm going to run another build with the same settings, and we'll see if it works. if so I'm guessing it's a redports bug, or some parallelization issue. <zacts>mark_weaver: just a sec. I know that 10-i386 and 11-i386 use some form of a fairly recent clang <zacts>3.2 / 3.3 / 3.4 <- let me double check on this 