IRC channel logs


back to list of logs

<Madsy>Sweet. My assoc list made in C works
<didi>C, bad. Scheme, good.
<zRecursive>C not bad, C dominates the whole IT world
<zRecursive>C+scheme(guile) is a good combination though
<Madsy>didi: C bad but fast, Scheme good but slow
<zRecursive>If no C, then no unix, no www, ...
<Madsy>lol.. evaluatin a bytevector prints the whole thing
<Madsy>No matter how long it is
<zRecursive>what ?
<Madsy>If you evaluate a bytevector in the REPL
<Madsy>It prints all of its contents, no matter the size
<zRecursive>any code ?
<Madsy>Using 2.0.10
<zRecursive>Madsy: do you want "lazy" evaluation ?
<Madsy>zRecursive: Huh?
<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
<Madsy>I don't remember the name
<zRecursive>it is "strict" evaluation
<zacts>zRecursive: guile2 FreeBSD port almost ready to send as a PR
<zRecursive>zacts: great
<nalaginrut>morning guilers~
<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>I have a fix, will push soon.
<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.
<mark_weaver>I'm surprised no one ever noticed before now.
<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>I confess I used a lot Guile specific things
<zRecursive>i am used to use 'call-with-input-file
<mark_weaver>me too
<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>I do think I should change it
<nalaginrut>but anyway, when you picked OOP, you can't avoid Guile specific anymore
<mark_weaver>true, but I rarely use OOP
<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>is this normal / expected?
<zacts>and if it's a guile issue could running a non-parallel build possibly solve the problem?
<mark_weaver>nevermind, I found what that is.
<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>okay, I just thought I'd ask.
<zacts>no problem
<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>ok, I'll ask around.
<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>Hello Guilers!
<mark_weaver>hi civodul!
<nalaginrut>hi ludo
<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)
<mark_weaver>civodul: fyi, there's one other bug that I just fixed in stable-2.0:
<civodul>ah yes
<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
<civodul>hello wingo
<wingo>you have time-zone superpowers :)
<mark_weaver>heh :)
<Arne`>hi ☺
<mark_weaver>I'm a fool for still being awake :)
<mark_weaver>well, I sent the patches I was working on to guix-devel, now it's time for me to sleep.
*mark_weaver --> zzz
<wingo>sleep well
<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>hum, dunno
<wingo>there is a port of foof-loop in guildhall i think
<Arne`>I tried to google that but did not find it
<Arne`>where can I get thaat?
<wingo>ijp ?
<Arne`>the package manager is here, I think:
<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?)
<wingo>i think so, yes
<Arne`>ah, found it:
<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`>english version:
<Arne`>ok, found the reason: I executed guild in the guildhall directory.
<wingo>strange reason :)
<jmd>How can I represent a newline character in a string?
<ijp>\\n as usual
<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?
<mark_weaver>unlikely. my guess is that it might have been because of;a=commitdiff;h=f1a13268fdc55a78700317b0e5d68649547db744
<mark_weaver>which was after we did our tests
<mark_weaver>or maybe a different version of mingw
<Madsy_>Maybe he should try my howto
<Madsy_>To see if there are any differences
<jmd>What's the easiest way to do a string search and replace?
<mark_weaver>jmd: I suppose we should add something like that to guile. Here's a very efficient one I wrote that has gotten some use. feel free to use it.
<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
<Madsy_>Guess I have to make my own
<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>meep meep
<wingo>greets :)
<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.
<mark_weaver>the one remaining issue that would be good to look into is this:
<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.
<civodul>let's do it, then
<civodul>wingo: fine with you?
<mark_weaver>I think we could release any time.
<mark_weaver>(e.g now :)
<civodul>ok :-)
<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.
<wingo>civodul: works for me
<mark_weaver>ah, yes :)
*civodul updates NEWS
<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
<davexunit>I joke, of course, but yes, exactly.
<mark_weaver>okay, now I finally understand :)
<mark_weaver>now, if only we could get more people to test things *before* the release :)
<civodul>damn, jao left
<civodul>i read that IPython article in LWN, and thought that we need more eye candy in Geiser
<davexunit>civodul: what kind of eye candy?
<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.
<civodul>2.0.11 is out!
<mark_weaver>civodul: cool, thanks!
<civodul>you're welcome
<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?
<wingo>which libgc do you have?
<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 :)
<lloda>happy to help
<lloda>where/were, argh
<wingo>lloda: haha, it's a classic bug regarding order of operands to <
<wingo>maybe not
<wingo>sometimes i confuse myself!
<wingo>lloda: on one of your boxes, if you do (getrlimit 'as), what does it return?
<wingo>(two values)
<lloda>scheme@(guile-user)> (getrlimit 'as)
<lloda>$1 = #f
<lloda>$2 = #f
<wingo>so what happens if you (setrlimit 'as (* 100 1024 1024) #f)
<wingo>then (getrlimit 'as)
<lloda>the same on the other.
<lloda>scheme@(guile-user)> (setrlimit 'as (* 100 1024 1024) #f)
<lloda>scheme@(guile-user)> (getrlimit 'as)
<lloda>$3 = 104857600
<lloda>$4 = #f
<lloda>the same on the Mac, also
<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)
<lloda>While compiling expression:
<lloda>ERROR: Stack overflow
<wingo>while compiling expression!
<lloda>what it says ;p
<civodul>mark_weaver: right, oh well
<wingo>what if you ,o interp #t and try again
<civodul>mark_weaver: in the old days NEWS with updated along with each commit
<civodul>*very old
<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.
<lloda>ERROR: Stack overflow
<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>to make it more of a nice narrative, as you say.
<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
<civodul>so it has pros and cons, i think
<mark_weaver>zacts: 2.0.11 is out now!
<lloda>wingo: sure, let me know if there's something else I can try.
<zacts>mark_weaver: sweet!
<madsy>mark_weaver: Question: Should the bytevector print function really print the whole thing, not matter the size?
<mark_weaver>madsy: by default, yes.
<lloda>madsy: I use some run-hook before-print-hook thing that D. Hartwig posted on guile-user, maybe you can use that.
<lloda>works for me, except on traces... I don't know how to do it on traces.
<lloda>I mean errors. Well.
<mark_weaver>there's 'truncated-print' in (ice-9 pretty-print).
<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>reproducable. guile-2.0.11
<zacts>you'll have to do another new release
<lloda>getting closer to 2.0.24
<zacts>(totally joking)
<mark_weaver>heh :)
<madsy>lloda: Thanks :)
<lloda>you're welcome!
<civodul>goto night/day!
<mark_weaver>madsy, lloda: fwiw, is a monkey patch. it simply replaces an internal procedure in guile.
<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>(and the general architecture of the store)
<mark_weaver>zacts: I assume you meant to write 'guix' not 'guile'.
<mark_weaver>but this is a discussion for #guix, not #guile
<zacts>mark_weaver: oh yes, wrong channel also
<zacts>I misread the channel list and had a dyslexic moment
<mark_weaver>np :)
<zacts>mark_weaver: ok, so I'm getting a coredump on certain architectures.
<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?
<mark_weaver>it would be good to have a backtrace
<zacts>mark_weaver: I'll have to make a new vm and try it.
<zacts>(if a vm will work for this)
<mark_weaver>I expect it would
*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>admittedly these are just guesses...
<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>I guess that's related to the compiler in use.
<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.
<mark_weaver>I'm guessing a clang 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
<zacts>mark_weaver: <- the other log that coredumped
<mark_weaver>zacts: thanks
<zacts>sure, just a sec..