IRC channel logs


back to list of logs

***turbofai` is now known as turbofail
***ultrakebab is now known as ResistLennart
<civodul>Hello Guilers!
<wingo>morning :)
<ArneBab>wingo: recap on yesterday: if I use the actually equivalent python-code (looping over the file contents), the Python needs 8.4s, compared to 2.1s in Guile.
<ArneBab>So the pure scheme let recursion wins by factor 4 over the pure Python loop.
<ArneBab>(i. 2.1.3, in 2.0.11 Guile wins by a bit more than factor 2)
<wleslie>iwbni bytevector-procedures:bytevector-index &c took an index to start from
<wleslie>thinking from the perspective of implementing boyer-moore
<wingo>i am reminded of why i think ltdl is terrible dependency for us to have
<wingo>5 years, no reply.
<wleslie>you did write about this.
<ArneBab>wleslie: I added that today
<ArneBab>wingo: maybe your own blog post applies there: If we’re using something, we need to be somewhat active there.
<wingo>i don't care to be active there
<wingo>i would rather incorporate the functionality into guile
<wingo>civodul: if you have any followup thoughts re: that canonicalize-path thing, they are welcome
<wingo>it seemed to me that canonicalize-path was off the hot path, but maybe i am misunderstanding
<civodul>wingo: i just replied :-)
<civodul>(i think?)
<wingo>ah ok :)
<wingo>between gnus and debbugs-gnu it's hard to remember what's up to date
<wingo>there was a thread recently that spanned user, devel, and two bugs
<wingo>clownshoes :P
<civodul>heh :-)
<civodul>ACTION uses M-x debbugs-gnu
<wingo>ACTION too
<wingo>super useful
<wingo>though i could probably use it better
<wingo>yarrr, ,trace does not appear to work in 2.1.3
<wingo>can people reproduce that?
<lloda>it doesn't seem to do anything
<lloda>wingo: I'm at test-stack-overflow on my linux box and the mac. getrlimit/setrlimit seem to work the same in both. But on the mac (test) starts eating up memory and never terminates. Where do I poke?
<wingo>lloda: hmm
<wingo>let me check
<wingo>lloda: can you strace on a mac?
<wingo>if so i would strace the process
<wingo>stack should be being allocated via mmap
<wingo>and then freed via madvise
<lloda>there is no strace on the mac. There is dtrace, but tbh I don't know how to use either :-/
<wingo>so, test-stack-overflow will try to use all your stack
<wingo>actually all your memory. maybe that throws macos into conniptions
<wingo>maybe it tries to swap?
<wingo>maybe we try to wrap around the address space? not sure
<civodul>lloda: IIRC the strace equivalent is "dtruss"
<wingo>ah right, the rlimit should limit us to a certain amount of memory
<wingo>maybe the rlimit that we apply doesn't apply to anonymous mmap pages?
<wingo>lloda: can you edit the test to print out the original soft and hard limits and then the new soft and hard limits?
<wingo>i have the feeling that the mmap is always succeeding somehow and that the rlimit isn't limiting the mmap
<wingo>that's my guess
<wingo>lloda: lmk if you need more speculation
<lloda>before #f #f
<lloda>after 104857600 #f
<lloda>that's the same as in Linux
<lloda>ok so I can run dtruss
<lloda>this stuff is dangerous :-O
<wingo>lloda: another option. run the test in a debugger and break on scm_report_stack_overflow
<wingo>see if it ever triggers
<lloda> is the dtruss trace
<lloda>had to edit it, I killed the process after the last mmap
<lloda>trying w/ debugger now
<wingo>i don't understand why it maps 0x1000
<wingo>ah i do see a phase where it's doubling
<wingo>there's a part of the trace that's like this:
<wingo>that's the main loop of the test but all of the mmap's succeed in spite of the rlimit that was set
<wingo>like you shouldn't be able to have a successful mmap of 0x40000000 bytes if you have set an rlimit of 0x6400000 bytes
<wingo>and then it spawns a thread? what's that about
<wingo>i guess some crash monitor or something?
<lloda>there was no crash until I killed the process myself
<wingo>there's this:
<wingo>no answer tho...
<wingo>i am thinking maybe setrlimit just doesn't work on os x
<wingo>i guess we could write a little c program to test or something
<lloda>I read that one needs to set RLIMIT_DATA in addition to RLIMIT_AS or?
<wingo>i don't think so, i think that's nominally for memory allocated via brk(2) not mmap(2)
<wingo>written by bruno :)
<wingo>says that setrlimit just doesn't work on the mac.
<civodul> doesn't mention MacOS
<lloda>this is... uf.
<wingo>consensus seems to be that setrlimit just doesn't work to limit memory on os x
<wingo>which, ok. i guess we can add an exception to the test to just error out
<lloda>seems so :-/
<wingo>or return 'skipped / unresolved whatever
<wingo>same with the out-of-memory test
<wingo>lloda: what's your %host-type?
<wingo>or how do i check for mac os anyway
<lloda>I was thinking about that
<lloda>whether to rely on autoconf or
<lloda>just check uname
<lloda>(car (uname)) = "Darwin"
<lloda>I guess I can't (throw 'unresolved) in these standalone tests?
<wingo>i think you can
<wingo>exit 77
<wingo>i think that will skip the test
<random-nick>what do I use to wait some time in guile? do I use the sleep procedure from the POSIX bindings?
<wingo>ok so you're on it, great :)
<wingo>random-nick: yep, or usleep
<wingo>usleep probably
<dsmith-work>Happy Friday, Guilers!!
<wleslie>Happy Friday dsmith-work!
<wleslie>(and happy Friday/Saturday Guilers!)
<lloda>wingo: I'll send a patch after I rebuild and run the suite from the top
<wingo>lloda: great. fwiw i think it's ok to just patch the test case
<wingo>to make an early return
<lloda>yeah I did
<lloda>;; setrlimits are ignored in OS X (tested on 10.9 and 10.10). Proceeding
<lloda>;; with the test would fill all available memory and probably end in a crash.
<lloda>(when (string-ci= "darwin" (vector-ref (uname) 0))
<lloda> (exit 77))
<lloda>just want to see that the test is reported unresolved
<lloda>I saw a report of setrlimit being ignored back in 2003. Ah Apple... >:-/
<wleslie>apple: no limits
<lloda>ok, those two tests skip as they should. ok to push?
<dsmith-work>Is there a Darwin os? Wonder if that bug is in there too?
<dsmith-work> I guess
<lloda>this bug is in the BSD layer so I would think it's there too
<wingo>bah i seem to have added a pk somewhere :P
<wingo>ah no it was there :)
<wingo>lol at this error tho
<wingo>While compiling expression:
<wingo>ERROR: badness! #<module (#{ g159}#) 9702d0> %exception-handler
<lloda>ok to push the patch above?
<lloda>I also confirm the bug with sign of zero reported by Cristopher White
<lloda>on Linux:
<lloda>scheme@(guile-user)> 1.0@-0.0
<lloda>$1 = 1.0-0.0i
<lloda>on OS X:
<wingo>lloda: lgtm
<lloda>scheme@(guile-user)> 1.0@-0.0
<lloda>$1 = 1.0+0.0i
<wingo>what! so weird
<lloda>ok I'll push & close the bug
<lloda>ok so the setrlimit bug was posted to guile-devel so there's no real bug, no need to close
<wingo>finally figured out how to resuscitate a previous commit log in magit
<wingo>by accident
<wingo>and C-M-p
<wingo>too bad, almost ;)
<lloda>who wants more OS X bugs ? I have some
<lloda>test-language fails b/c --language=elisp -l test-language.el segfaults
<lloda>same with --language=ecmascript -l test-language.js
<wingo>can you ,L elisp at the REPL?
<lloda>just opening with --language=ecmascript and pasting the code in the REPL works fine
<wingo>do you have a backtrace of the segfault?
<lloda>sorry, ,L and paste also works fine
<GreySunshine>I created a module test_module.scm ( and a script use_module.scm ( Both module and the script are in the same directory. I tried to run the script with this command "guile use_module.scm". I get this error , for all I can understand the s
<GreySunshine>cript is not able access the module. please help!
<lloda>The module name is relative to the %load-path. So a module called (a b c) needs to be somewhere-in-load-path/a/b/c.scm
<lloda>gotta leave! bon we Guilers
<GreySunshine>what if they are in the same directory?
<dsmith-work>GreySunshine: Also note that '.' is not on the %load-path. (For the same reasons '.' in not on the $PATH)
<dsmith-work>GreySunshine: So to repeat lloda: If yoy have a module (a b c) , the filename on disk *must* be a/b/c.scm , and that must be on the %load-path
<wingo>ecraven: you been able to check if guile was compiled right?
<GreySunshine>I did this "GUILE_LOAD_PATH=$GUILE_LOAD_PATH:/home/nightfury/Code/" now that I have added the current directory in path it still doesn't work.
<spk121>GreySunshine: you could add (write %load-path) to the top of your script to see if GUILE_LOAD_PATH is working
<GreySunshine>yes I did GUILE_LOAD_PATH, now it works!
<wingo>holy crap this time-related bugs from zefram are detailed!
<GreySunshine>thanks so much for helping me!
<random-nick>hmm, what can I use to transport strings for processing from one thread to another?
<random-nick>are ports usable for that?
***ResistLennart is now known as xXNSyncLover1997
***xXNSyncLover1997 is now known as _NSyncLover1997_
<dsmith-work>Seems like more guile mails in the last few days than in the last year..
***_NSyncLover1997_ is now known as IslamicScholar
***madsy__ is now known as Madsy
<random-nick>hmm, how do I read on sockets only when there is something to read?
<dsmith-work>random-nick: select
<mark_weaver>wingo, lloda: I vaguely recall hearing that OS X automatically creates new swap files on-demand in case of OOM.
<random-nick>dsmith-work: thanks
<dsmith-work>random-nick: If you are unfamilar with select, this might help:
<dsmith-work>random-nick: But that's the C system call interface, not Scheme...