IRC channel logs


back to list of logs

<kjell>i'm getting a segfault using pointer->procedure from the foreign module, anyone got any tips to debug this?
<kjell>i've tried guile --debug and installed libao-dgb (i'm using ffi to access libao) to get som useful information with gdb and the core file, but my knowledge is a little limited
<kjell>the backtrace is only giving me numbers that isn't very helpful to me
<davexunit>I'm not so good with gdb, unfortunately.
<davexunit>but do note that it is extensible with guile these days. :)
<davexunit>I really need to use it better.
<davexunit>learn to use*
<kjell>yeah i found some of that, but i was hoping for something faster and simpler at ten to two when i should be sleeping :)
<kjell>i've been looking at your guile-toxcore for inspiration though
<kjell>using the define-syntax form from it i have a function that returns a pointer and takes a int and two pointers: '* "ao_open_live" (list int '* '*)
<kjell>does it look ok to you?
<kjell>i've written about fifteen others that seem to work
<kjell>but none of the others take mixed values and pointers, so i'm thinking i might be doing it wrong
<kjell>you've written a few that are formatted similarly
<davexunit>nothing stands out to be as wrong, assuming the macro works like the one I use.
<kjell>it should be fine, since i'm doing a few calls before the call to this one, and they work fine and return sensible data
<davexunit>it could be that you found a bug, I wouldn't expect pointer->procedure to segfault when given bad input.
<kjell>maybe, but i'm diong simple stuff here :)
<kjell>thanks anyway, sleeps is probably what i need the most now
<kjell>will try to get some time to read up on the gdb support tomorrow
<davexunit>scheme@(guile-user)> (dynamic-func "ao_open_live" libao)
<davexunit>$1 = #<pointer 0x7f2d34f7e070>
<davexunit>scheme@(guile-user)> (pointer->procedure '* (dynamic-func "ao_open_live" libao) (list int '* '*))
<davexunit>$2 = #<procedure 2c97020 (_ _ _)>
<davexunit>worked for me :/
<kjell>but when it's used...
<kjell>the last pointer it takes can be null
<davexunit>oh... you said pointer->procedure caused the segfault
<kjell>"ao_option *option" (from ao.h)
<kjell>aha, sorry, i was being unclear
<davexunit>well then, yes, it's not surprising that the call to that function triggered a segfault.
<kjell>exactly :)
<davexunit>you'll need to make sure that your input is valid.
<kjell>but it's not the easiest thing for a noob to find out how to do it right
<kjell>the seconf pointer is a struct with a few values created by other ffi-calls, i can print them and they look fine
<kjell>for null i use (bytevector->pointer (make-bytevector 4))
<davexunit>you can use %null-pointer instead
<davexunit>that bytevector is certainly the problem
<davexunit>well, maybe it's not...
<davexunit>just try %null-pointer to see
<kjell>davexunit: i'm getting real close to owing you a bottle of whisky
<kjell>that worked, thanks again! :)
<davexunit>how about a nice ginger beer instead? :P
<kjell>whatever floats your boat :)
<davexunit>so yeah, you didn't make a null pointer before, you made a non-null pointer to that bytevector.
<davexunit>but the sizeof that options struct was not 4 bytes so...
<davexunit>Crashy McCrasherson crashed your program.
<kjell>but the sizeof of the struct, isn't that irrelevant to the pointer?
<kjell>yeah, i don't like him at all
<davexunit>the null pointer is the pointer to the address 0. your pointer is to a non-zero address, a real place in memory.
<kjell>i am only a call to a play function and a while loop from hearing some mp3 audio in my speakers i think
<kjell>yeah, i think i understand pointers in c, and i realize that my attempt att a null pointer in guile was broken :)
<kjell>davexunit: i'm now playing an mp3-tune using libao and libmpg123 using ffi in guile :D
<kjell>davexunit: thank you very much for your help
<kjell>i'll clean it up a bit and post it later this week if you're interested
<kjell>_i'm_ excited :)
<davexunit>I kind of wanted to write an MPD client in guile, but since EMMS exists for emacs, I wouldn't really use it.
<zacts>an MPD server in guile would be cool
<zacts>to replace MPD
<davexunit>now that would be cool.
<davexunit>and really difficult to do :)
<jgrant>Does MPD implement it's own codecs, or outsources that?
<zacts>davexunit: I really want to get started on SICP, I've just been busy as hell
<zacts>is SICP still useful if I do an initial read thru without doing all of the exercises?
<zacts>or should one not conquer SICP this way?
<davexunit>jgrant: it uses the libraries you'd expect for the various formats, see:;a=blob;f=gnu/packages/mpd.scm;h=a1b427271d6ca85bf7c52151b94cb15403d28c24;hb=HEAD#l82
<davexunit>zacts: do the exercises as you go.
<zacts>hm.. Ok. I'll be good and go ahead and do them
<davexunit>I personally cherry picked the excercises. I didn't do every single one.
<zacts>ah ok
<zacts>well perhaps I may do the same
<davexunit>and in fact I haven't worked through the whole book yet
<zacts>oh interesting!
<zacts>did you at least get thru ch3?
<davexunit>but SICP is a pretty constant source of inspiration to me
<davexunit>yes, through chapter 3.
<davexunit>chapter 3 is a gold mine. a bunch of code in my game engine was inspired by that chapter
<zacts>oh neato
<davexunit>the scheduler for the digital circuit simulator became the (sly agenda) module
<zacts>davexunit: have you ever written any toy interpreters?
<davexunit>surprisingly, no.
<davexunit>I really should.
<zacts>davexunit: there is a book on this
<zacts>well, and SICP itself
<zacts>you write a scheme interpreter in scheme with SICP
<davexunit>yeah, I've read through that and watched the lectures
<davexunit>I just haven't written my own metacircular evaluator
<zacts>the book LISP in small pieces
<zacts>it even covers scheme dialects
<zacts>davexunit: just curious, but do you use a GUI emacs, or do you run emacs in a terminal?
<davexunit>when emacs is an X window, it looks nicer and can do things like render images.
<zacts>oh neat
<zacts>I'm trying to switch from tmux + bash + vim to GUI emacs + evil-mode + ansi-term
<davexunit>ansi-term never cut it for me. I use a standalone terminal emulator in addition to emacs
<zacts>huh interesting
<zacts>do you use stumpwm?
<zacts>and what about ansi-term didn't work for you?
<zacts>and which irc client do you use?
<davexunit>I used stumpwm briefly, but not anymore. I use gnome 3.
<davexunit>ansi-term just isn't as good of a terminal emulator as the standalone ones.
<zacts>oh wow! gnome3!?
<davexunit>and I use ERC.
<davexunit>the emacs irc client
<zacts>the only problem I've had with ERC is that I don't know how to configure it for large buffer sizes
<zacts>it would crash often or get b0rked on my irc ssh account
<zacts>irssi just works smooth for me
<nalaginrut>morning guilers~
<zacts>morning nalaginrut
<zacts>and what did you dislike about stumpwm davexunit?
<davexunit>zacts: it's written in common lisp :P
<nalaginrut>yeah, good reason ;-P
<davexunit>I want to use guile-wm, but the maintainer hasn't worked on it in quite some time and there are a few blocker bugs that keep me from being able to use it.
<nalaginrut>I haven't gotten time to hack WM, but I'd like to use if you done it ;-)
<nalaginrut>especially use it on Hurd
<zacts>davexunit: is guile-wm a difficult to hack codebase?
<davexunit>sort of.
<davexunit>mostly because I don't know the X protocol
<zacts>Oh, I see
<davexunit>I think there's 2 patches of mine upstream
<davexunit>there's a particularly annoying bug that would force me to restart X that I couldn't figure out, so I stopped using it.
<cluck>davexunit: small trick, setup ansi-term to run gnu screen instead of the shell and you'll get a great terminal (with still some flaws left but vastly better)
<davexunit>cluck: how badly do the emacs keybindings interfere with screen's?
<cluck>zacts: just truncate your buffers to some reasonably small value so it doesn't eat up ram needlessly (leave backlogs for logs) and you should be fine
<cluck>davexunit: mostly not at all afaict, both screen and emacs are reasonably considerate of each other
<davexunit>cluck: thanks, I'll have to try that
<davexunit>now, how to configure ansi-term this way...
<cluck>davexunit: though i personally tend to avoid screen's default C-a binding when possible (will often use C-z if not dealing with prehistoric uplinks)
<davexunit>I find the 'z' key kind of awkward to reach. I wonder what I should use instead.
<davexunit>I wish screen's configuration format wasn't so horrible.
<zacts>ok cool
<cluck>davexunit: (setq explicit-shell-file-name "/usr/bin/screen")
<cluck>davexunit: it's a matter of preference above anything else really, i tend to gravitate to z because it's mostly unused (and as a stumpwm user t is taken)
<cluck>so whatever works for you =)
<zacts>cluck you know what I think I'll do. I'm going to setup znc, so I can use a local emacs to connect to a continuously running irc session
<cluck>zacts: many people do that (and other things, essentially making emacs a unified frontend) ie, with mail (gnus async backends), instant messaging (say bitlbee under erc), media (emms slaves), etc
<nalaginrut>I'll write something if guile-emacs go to upstream...
<cluck>nalaginrut: fwiw there were rumors stumpwm's main dev seemed open to the idea of guile a while back, so he might be persuaded to port if someone offers to help
<cluck>a guile based emacs under a guile based stumpwm sounds like the stuff of dreams :)
<nalaginrut>cluck: oh it's good news, but so many things on my hackline now...
*nalaginrut needs a clone
*nalaginrut needs a clone of himself
<zacts>cluck: yeah that sounds like fluffy pink cotton candyish heavenish awesome
<zacts>or perhaps it just sounds awesome
<dje42>Does git head require something newer than libgc 7.4?
<dje42>I'm getting undefined symbol: GC_move_disappearing_link
<dje42>Huh, I see it readelf --dyn-syms
<dje42>Ah, got it. has an rpath in the header to find libgc, but guile's pkg-config file also has -lgc, and thus the binary (in this case gdb) also either needs an rpath or the user has to set LD_LIBRARY_PATH.
<dje42>I can take out the -lgc and gdb will still link, but now the dynamic linker will find the one libguile refers to instead of /lib/ (which on my machine doesn't have GC_move_disappearing_link)
<nalaginrut>dje42: how's guile-gdb now? ;-)
<zacts>what is guile-gdb?
<zacts>davexunit: ^
<zacts>I'm trying to find out if they are going to offer this again
<zacts>if so I'm doing it
<zacts>it looks like a really good overview of SICP
<zacts>well this one is archived
<zacts>so I get full access too
<sneek>Welcome back wingo, you have 2 messages.
<sneek>wingo, stis says: there is a bug in generation of receive-values, I got (receive-values 9 #f 2)
<sneek>wingo, stis says: never mind, wrong lead
<nalaginrut>is there any possible to use scm_reverse_x in %read-line? I found it's 20% performance increased. But I'm not sure if it's safe to introduce side-effect here
<wingo>test case?
<nalaginrut>wingo: I'm trying to extract a simple test case from it, I'll send mail to list when it's done
<nalaginrut>but anyway, I think read-line has room to optimize, the current one is so slow compared to other languages
<wingo>i used to look at it and i found that its perf was ok -- dunno
<wingo>i'm interested to see a test case :)
<nalaginrut>wingo: here's an interesting simple benchmark testing read-line and string operations between several languages,
<nalaginrut>although the code using Guile is not so elegant, I'm trying to rewrite for better result. But I found it's not so easy to increase the performance
<nalaginrut>it's not written by me, obviously
<nalaginrut>I don't know if there's better way to write the test case, but python shows a good performance here
<nalaginrut>I've tried several ways to increase the performance, but seems the bottleneck is read-line
***karswell` is now known as karswell
***karswell` is now known as karswell
<nalaginrut>wingo: alright, I've tried master for the same test, very impressive result, 1.6 -> 0.6
<nalaginrut>nice work ;-)
<wingo>dunno what i did :)
<nalaginrut>seems the compiler itself is more important than read-line ;-D
<wingo>how does that compare to other languages you were trying?
<nalaginrut>wingo: python is around 0.24
<wingo>what is the benchmark? :)
<nalaginrut>well, I can't say it's a dedicated benchmark. Just someone write a little script to count the swap size of all the current pid. But he write it in many language for interest. It happens to be a thing to compare these language
<taylanub>nalaginrut: is this about the git repo you posted above?
<nalaginrut>I should commit something to the repo, with better coding. And add some boast to 2.2 ;-P
<wingo>it's not fast code
<nalaginrut>taylanub: yes
<nalaginrut>wingo: you mean the version he give? yes, it's not so good
<nalaginrut>but frankly, %read-line cost 0.32s in this case, I'll take look at it
<wingo>could be read-line is called too many tims
<nalaginrut>yes, but it has to be
<nalaginrut>the program need to parse each lines in /proc/pid/smaps
<wingo>could be buffering too
<nalaginrut>wingo: what if I read all strings first, then use call-with-input-string? Could it be faster?
<wingo>don't think so
<dsmith-work>Tuesday Greetings, Guilers
<nalaginrut>dsmith-work: heya
<nalaginrut>wingo: what do you mean about "buffering" here?
<wingo>or set locale to C :)
<nalaginrut>I've considered to use iso8859-1, let me try
<nalaginrut>wingo: oops, setlocale to C in the begin drags the program so much ;-P
<nalaginrut>hmm...seems encoding will go for reversed way...
<nalaginrut>set a larger block buffer got some progress, but little
<nalaginrut>well, 0.7s
<nalaginrut>reduced 0.7s for a larger buffer
<nalaginrut>wingo: I found %after-gc-thunk is the second time costing, can it be optimized?
<wingo>that indicates that you have finalizers i think
<wingo>something is being allocated that has a finalizer
<wingo>i don't recall
<nalaginrut>hmm, I don't dedicated to do so
<nalaginrut>maybe something triggered it?
<nalaginrut>wingo: will 'catch' cause it?
<nalaginrut>hoh, i disabled gc, it's 5s now
<nalaginrut>in such oneshot script, gc is useless
<davexunit>disabling gc makes me scared.
<nalaginrut>but it's just oneshot data collecting script
<nalaginrut>gc will recycle for you anyway
<wingo>nalaginrut: is the script compiled?
<wingo>or is it being interpreted
<nalaginrut>it's compiled
<nalaginrut>0.528s now, I wonder if there's possible to reduce to the same level without further compiling optimizing ;-P
<wingo>change the code to use named let instead of while and set!
<nalaginrut>I did it in the first glance
<nalaginrut>I don't like while and set! now ;-P
<wingo>you are using statprof?
<nalaginrut>I use ,profile
<nalaginrut>I've tried statprof but it's segfault, so I leave it for a while
<nalaginrut>well, I should report it
<wingo>,profile and statprof are the same thing
<nalaginrut>segfault in stable2
<nalaginrut>well, when I run stat-stop, it's dump
<nalaginrut>anyway, they're the same
<wingo>nalaginrut: odd
<wingo>i probably fixed that in master
<nalaginrut>wingo: so the only chance is %read-line now I guess
<wingo>anyway the better interface is (statprof (lambda () your-code))
<nalaginrut>yes, it's better
<daviid>wingo: hello! the re-write of goops in scheme is fan-tas-tic! will it be available for 2.0 as well? then i want to ask if you're ok with a guile-gnome release: i ask [again] because it's all fine except make distcheck [which fails to run a test [gobject related], it does not fail the test]; the tarball is 'perfectly' ok and pass make check
<wingo>hi daviid :)
<wingo>the rewrite is only for master
<wingo>because there are some changes that are incompatible -- very few, hopefully no impact, but not appropriate for a stable series
<wingo>those refactorings are in order to let me fix the accessor bug
<daviid>i understand and actually did think it would be this way...
<daviid>i'll switch to master now then :)
<nalaginrut>is it possible to pass '-e main' to /usr/bin/env guile?
<nalaginrut>wingo: master is too cool to try, but the guile.m4 seems hasn't updated, then I can't configure Artanis under master ;-(
<wingo>nalaginrut: you could specify GUILE_PKG([2.2 2.0])
<wingo>which you probably should do if you want to allow compilation against guile 2.2
<wingo>until guile 2.2 is stable we shouldn't be automagically selecting 2.2 i don't think
<nalaginrut>I'm hacking guile-lua-rebirth too, it depends on 2.2 tree-il. Although I don't need 2.2 for Artanis now, I don't want to change version everday...
<nalaginrut>Now I'm using "PKG_CHECK_MODULES([GUILE], [guile-2.0 >= 2.0.11])"
<nalaginrut>because Artanis needs 2.0.11+
<nalaginrut>dunno how to check 2.2 either
<daviid>wingo: what about releasing guile-gnome? would you prefer to debug this make distcheck ? i could not figure out why it does not work, would you like to try maybe?
<wingo>nalaginrut: GUILE_PKG([2.2 2.0])
<wingo>then PKG_CHECK_GUILE([guile-$GUILE_EFFECTIVE_VERSION >= 2.0.11])
<wingo>daviid: sure, i can debug the distcheck issue
<wingo>i meant to get to the guile-gnome building issue too as part of this goops stuff
<daviid>ok perfect, thanks
<daviid>remeber i made a change [in devel of course] so that make check works [builddir instead of srcdir], so it tried to locally reverse to see if that was the source of the make distcheck problem, but no
<nalaginrut>oops, error: possibly undefined macro: PKG_CHECK_GUILE
<nalaginrut>maybe PKG_CHECK_MODULES?
<wingo>hah, right
*nalaginrut tring
<nalaginrut>wingo: I think it works now, at least I can configure now, maybe needs more testing, thanks!
<nalaginrut>wingo: one more question, seems compiling warning redirect to stderr now? I think it's stdout in stable2
<nalaginrut>anyway, I redirect them to build.log and build.err respectively
*nalaginrut go to bed...
<nalaginrut>night guiles
<nalaginrut>night guilers
<wingo>night :)
<kjell>anyone know if guile-zmq is abandoned? I fail to build it
<kjell>seems like it's not compatible with zmq 3.2 or 4.0 at least
<davexunit>aww :(
<kjell>exactly my feeling :(
<wingo>kjell: if you are interested in maintaining it you are welcome to do so :)
<wingo>i can hand over whatever privs are needed
***heroux_ is now known as heroux
<wingo>netsplits jeebus
<wingo>so before all this happened
<wingo><wingo> kjell: if you are interested in maintaining it you are welcome to do so :)
<wingo><wingo> i can hand over whatever privs are needed