***turbofai` is now known as turbofail
***ultrakebab is now known as ResistLennart
<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 <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 <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>though i could probably use it better <wingo>yarrr, ,trace does not appear to work in 2.1.3 <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: can you strace on a mac? <wingo>if so i would strace the process <wingo>stack should be being allocated via mmap <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 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>lloda: lmk if you need more speculation <wingo>lloda: another option. run the test in a debugger and break on scm_report_stack_overflow <lloda>had to edit it, I killed the process after the last mmap <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>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>says that setrlimit just doesn't work on the mac. <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 <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>whether to rely on autoconf or <lloda>I guess I can't (throw 'unresolved) in these standalone tests? <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 :) <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 <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>just want to see that the test is reported unresolved <lloda>I saw a report of setrlimit being ignored back in 2003. Ah Apple... >:-/ <dsmith-work>Is there a Darwin os? Wonder if that bug is in there too? <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>ERROR: badness! #<module (#{ g159}#) 9702d0> %exception-handler <lloda>I also confirm the bug with sign of zero reported by Cristopher White <lloda>scheme@(guile-user)> 1.0@-0.0 <lloda>scheme@(guile-user)> 1.0@-0.0 <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 <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 <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 <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 <wingo>holy crap this time-related bugs from zefram are detailed! <random-nick>hmm, what can I use to transport strings for processing from one thread to another? ***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? <mark_weaver>wingo, lloda: I vaguely recall hearing that OS X automatically creates new swap files on-demand in case of OOM. <dsmith-work>random-nick: But that's the C system call interface, not Scheme...