***michel_mno_afk is now known as michel_mno
***michel_mno is now known as michel_mno_afk
<please_help>I have a really weird error where if I use a function from my library in guile, I go out of memory and segfault, whereas if I copy-paste that function at the repl, it works just fine. Where do I start looking for the cause of such a problem? <please_help>the only difference I can think of is that the library was written before a change of lib version and I rely on an ffi, but I cleared the cache since then. <please_help>I literally copy-pasted everything that was needed straight from my codebase without any modification and it works just fine, I have no idea what's going on at all. <please_help>with 2.0.9 by the way, 2.0.11 breaks the FFI for me. <mark_weaver>well, for starters, it would be good to know why 2.0.11 breaks your code. one option there would be to do a 'git bisect' to determine which commit broke your code. <mark_weaver>another suggestion would be to find an example that fails consistently, and then try to incrementally simplify it until you have a minimal test case that demonstrates the problem. <mark_weaver>if you can provide a small self-contained example that demonstrates the problem, then it would be feasible for me to look into it. <mark_weaver>because it's not sustainable for you to use 2.0.9 forever, and it might uncover a bug in your code (or ours) that would solve the other problem. <mark_weaver>and because git bisect, while tedious, is almost entirely mechanical. you might even be able to automate it. <please_help>mark_weaver, it simply fails to dynamic-link with a segfault, and I don't see any difference in the docs about the FFI API so I assume it's a bug. Given that the same library is used in both test-cases, the problem can't be there. I'll go ahead and make a minimal test-case for that but you might need to grab the relevant library yourself if you care about checking it. I don't think I can provide a minimal test-case for the <please_help>general problem with 2.0.9 because as I said, I copy-pasted without modifications and the problem magically disappears. After having a testcase for the FFI problem, I'll go bisect. <mark_weaver>please_help: what's the first error message you see? <mark_weaver>it might not be because automake is too old, but rather because you are missing .m4 files from other packages that autoconf needs. <mark_weaver>you wrote: "Given that the same library is used in both test-cases, the problem can't be there." That's faulty reasoning. <mark_weaver>some bugs show themselves, or not, depending on the precise details of a running process. <please_help>mark_weaver: starts at configure.ac:41: error: possibly undefined macro: AM_INIT_AUTOMAKE <please_help> If this token and others are legitimate, please use m4_pattern_allow. <paroneayea>"follow this tutorial" would be a nice thing to say, eventually! ***Shozan is now known as SHODAN
<amz3>ah yes follow this tutorial thing <amz3>or maybe convert some lisp/clojure kata to guile <amz3>I wil maybe write something <amz3>but I still need to finish/get back to complete the planet <amz3>while build ffi binding for wiredtiger in python, I discovered a potential source of a bug. <amz3>wiredtiger does "insert" inside the database in two steps first you (cursor-key-set cursor key) and (cursor-value-set cursor value) and then you do (cursor-insert cursor) to actually "put" something in the database. <amz3>So in python cffi, between the eqv of (cursor-set-key) and (cursor-insert) the key and value was gc'ed and in the best case garbage was inserted in the database <amz3>To avoid the values to collected, I had to keep a reference to them <amz3>Long story short, I'll use sqlite <please_help>mark_weaver: I don't have the FFI problem with 2.0.11 anymore. I might be confusing 2.1 and 2.0.11, although then I'm not sure why I wasn't on 2.0.11 already. Eitherway, I have the same problem as in 2.0.9 with this codesegment that works only when copy-pasted and isolated. <please_help>also the full error is: GC Warning: Failed to expand heap by 5153960890368 bytes <please_help>GC Warning: Failed to expand heap by 5153960759296 bytes <please_help>GC Warning: Out of Memory! Heap size: 17 MiB. Returning NULL! <Jaood>will r7rs be implemented in Guile? <sneek>Welcome back Jaood, you have 1 message. <daviid>wrt 'need help learning...' it would be cool to have some Guile Rocks! videos <Jaood>cB8Pe~gAd53DEEHgbugUkFSHtzzLqnYlbs,AQACAAE/random_babcom/103/#WhyGNUGuile <please_help>mark_weaver: it seems I found the source of the problem: printing. I suspect an infinite loop is going on (such as trying to print the object as part of the print procedure). But why is it happening now and never before? <please_help>alternatively, could it be legitimate heap exhaustion? My objects can be very big in text form. <please_help>actually not related to printing per se it seems, even without printing it crashes. However, I can get correct objects to be created without a crash where if I try to print them, via either repl or format, it will crash. <mark_weaver>the default printer will diverge if given cyclic data <Jaood>can you guys sell me on Guile over Racket? <amz3>Jaood: guile is better :> <mark_weaver>my impression is that Racket is more of a static system, in the sense that you can't redefine most existing procedures and have the rest of the system start to use your newly rebound version. <mark_weaver>but if you want more of a living system, closer in spirit to Emacs, where the entire system is hackable while it runs, then Guile is better suited <mark_weaver>for what it is, Racket is a great system. I admire it a lot. but it's based on a different philosophy <mark_weaver>in the Foreword to Structure and Interpretation of Computer Programs, the classic introductory computer science textbook book based on Scheme (by one of its founders), Alan Perlis wrote: "Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of <mark_weaver>In my opinion, Racket has abandoned some of Lisp's dynamicism and is more geared toward making static systems. <Jaood>mark_weaver: pardon my noobness but why will you want to modify Guile itself while it runs? <mark_weaver>I'm not talking about modifying Guile itself, but even the system you are working on. <Jaood>by system, you mean the application one is working on? <mark_weaver>last I checked, by default in Racket, procedures cannot be redefined without restarting the program, unless they were specially written to allow it. <mark_weaver>and the modern scheme standards are going in the direction as well, I should add <mark_weaver>in both R6RS and R7RS, any binding that is export from a module must be immutable. <mark_weaver>the only top-level variables that can be mutable are ones that are private to a single module <mark_weaver>there are pros and cons to both approaches; it depends on what you're working on. <Jaood>is restarting the system your strong point here then? <amz3>I did not understand his point <mark_weaver>I'm sorry, but I don't have a horse in this race, so I don't have any particular motivation to "sell you" on Guile. <mark_weaver>if you don't find anything I've said persuasive, then use Racket. it's a good system too. <Jaood>I mean, both allow extending the core language and add new functionalty with libraries <amz3>Jaood: my point of view might not be a big help, but I think that outside the VM and language the community is also a strong point to take into account. Have a look at the community and see which one works on project you are the most interested in <mark_weaver>I have neither the time nor interest in being a salesman. <Jaood>mark_weaver: sorry If sounded rude, that was not my intention, I appreciate everything you said <Jaood>you gave me something to think about <amz3>when I had a look at racket, outside the language as a learning tool, there doesn't seem to be much activity <mark_weaver>Jaood: okay, no worries. happy hacking, whichever system you choose :) <Jaood>amz3: what kind of activity do you see in the Guile community? <taylanub>ACTION needs to get back to Guix hacking :\\ <Jaood>yeah, been wanting to try Guix as a package manager first <taylanub>I'm using it on Debian. really easy to install with the drop-in binary tarball. <Jaood>and starting to get "down the rabbit hole" ;) <taylanub>Jaood: if you start writing Emacs Lisp, you'll come to appreciate how easy it is to re-execute a function definition to which you just made changes, having said changes take effect immediately within the running Emacs session. that's a really great ability during development, and similar to Emacs, Guile allows it with Scheme code. <Jaood>yeah, got it, didn't know Racket doesn't allow that, I guess that is why in racket-mode emacs, racket-mode just restarts everything when you make a change giving you a new clean state, which I find convenient, it doesn't take long either <Jaood>but I can see the usefulness for a application like an editor <mark_weaver>it depends whether you have any state in the program's data structures that you don't want to dump. <mark_weaver>for example, if you had to restart emacs every time you modified a binding, that would be terrible <mark_weaver>and similarly, with an interactive computer algebra system like maxima it wouldn't be very good either. <mark_weaver>emacs, maxima, lisp, guile: these are designed to be living systems, in a sense. <mark_weaver>racket is designed more to be a static system, where the code doesn't change without restarting the program. <amz3>I understand better the design of epsilon <Jaood>mark_weaver: yeah, I'm starting to see how that is a very strong point, even for web app development where I'm interested in, not throwing away the data and redefining procedures live <Jaood>mark_weaver: can anonymous procedures be redefine live too? <davexunit>procedure objects don't change once they are created, but of course you can modify the variable that the object is bound to. <taylanub>Jaood: "anonymous procedure" is kind of a vague term. I'm guessing you mean a procedure which, instead of being bound to a variable, gets passed to some API, or stored in some data structure, etc. in that case it depends on the API, the data structure, etc. <taylanub>Jaood: e.g. in Emacs you can (add-hook 'foo-hook (lambda () ...)), and getting that lambda out of the hook again and adding another one instead can be a bit annoying but it's possible. <Jaood>so in the case of named procedures, existing code will start using a modified procedure automagically/live, like modifying the function you pass to some other function? <mark_weaver>Jaood: procedures can be stored in variables, like any other values. <mark_weaver>when you refer to a variable, the variable is read to get the value within, which might be a procedure. <Jaood>davexunit: say function A already takes function B as a argument, if I modified function B, will the running version of function A pick up the changes in fucntion B? <mark_weaver>if you call (A B), then the variable B is read only once, before A is called. <Jaood>mark_weaver: but then how can system be real live with out that feature? <Jaood>mark_weaver: I'm talking about procedures stored in variables <mark_weaver>well, most of the time when you call a procedure, you look up its value from a variable immediately before calling it. <mark_weaver>every time you call it that way, its value is looked up from the variable. <mark_weaver>then 'display' is only looked up once, and the stored in a local variable within 'for-each'. <mark_weaver>changing 'display' while 'for-each' is running will not change its local variable, and as I said procedures themselves are immutable. <Jaood>mark_weaver: so for 'for-each' to catch the change of 'display' you need to restart the system or is there another way? <mark_weaver>no, you don't need to restart the system, you just need to call 'for-each' again. <mark_weaver>when you call 'for-each', you pass it a procedure object. <mark_weaver>so every time you call (for-each display <list>) it reads the 'display' variable before passing its value (a procedure) to 'for-each'. <Jaood>who wrote most of the Guile manual? <Jaood>ok, its very good, I see there is a 2.2 manual, is there somewhere to see the roadmap for 2.2? <Jaood>are you working on Guile? :D <please_help>is there something wrong with the syntax (let ((ptr #u64(0))) ...) ? When I do that and add (format) messages right after, it tells me that ptr is actually #u64(1) <please_help>moreover, while the value is set by a C function later and I get the correct value, one statement later it is set back to 1 again. <please_help>there's also nobody with a reference to it outside the let scope. <sbidin>Is there a prettier way of defining something like (define (f . (x . rest)) (...))? <please_help>moreover, replacing #u64 by (make-typed-array 'u64 0 1) actually does not present this problem <sbidin>mark_weaver: Oh, right... :) Thanks! <please_help>I thought they were equivalent on account of the reader macro translating into the make-typed-array form? <mark_weaver>please_help: it sounds like you're modifying some literal array somewhere <mark_weaver>please_help: values like #u64(0) are literals, and all literals in scheme are immutable. <please_help>The value of the first cell is being modified but not the array itself, or so it should be <mark_weaver>if there are two instances of #u64(0) in the same program, the compiler is allowed to combine them into a single object. <mark_weaver>and then if you modify one of them, against the rules, then the other one will change too. <please_help>I use (bytevector->pointer ptr) which I assume to be semantically equivalent to (bytevector->pointer ptr 0), which should give me a pointer to the first cell <please_help>oh, so all #u64(0)-formed arrays are actually "the same"? <mark_weaver>we may be able to start putting literals in read-only memory in 2.2, at least for compiled code. I think we might already do so. <mark_weaver>in which case you'll get a segfault if you try to modify them. <mark_weaver>and then maybe we can look at supporting a segfault signal handler that reports those errors in a nicer way, but that's another step. <sneek>ijp was here Jul 08 at 10:14 am UTC, saying: probably negligible if any. <please_help>speaking of segfaults, when will guile stop dying when a segfault is encountered? It's really annoying when trying to develop using the ffi. <mark_weaver>when you're working with C code, that's life, sorry. what do you expect it to do? <mark_weaver>you could make the same complaint about C without Guile in the picture <mark_weaver>when you use the FFI, you're in the C world, and if you mess up, things can get ugly <mark_weaver>and now, with the latest gdb and guile, we even print guile values and stack frames nicely from within gdb. <mark_weaver>if there's some magic bullet for recovering from segfaults, I don't know it. educate me if you do.