IRC channel 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>scheme@(guile-user)> (pointer->procedure '* (dynamic-func "ao_open_live" libao) (list int '* '*))

<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>w00t!

<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

<davexunit>:)

<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>awesome!

<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: http://git.savannah.gnu.org/gitweb/?p=guix.git;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

<zacts>:-D

<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.

<zacts>hehehe

<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>davexunit: http://pagesperso-systeme.lip6.fr/Christian.Queinnec/WWW/LiSP.html

<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>GUI

<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>yeah

<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

<nalaginrut>heya

<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 libgc.so.1

<dje42>Ah, got it. libguile.so 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/libgc.so (which on my machine doesn't have GC_move_disappearing_link)

<nalaginrut>dje42: how's guile-gdb now? ;-)

<zacts>what is guile-gdb?

<zacts>mark_weaver: https://edge.edx.org/courses/uc-berkeley/cs61as-1x/SICP/info

<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

<wingo>moin

<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, https://github.com/lilydjwg/swapview

<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

<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>:)

<wingo>how does that compare to other languages you were trying?

<nalaginrut>wingo: python is around 0.24

<nalaginrut>python2

<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?

<taylanub> https://github.com/lilydjwg/swapview

<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

<wingo>times

<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>setvbuf

<wingo>or set locale to C :)

<nalaginrut>I

<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>maybe?

<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?

<wingo>dunno

<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

<wingo>cool

<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>:)

<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>stramge

<wingo>*strange

<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

<daviid>ok

<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>now

*nalaginrut go to bed...

<nalaginrut>zzzZZZZ

<nalaginrut>night guiles

<nalaginrut>night guilers