<please_help>I have 1 smob that I can manipulate correctly after it's passed to a guile program. In a second module, the same smob definition is registered and I return another smob of that type. However, while I can (pointer->bytevector) the malloc'd data, if I ever try to (bytevector-###-ref) that, I get a memory corruption error. <please_help>Also printing works but seems to display widely incorrect values, which indicate the memory has been freed somewhere <please_help>using scm_remember_upto_here_1 does not seem to help <zacts>^ it would be cool to do a project like this with guile and your 2d game kit <please_help>no idea why the smob's content becomes invalid in one module but not the other? <davexunit>I don't program with the C API much these days. <please_help>Hopefully I'll be able to say the same soon(TM) but in the mean time, not much luck. <please_help>Even stranger it seems; the data pointed to by the smob variable is correct until it is turned into a SCM... <mark_weaver>please_help: I saw you ask the other day about whether you could define the smob type in each module independently. that won't work. you need to define the type in just one place and then export it if you need it in another module. <mark_weaver>I have to go afk now, but wanted to briefly mention that first. <please_help>unfortunately, this does not seem to have changed anything. <please_help>Data pointer address is 0x1eaa860; it points to 9 doubles (size = 8 bytes) of data. The corruption happens at 0x0000000001eaa8d0 which is 112 positions away. 9*8 = 72. The rest of the structure the smob cares about are an ull* (8 bytes), an ull (8 bytes) and an int (4 bytes) for a total size of 92 bytes per struct. <hellekin>ditto for Ocaml-OTR (implemented within a week from Ocaml-TLS' 3 months old base and its 20K LOCs) <micro^>I've finally written my first scheme/guile script and would welcome some feedback on it <micro^>Where's the best place for this? <ArneBab><dsmith-work> micro^: You could post a link to a lisppaste <ArneBab>dsmith-work: did I understand your note about sneek correctly: that you did not see micro^ online? <micro^>paste.lisp.org is not connected to any IRC channels <dsmith-work>ArneBab: I wanted to ask sneek for the lisp paste url, but sneek is missing. <dsmith-work>micro^: Yeah, is not connected anymore. But you can still create a paste and then manually copy the url here. <please_help>When trying to load a SWIG-generated module I get Program received signal SIGSEGV, Segmentation fault. <please_help>0x00007ffff7b1291f in scm_hash_fn_create_handle_x () from /usr/lib64/libguile-2.2.so.0 <please_help>what's the non-deprecated equivalent to scm_sym2var? <dsmith-work>please_help: Check out the NEWS file. That has all the deprecation announcements and replacement info. Or should. <dsmith-work>In most cases, replace with `scm_lookup' or `scm_module_variable'. Use `scm_define' or `scm_module_ensure_local_variable' if the second argument is nonzero. See "Accessing Modules from C" in the manual, for full details. <dsmith-work>please_help: np. Sometimes they miss a replacement. That's a bug. <ArneBab>dsmith-work: I cannot reach paste.lisp.org either <please_help>what can I use to obtain the name of the module from a module object? <lloda`>you can always call the Scheme function from C... <please_help>looks like it's not good enough since scm_c_resolve_module appears to return an object that's not the right type to apply (module-name ...) on... <lloda`>(module-name (resolve-module '(srfi srfi-1))) <mark_weaver>micro^: one comment on your script: if the commands that you're running via 'system' fail (return a non-zero result), your script won't detect that and will just keep going. <mark_weaver>you might want to make your own little procedure that calls system and makes sure the result is zero, like: (define (run command) (unless (zero? (system command)) (error "command failed" command))) <please_help>looks like in guile-2.1.0.164-015c3, scm_sym2var always segfaults <mark_weaver>please_help: scm_sym2var has been removed from guile-2.1, quite a long time ago. I'm not sure why you're not getting an error at link time. <please_help>mark_weaver, the function is properly defined in guile headers... this could explain it. <mark_weaver>please_help: I don't see it in my copy of guile-2.1.0.164-015c3 <mark_weaver>sounds like maybe you've got some guile-2.0 headers/library installed that maybe you're unwittingly using. <mark_weaver>if you're using some mix of 2.0 and 2.1, that could certainly cause segfaults <please_help>yes, you are correct. It seems the 2.0 headers were being found first. ***dje is now known as xdje
<Rashack>is there a good json writer/parser for guile? <davexunit>I have some qualms about the implementation, but it's alright. :) <davexunit>I'd like to replace the macros and use plain sexps instead. <davexunit>and replace the hash table usage with alists. <davexunit>for a couple of package importers that deal with HTTP APIs that serve JSON. <davexunit>Rashack: that's because you cloned the git repo <Rashack>davexunit: that worked a lot better :) <Rashack>i wish that were in the readme more often <davexunit>developers pretty much always have to take additional steps that are *not* in the regular documentation for users. <Rashack>yeah, I keep thinking i'm a developer :) <davexunit>running 'autoreconf' is standard procedure when dealing with projects that use autotools <davexunit>not enough to write/debug complex build systems <Rashack>portability is hard, let's go shopping! <dsmith-work>Rashack: Generally, you don't commit a build product to version control. And ./configure is generated from other files. *davexunit hates when people commit build artifacts to the repo <Rashack>dsmith-work: i know about (1), but i guess i hadn't realized that ./configure was a build artifact <Rashack>i imagine that many times these kinds of problems are solved by autoconf (for me), i guess it only does sometimes <mark_weaver>right, I meant that 'autoconf' by itself before ./configure is usually not enough <mark_weaver>it's not enough for projects that use automake, for example, which is quite common these days <dsmith-work>Rashack: configure is always included in gnu source tarballs. <Rashack>mark_weaver: you mean autoconf, configure and make is not enough most of the time? <Rashack>dsmith-work: yeah, i pulled from github <mark_weaver>some projects include a script called "autogen.sh" or "bootstrap" that does what's needed when building directly from a repo checkout <Rashack>continuing on the autoconf/autoreconf/configure discussion <Rashack>i still think it would be nice to include "if you pulled this with git, do ..." in the README <dsmith-work>Rashack: From the guile HACKING: "When Guile is obtained from Git, a few extra steps must be taken before the usual configure, make, make install. ..." <Rashack>dsmith-work: i found that in one repo