IRC channel logs

<dje42>IWBN if the docs for soft ports provided a clear example of "subclassing" an existing port.

<dje42>i.e. I have to dig too hard (and I'm not sure I've found everything) how to pass off the 6 different function calls to the "baseclass".

<dje42>ref: http://www.gnu.org/software/guile/manual/html_node/Soft-Ports.html#Soft-Ports

<civodul>Hello Guilers!

<nalaginrut>heya ludo

<wingo>moin

*wingo going to fix prompt compilation in rtl

<mark_weaver>excellent! :)

<wingo>:)

<nalaginrut>oh!

<bubble>rtl ? real-time linux ? :-)

<wingo>no, our new vm

<bubble>coolness

<wingo>whee, prompts working

<civodul>woow, that's efficient

<civodul>something like 4 jours later :-)

<civodul>*hours

<tupi>hello guilers, anything recently changed with respect to dynamic-link search path? a code that used to perfectly run refuses to do so now, complaining with the following

<tupi>ERROR: In procedure dynamic-link: file: "libgw-guile-gnome-clutter", message: "file not found"

<tupi>but these libgw-guile-gnome-clutter* are all in /opt/lib, which itself is in my LD_LIBRARY_PATH

<tupi>any hint?

<wingo>nothing has changed that i know of

<wingo>it could be that the libs fail to load because something else changed on your system

<wingo>and then you run into the old ltdl "all errors are file not found" bug

<tupi>ok i will try to understand then :)

<tupi>note that kisê still works, it appears to be guile-clutter only that does not find its liib

<wingo>do an "ldd" within the environment you use on the files in /opt/lib

<wingo>see if something comes up as "not found"

<tupi>ok

<tupi>wingo: tx, here is the problem: libcogl-pango.so.0, libcogl.so.9

<tupi>these packages changed from 1.10 -> 1.14 on debian testing

<wingo>ah

<wingo>perhaps you need to recompile guile-clutter? dunno

<tupi>i can try

<tupi>it should work i guess

<tupi>but it would be nice to update guile-clutter ... :)

<wingo>:)

<wingo>sneek: later tell mark_weaver i wonder how lazy dynamic linking is threadsafe with the PLT trampolines

<ijp>it's weird that (language cps) uses builder macros, and all the rest use procedures

<sneek>Will do.

<wingo>sneek: later tell mark_weaver seems to me we should do something like that

<sneek>Will do.

<wingo>sneek: botsnack

<sneek>:)

<tupi`>power failure [in my house], reminds us how much we depend on elec :) unbeilevable

*wingo going to try to convert gsubrs over to the rtl vm

<stis>yey, now we are close :-)

<wingo>i think so, yes

<wingo>surely a bunch of bugs to find, but i need more things in rtl to implement "abort"

<wingo>right now aborting works but resuming doesn't

<wingo>because it recurses from one vm to the other

<stis>hmm, yes I rememberes that to be a tricky part.

<wingo>humm, i actually wish i had c++ templates

<wingo>because they are turing complete ;)

<madsy>With great power comes great responsibility :P

<wingo>i guess i have elisp that can generate the code that i was going to generate anyway ;)

<stis>:-)

<stis>Hmm, debug large macros is not that helpfull, ...

<stis>I have a huge macro defineing an evironment and the line numbers just don't transfer and I get zero help from that output

*tupi is facing lots of power failure today!

<tupi>wingo: i did rcompile and it's ok [clutter...]

<tupi>tx

***alexei is now known as amgarchIn9

<wingo>mu

<wingo>heya mark_weaver

<mark_weaver>hi wingo! how goes the hack?

<sneek>mark_weaver, you have 2 messages.

<sneek>mark_weaver, wingo says: i wonder how lazy dynamic linking is threadsafe with the PLT trampolines

<sneek>mark_weaver, wingo says: seems to me we should do something like that

<wingo>heh, sorry about that ;)

<wingo>am currently looking at generating rtl stubs for gsubrs

<mark_weaver>I don't know why you'd apologize; it's a good thing to look into :)

<wingo>getting arity information for stubs is trickier than with the stack vm...

<mark_weaver>though quite possibly it would be harder for us to do the same thing, because of portability issues.

<wingo>it's platform-specific, but there's no reason we can't have a fallback along with some platform-specific fast paths

<mark_weaver>*nod*

<wingo>well, depending on what abstractions the various architectures permit

<wingo>yes. nods all around ;)

<mark_weaver>I don'

<mark_weaver>I don't know if it's feasible, but it would be great if we could use the PLT mechanism to create C interfaces for Scheme procedures that have not yet been loaded.

<mark_weaver>e.g. for things like scm_local_eval and scm_eval_string

<mark_weaver>obviously we couldn't do it for all platforms, but maybe we could for some.

<wingo>yes!

<wingo>yes that would be great

<wingo>and likewise for scheme -> c once we get native compilation

<wingo>to call out to the runtime

<mark_weaver>I seem to vaguely recall that ELF allows symbols that have already been bound to code segment A, to later be relinked to a different code segment B, when new libraries are dynamically loaded.

<mark_weaver>if so, we could even use this mechanism to deal with Scheme procedures bound at toplevel to be 'set!'.

<mark_weaver>such that code that calls the procedure could simply jump via the PLT.

<mark_weaver>just random ideas... not sure if they will pan out :)

<wingo>yes i agree

<wingo>tricky of course

<wingo>but it would be nice

<wingo>evening, civodul

<civodul>hey, wingo

<ijp>(error "unexpected $fun" fun) <- wingo hates fun

<wingo>straight truth, that

<civodul>:-)

*civodul updates the smob section of the manual

<civodul>i think this was prompted by a comment by dje42

<civodul>and indeed, that section's is a real mess

<civodul>completely outdate

<civodul>+d

<wingo>so much to do :)

<civodul>yeah

<civodul>mark_weaver: the compilation-order bug also affects auto-compilation (obviously), so that really sucks

<mark_weaver>really? I would expect that when modules are loaded for auto-compilation, they the top-level expressions are also evaluated.

<mark_weaver>sorry, gotta go afk for a bit

<civodul>or maybe not, because it ends up doing things in the right order

<civodul>yeah

IRC channel logs

2013-10-14.log