IRC channel logs


back to list of logs

***_zxq9_ is now known as zxq9
<nalaginrut>morning guilers~
<nalaginrut>guile-2.1+ uses `madvise', which hasn't implemented in Hurd...
<mark_weaver>nalaginrut: that entire function 'return_unused_stack_to_os' is optional. notice how the entire body is within an #ifdef
<nalaginrut>mark_weaver: how could I avoid it
<mark_weaver>it just tells the kernel that we don't need the data in that region anymore, so it can be forgotten and zeroed the next time it's paged in.
<mark_weaver>nalaginrut: well, for now you could just change #if HAVE_SYS_MMAN_H to #if 0
<nalaginrut>mark_weaver: what options can I pass to configure so that I can compile it?
<nalaginrut>mark_weaver: oh, seems I have to modify the code?
<mark_weaver>a better fix would be to add some autoconf test to check if the feature is available or not.
<mark_weaver>nalaginrut: what compile error do you get?
<mark_weaver>nalaginrut: is MADV_DONTNEED undefined?
<mark_weaver>or is it a runtime error?
<nalaginrut>mark_weaver: "madvise failed: Function not implemented" loop forever
<nalaginrut>no, it's in compiling time
<mark_weaver>so it compiles successfully but prints that error forever when you run?
<nalaginrut>I don't know if it's successful, you know .go files needs very long time, I break it
<mark_weaver>nalaginrut: oh, I see.
<mark_weaver>nalaginrut: so it doesn't loop forever then.
<mark_weaver>the error message should be harmless, just annoying
<nalaginrut>mark_weaver: it'll print every second while compiling .go, anyway, I wish it won't hurt anything
*nalaginrut compile it again
<mark_weaver>nalaginrut: it should be harmless, but one possible fix for now would be to change "if (ret)" to "if (ret && errno != ENOSYS)" on line 920 of vm.c
<nalaginrut>mark_weaver: should we check it in configure? I don't know if it's necessary to have it in 2.2
<mark_weaver>dunno, I think this fix would be okay too
<mark_weaver>nalaginrut: can you try my suggested fix and let me know if it fixes the problem?
<nalaginrut>mark_weaver: yes, I'll try it then, it's not so fast to compile under Hurd at present since I can't take advantage of multi-core
<nalaginrut>but it's fast and stable than before
<mark_weaver>no need to recompile any .go files that you already have. the messages will be harmless.
<nalaginrut>it's fresh compiling since I just installed latest Hurd, so I have to endure .go
<mark_weaver>I'm glad to hear that progress is being made on the Hurd. I'm looking forward to trying it when Guix supports it.
<nalaginrut>yes, I'm surprised to try the latest version, it runs smoothly and faster
<nalaginrut>last time I tried it, I have to stop play after several no-reason halt
<nalaginrut>now it's better
<mark_weaver>that's good news!
<nalaginrut>indeed ;-)
<mark_weaver>while you're editing vm.c, that "-EAGAIN" on line 918 should have the '-' removed.
<mark_weaver>I'll fix these soon.
<nalaginrut>mark_weaver: ok
<mark_weaver>(that -EAGAIN fix will not affect you anyway, and would be relatively harmless on any system)
<nalaginrut>for better solution, I'm going to ask Hurders if it's possible to implement madvise
<nalaginrut>mark_weaver: madvise is just a stub in Hurd, how about this fix: if HAVE_SYS_MMAN_H || !__MACH__
<nalaginrut>just avoid this code under Hurder
<nalaginrut>oops, !__gnu_hurd__ is better
<mark_weaver>nalaginrut: I think that's a worse solution, because it means that even after the Hurd adds support for madvise, Guile 2.2 will continue to assume that Hurd doesn't have the features.
<mark_weaver>and anyway, it would be "&& !", not "|| !"
<mark_weaver>but I still think it's a bad idea
<nalaginrut>ah yes, it's && !, my mistake
<nalaginrut>mark_weaver: or maybe we can define __HAS_MADVISE__ in config.h while configure
<mark_weaver>what problem are you trying to solve that my proposed fix doesn't solve?
<mark_weaver>we could do a configure check, but it has the disadvantage that if the Hurd ever gains madvise, then Guile won't be able to take advantage of it until the next time it's recompiled.
<mark_weaver>which might be a long while if that compiled guile is in debian stable, for example.
<nalaginrut>mark_weaver: the previous fix hide details "madvise is missing", personally I prefer check it explicitly, but it's unnecessary
<mark_weaver>your proposed fix would also "hide" that fact.
<nalaginrut> least hackers may see __HAS_MADVISE__ for hint under certain case
<mark_weaver>well, the great thing about free software is that you can do what you want in your own tree :)
<nalaginrut>mark_weaver: just suggestion, I won't insist on it ;-)
<mark_weaver>it's a run-time failure, not a compile-time failure. run-time failures can be temporary. I don't want to assume that an ENOSYS returned on the build system implies that ENOSYS will always be returned on the system the code is run on later.
<nalaginrut>oh, it's run time?
<mark_weaver>well, madvise returning -1 with errno set to ENOSYS is a run-time failure, yes.
<civodul>Hello Guilers!
<artyom-poptsov>Hi civodul
<wingo>meep meep
<lloda`>wingo, hi
<wingo>heya lloda`
<lloda`>question about profile lines like 'anon #x7f6371cbf9a4', is that new in master? I don't remember seeing that before, didn't we have source info for anonymous lambdas?
<wingo>that's new yes -- you don't get source info as well?
<wingo>thing is, in master, slot 0 is not always the procedure
<wingo>so you have to key off the IP
<wingo>and you might not have the closure object around
<wingo>and indeed there might not be a proper closure object in some cases
<wingo>due to closure optimization
<wingo>however from the ip you should be able to get name, source location, etc
<wingo>but "anon #x...." means that no name was found for that closure
<wingo>there might be source info though, that's usually displayed out to the right i think?
<wingo>or perhaps not
<wingo>we should try to do better at profiling line numbers
<wingo>it won't work in general for the newest frame on the stack, because profiling ticks are only processed on function call, return, and on loop back-edges, but it will accurately sample the source location for other frames on the stack
<lloda`>I don't get anything else, unless there's some option I'm missing (I just do ,profile sexpr)
<lloda`>the whole line is
<lloda`>100.00 0.77 0.77 anon #x7f6371cbf9a4
<wingo>interesting :)
<wingo>so probably we should display source info then
<wingo>seems it's not being displayed
<wingo>it's hard to fit into normal terminal widths
<wingo>but we should try i guess
<wingo>at the very least we should add source info to "anon ..." with
<wingo>s/ with//
<lloda`>can the address be used to retrieve source info manually?
<lloda`>how :D
<wingo>somehow things aren't being plumbed correctly...
<wingo>you should read statprof.scm, it's interesting :)
<wingo>don't look at stable-2.0 tho, master is much more pleasant :)
<lloda`>I ditched 2.0 a while ago :D
*civodul just ported wingo's GDB pretty-printer improvement to 2.0
<civodul>it's much better esp. when it comes to printing loooong bytevectors or strings in GDB
<mark_weaver>oooh, nice!
<civodul>just yesterday i was thinking this should be improved
<civodul>i'm glad he already did it
<civodul>mark_weaver: BTW, that chunked-encoding bug i reported is what prevents proper progress reports when downloading from
<mark_weaver>civodul: okay, I'll take a look, thanks!
<mark_weaver>civodul: btw, any idea why bug-guile is no longer on gmane?
<mark_weaver>(recently I've started mostly reading development lists on gmane)
<mark_weaver>I also just noticed that David Kastrup filed a bug report relating to the smob marking.
<mark_weaver>wingo, civodul: ^^
<wingo>mark_weaver: ?
<wingo>there is a message from 24 feb
<wingo>mark_weaver: does dak's thing relate to the mail i sent to the ?
<wingo>i wonder if enabling topological finalizatoin fixes his issues
<wingo>specifically "running the finalizer of object O1 which
<wingo>links to finalizable object O2 could see O2 after O2's finalizer has
<wingo>been run, because finalizers are unordered."
<wingo>and the following paragraph
*taylanub has zero actual experience with finalizers but the safety&correctness pedant on his shoulder is bickering him to lobby for topological order :P
<mark_weaver>wingo: not sure off hand, I haven't yet read his bug report. got my hands full with children right now.
<civodul>mark_weaver: it's still on gmane, isn't it?
<mark_weaver>civodul: I don't see bug-guile on gmane, and ttn posted asking about it a while ago as well (on guile-user)
<mark_weaver>do you see it?
<civodul>yes, see:
<civodul>my Gnus sees it as well
<mark_weaver>ah yes, I see it now.