***_zxq9_ is now known as zxq9
<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 <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. <nalaginrut>mark_weaver: "madvise failed: Function not implemented" loop forever <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 <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>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 <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 <mark_weaver>while you're editing vm.c, that "-EAGAIN" on line 918 should have the '-' removed. <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__ <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. <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 <nalaginrut>hmm...at 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. <mark_weaver>well, madvise returning -1 with errno set to ENOSYS is a run-time failure, yes. <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>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>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`>100.00 0.77 0.77 anon #x7f6371cbf9a4 <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>at the very least we should add source info to "anon ..." with <lloda`>can the address be used to retrieve source info manually? <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 :) *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 <civodul>just yesterday i was thinking this should be improved <civodul>mark_weaver: BTW, that chunked-encoding bug i reported is what prevents proper progress reports when downloading from hydra.gnu.org <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) <wingo>there is a message from 24 feb <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." *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)