IRC channel logs

2015-01-20.log

back to list of logs

<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>davexunit: http://www.nostarch.com/sparkfunprocessing
<zacts>^ it would be cool to do a project like this with guile and your 2d game kit
<davexunit>my gf likes processing.
<davexunit>with some work, Sly could be way cooler :)
<please_help>no idea why the smob's content becomes invalid in one module but not the other?
<davexunit>not sure :/
<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>mark_weaver, OK, will try.
<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>OT: has anyone seen http://media.ccc.de/browse/congress/2014/31c3_-_6443_-_en_-_saal_2_-_201412271245_-_trustworthy_secure_modular_operating_system_engineering_-_hannes_-_david_kaloper.html#video ? I'm interested to know how Guile-TLS would compare to OCaml-TLS in terms of LOCs and security. Any pointer welcome
<hellekin>ditto for Ocaml-OTR (implemented within a week from Ocaml-TLS' 3 months old base and its 20K LOCs)
<zacts>hi guile hackers
<slucx>hi zacts
<civodul>Hello Guilers!
<micro^>GM
<wingo>moin
<dsmith-work>Tuesday Greetings, Guilers
<micro^>gr33tz Mr. Smith!
<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?
<dsmith-work>micro^: You could post a link to a lisppaste
<dsmith-work>Aww. Sneek went away
<ArneBab><dsmith-work> micro^: You could post a link to a lisppaste
<micro^> http://paste.lisp.org/+343Z
<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.
<dsmith-work>Hm.. I can't get to lisp.org.
<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>The full backtrace is http://pastebin.com/yThs5YUG
<micro^>Here's the link again: http://paste.lisp.org/+343Z
<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>** `scm_sym2var' deprecated
<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>thanks dsmith-work
<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?
<taylanub>please_help: did you try 'module-name'?
<lloda`>(module-name ...) ?
<lloda`>hey
<taylanub>:D
<davexunit>interesting, module-name is not documented.
<please_help>yeah, that's the first name I looked for
<please_help>what would be the c function bound to that?
<please_help>scm_c_module_name?
<lloda`>you can always call the Scheme function from C...
<please_help>guess that's my best bet then
<please_help>thanks
<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`>in the REPL
<lloda`>(module-name (resolve-module '(srfi srfi-1)))
<lloda`>$1 = (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)))
<mark_weaver>(that's very basic, but it's a start)
<please_help>looks like in guile-2.1.0.164-015c3, scm_sym2var always segfaults
<please_help>not sure if that's normal, due to bitrot, or what.
<davexunit>please_help: have you tested on 2.0.x?
<please_help>davexunit, no I haven't
<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.
<please_help>in modules.h
<please_help>declared*
<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.
<mark_weaver>ah, good.
***dje is now known as xdje
<Rashack>is there a good json writer/parser for guile?
<davexunit>Rashack: guile-json
<Rashack>davexunit: https://github.com/cthom06/guile-json ?
<davexunit>Rashack: https://gitorious.org/guile-json/guile-json
<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.
<Rashack>ok, i'll take a look at it
<davexunit>we use it in Guix.
<davexunit>for a couple of package importers that deal with HTTP APIs that serve JSON.
<Rashack>seems to be difficult to build :(
<davexunit>it's pretty straight forward, actually.
<davexunit>no dependencies outside of guile itself.
<Rashack>well...
<Rashack>the README suggests ./configure
<Rashack>which isn't there
<Rashack>all too common
<davexunit>Rashack: that's because you cloned the git repo
<davexunit>rather than getting a release tarball.
<davexunit>run 'autoreconf -vif'
<davexunit>that will generated configure and Makefile.
<davexunit>generate*
<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
<Rashack>I should learn autotools
<davexunit>admittedly, they are difficult to learn.
<davexunit>I only the basics. enough to get around.
<davexunit>not enough to write/debug complex build systems
<Rashack>portability is hard, let's go shopping!
<davexunit>:P
<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
*dsmith-work agrees
<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
<Rashack>and then ./configure
<mark_weaver>autoconf is usually not enough by itself
<Rashack>as i said "and then ./configure"
<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?
<mark_weaver>right
<Rashack>dsmith-work: yeah, i pulled from github
<mark_weaver>"autoreconf -vfi" is usually the right thing
<mark_weaver>although it varies from project to project.
<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
<Rashack>since projects differ
<dsmith-work>Rashack: That is usually in the file HACKING
<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