IRC channel logs

2014-10-26.log

back to list of logs

***karswell` is now known as karswell
***heroux___ is now known as heroux
***heroux__ is now known as heroux
<stis>hej guilers!
<nalaginrut>hmm...guile git repo is down?
<nalaginrut>alright, fine now
<gjanssens>Hi, question about %load-path
<gjanssens>Gnucash comes with a bunch of guile modules
<gjanssens>They are only useful though for gnucash
<gjanssens>On the other hand the guile guide suggests putting guile modules in the site-dir
<gjanssens>Would that make sense for such private modules, or should gnucash just keep them in its own private data directory ?
<gjanssens>Or asked the other way around, what kind of modules should be put in the site-dir ?
<gjanssens>I would presume modules that could be more generally useful independent of gnucash ?
<janneke>gjanssens: why, what are you trying to accomplish?
<sneek>janneke, you have 1 message.
<sneek>janneke, nalaginrut says: I think your patch to lalr-scm added source-location info, which could be used in procedural Tree-IL 'src' slot. But I don't know how to use this new feature. Is there any document or tutorial? ;-)
<mark_weaver>gjanssens: I'm not sure there's any harm to putting 'private' modules in site-dir, as long as the module name starts with a prefix that makes it unlikely to collide with anything else (e.g. (gnucash private ...)).
<gjanssens>janneke: I'm not really trying to accomplish anything, just understanding how things are done properly
<mark_weaver>gjanssens: however, for modules that could never be used outside of the gnucash executable, I suppose it would be reasonable to keep them in a separate directory, in which case you should augment %load-path and %load-compiled-path within gnucash.
<ijp>xb
<gjanssens>mark_weaver: thanks, that's what we currently do
<mark_weaver>sounds good to me!
<gjanssens>Just wanted to make sure that's the recommended way
*gjanssens is reassured now :)
<mark_weaver>I'd only inquire about the possibility of users writing guile scripts that run outside of the gnucash executable, but somehow do something gnucash related. I'm not sure if that makes any sense or not though :)
<djcb>mark_weaver: i did something similar with mu
<djcb>i started with a special mu/guile binary
<djcb>but then just wrote some modules to be used with the 'normal' guile
<mark_weaver>for new programs, written from the start to use guile extensively, it is often preferable to have 'guile' be the main program, and instead include a C library for any needed C bits. this provides a lot more flexibility, and in such a case, it's more feasible for users to write their own script that use your Scheme+C code as a library.
<mark_weaver>in such a case, probably everything should go in the site directory.
<mark_weaver>but obviously gnucash is not such an example
<mark_weaver>djcb: I'm glad you made the switch! I still need to check out mu, and the more I hear about it the more tempted I become :)
<djcb>mark_weaver: thank you!
<djcb>the guile part is a bit of an experiment, being fascinated by guile for a decade or so
<djcb>but it's been fun!
<mark_weaver>:)
<djcb>writing little scripts to do some statistics / graphs (using gnuplot) is quite interesting
<djcb>my guile/scheme is still rather pedestrian though
<mark_weaver>djcb: are you familiar with guile-charting?
<mark_weaver>gnuplot, despite its name, is not actually affiliated with GNU at all.
<djcb>indeed
<mark_weaver>and it has a rather suboptimal license, as I recall.
<djcb>aha
<djcb>doesn't seem *too bad* http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright?view=markup
<djcb>but yeah, incompatible
<djcb>i think guile-charting wasn't available when i needed it (few years back)
<mark_weaver> https://lists.gnu.org/archive/html/guile-user/2014-09/msg00089.html
<mark_weaver>no doubt, gnuplot is much more capable, of course.
<djcb>but i should probably start using it, now that it's there!
<djcb>of course, the great GNU replacement for Graphviz / Gnuplot would be nice
<djcb>guile-charting looks like a nice start
<djcb>and potentially a lot nice since we have a real language
<djcb>*nicre
<djcb>*nicer
<mark_weaver>right, we seem to find ourselves in that position a lot in guile land :)
<mark_weaver>(nice start, good language, but less functionality available out of the box)
<janneke>mark_weaver: saw your mail; i snailed assign.future october 9th, and it's supposed to take 4-6 days
<mark_weaver>janneke: yeah, this seems unusually slow.
<djcb>guile integration has happened to a few gnu packages though... hoping it will continue\\
<mark_weaver>yes, there has been some encouraging progress on that front. I'm especially pleased with the GDB integration. The backtraces produced by gdb 7.8 with guile-2.0.11 are lovely.
<mark_weaver>and wingo made use of it to help him debugging webkit, iirc.
<djcb>have to play with that... some guile magic to assist me with some glib-related debugging would be nice
<djcb>probably a good way to start playing with that
<djcb>gdb% guile-repl
<djcb>Guile scripting is not supported in this copy of GDB.
<djcb>:-(
<gjanssens>Another question on guile compilation:
<gjanssens>Assume a future version of guile uses an incompatible ABI
<gjanssens>For example let's assume guile 2.0 compiles scm files in a way that is incompatible with guile 2.2
<gjanssens>Suppose I have a set of files compiled with guile 2.0 and I now install guile 2.2
<gjanssens>Will it properly detect that compiled files are no longer compatible and trigger an autocompile ?
<rekado>Is there any better documentation available for (sxml ssax)? Any examples I could look at to understand how to use it?
<rekado>the official docs don't seem to include descriptions of the procedures.
<ijp>rekado: not really, you can read the docs in the file, but that isn't optimal either