IRC channel logs


back to list of logs

<zacts>lo guilers
<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".
<civodul>Hello Guilers!
<nalaginrut>heya ludo
*wingo going to fix prompt compilation in rtl
<mark_weaver>excellent! :)
<bubble>rtl ? real-time linux ? :-)
<wingo>no, our new vm
<wingo>whee, prompts working
<civodul>woow, that's efficient
<civodul>something like 4 jours later :-)
<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>wingo: tx, here is the problem:,
<tupi>these packages changed from 1.10 -> 1.14 on debian testing
<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>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
<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>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...]
***alexei is now known as amgarchIn9
<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
<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 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 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
<wingo>so much to do :)
<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