<leoprikler>mwette: my implementations creates one list of N vectors + 2 lists for indexing <leoprikler>well, apart from the temporary lists for the function calls, but those are the same for every implementation I'd guess <leoprikler>tbf my inc could probably be optimized with vectors tho <chrislck>leoprikler: no: older records. (define <person> (make-record-type 'person '(name addr dob))) (define (addr-getter (record-accessor <person> 'addr))) (export addr-getter) <chrislck>IIUC this is a change guile-2 to guile-3 whereby getter is now a macro <leoprikler>chrislck: I assume you mean (define addr-getter ...)? <leoprikler>e.g. in (tsukundere text) #:export (... text-string set-text-string! ...) <leoprikler>(define text-string (record-accessor <text> 'string)) <leoprikler>(define set-text-string! (record-modifier <text> 'string)) ***apteryx is now known as Guest25677
***apteryx_ is now known as apteryx
<chrislck_>leoprikler: thx for pointer. not sure why mine isn't behaving. will check again. ***chrislck_ is now known as chrislck
<chrislck>funnily enough using guile-3.0.4 in gnucash theres unbound-variable warning for set-tm:mon and friends. these functions are core! <lloda>if help says they're in (guile) module they are in core <chrislck>importing (guile) doesn't reomve the warning. <lloda>what happens if you import specifically that, like (import (only (guile) set-tm:mon)) <leoprikler>could it be that they override stuff in the (guile) module or load their own guile? <chrislck>they? no, gnucash tries no such dirty tricks <chrislck>and updating to 3.0 was painful, but done <chrislck>now updating to 3.0.4 is showing some warnings... <chrislck>nonetheless this set-tm is harmless (for now) and I'll try figure out how to export record getters/setters <tohoyn>daviid: How is the file doc/version.texi generated? <tohoyn>str1ngs: do you know about doc/version.texi? <tohoyn>I'm trying to debianize g-golf and file version.texi is not found <leoprikler>doc/version.texi should be generated by autotools <tohoyn>./autogen.sh does not generate it <tohoyn>./configure --with-guile-site=yes does not generate <leoprikler>$(srcdir)/doc/version.texi: $(srcdir)/doc/stamp-vti <leoprikler>$(srcdir)/doc/stamp-vti: … $(top_srcdir)/configure <leoprikler>the code for generating it should be generated by autotools <leoprikler>specifically automake creates Makefile.in, then Makefile.in → Makefile through configure <leoprikler>I think automake does that when it sees info_TEXINFOS and the like <tohoyn>I can't find the code for version.texi in the top makefile <tohoyn>yes, and building g-golf normally works fine <leoprikler>in that case the code should be under doc/Makefile <tohoyn>I found the code in doc/Makefile <tohoyn>In the debianized version I found the following: $(srcdir)/version.texi: # $(srcdir)/stamp-vti <tohoyn>which is probably the reason why the code does not work <tohoyn>I use debuild to build the package <tohoyn>I generated the debian files with debmake <tohoyn>found the following in doc/Makefile.in: $(srcdir)/version.texi: @MAINTAINER_MODE_TRUE@ $(srcdir)/stamp-vti <tohoyn>so the key seemns to be @MAINTAINER_MODE_TRUE@ <tohoyn>it seems that the debianized version is not configured in maintainer mode <tohoyn>added --enable-maintainer-mode to the configure commmand in debian/rules. now the documentation builds ok. <tohoyn>In non-debianized code it is 3 of 6 <tohoyn>It seems that I don't have the Clutter library <tohoyn>In which package the Clutter introspection files are located? ***sneek_ is now known as sneek
<chrislck>leoprikler: thx for pointers -- you gave confidence that modularisation could progress and it did <chrislck>leoprikler: modularise gnucash. it started 20yrs ago when guile was nowhere as strict on modules and stuff <dsmith-work>srandon111: No. But I've always been interested in dfly. Seems like some *very* good ideas in there. <davidl>Can you do say sleep 60 in guile in some native way without using for example (system "sleep 60") ? <davidl>I want to run some procedure at a specified interval <davidl>(and also background the script, or daemonize it) <davidl>mwette: thanks, not sure how I missed that, I have auto-complete for it even xD <ane>what would be a name for a guile program's equivalent of the site-lisp directory <ane>$prefix/program/scheme $prefix/program/guile ? <ane>i.e. distributed scm files in the program's load path <ane>gdb seems to use $prefix/share/gdb/guile ***rekado_ is now known as rekado
<rekado>ane: $prefix/share/guile/site/3.0/$program <rekado>and for compiled files: $prefix/lib/guile/3.0/site-ccache/$program/ <leoprikler>well, that's assuming that you can name all your modules (program something) <leoprikler>if you need your own namespace for whatever reason, gdb's way is also sane <mwette>$prefix/share/guile/site and $prefix/share/guile/3.0/site <civodul>i wonder if we should ignore GUILE_LOAD_PATH until after scm_load_startup_files has been called <civodul>it's annoying that we're stat'ing so much when GUILE_LOAD_PATH is set <dsmith-work>I don't remember, can guile load a module from it's .go file *without* having the .scm file? ***oni_on_ion is now known as oni-on-ion
<civodul>i think so though we're not doing that anywhere <civodul>yeah it's a bit ridiculous that we're stating .scm files and then not opening them <civodul>this is to allow for the timestamp-based auto-compile logic <dsmith-work>Just wondering if it knew to look for a compiled file if there was no source. <dsmith-work>Thinking about embedded systems with limited "disk" space. <mwette>I have done this using load-compiled, IIRC. I can check ... <mwette>... not clean. I ran guile with --no-auto-compile, then load-compiled the .go files, then (use-modules ...). <dsmith-work>So pre-load the .go files? And then use-modules just uses them? <mwette>This was years ago, but I'm guessing I tried to get it to load .go files automatically but didn't make it. <mwette>I think so. It's been a while. That was with 2.0.13 IIRC, and worked with 2.2 IIRC. <civodul>yeah load-compiled does the trick, but plain use-modules does not