IRC channel logs


back to list of logs

<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
<mwette> /quit
<leoprikler>chrislck: I assume you mean (define addr-getter ...)?
<leoprikler>Also, Tsukundere does that without error.
<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!
<leoprikler>are they?
<leoprikler>perhaps you're forgetting an srfi
<chrislck>try in repl
<leoprikler>repl is not reliable for that kind of check
<chrislck>they're in boot.scm
<leoprikler>try in script
<chrislck>no probs inscript
<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))
<chrislck>still unbound
<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>all .scm code loaded via libguile.h
<chrislck>and updating to 3.0 was painful, but done
<chrislck>now updating to 3.0.4 is showing some warnings...
<leoprikler>bitvectors am i right?
<chrislck>nonetheless this set-tm is harmless (for now) and I'll try figure out how to export record getters/setters
<tohoyn>sneek, botsnack
<dsmith-work>Happy Friday, Guilers!!
<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
<leoprikler>I believe on ./configure
<leoprikler>but may be sooner
<tohoyn>./ does not generate it
<tohoyn>neither does autoreconf -vif
<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>so it should be created by make
<tohoyn>which Ḿakefile?
<leoprikler>top makefile
<leoprikler>the code for generating it should be generated by autotools
<leoprikler>specifically automake creates, then → Makefile through configure
<leoprikler>I think automake does that when it sees info_TEXINFOS and the like
<leoprikler>meaning you'd need texinfo for that to work
<tohoyn>I can't find the code for version.texi in the top makefile
<leoprikler>do you have texinfo on your machine?
<tohoyn>yes, and building g-golf normally works fine
<leoprikler>hmm does g-golf have subdir make?
<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>so there is extra #
<tohoyn>which is probably the reason why the code does not work
<leoprikler>how did this get there?
<tohoyn>no idea
<tohoyn>I use debuild to build the package
<tohoyn>I generated the debian files with debmake
<tohoyn>found the following in doc/ $(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>Now I get "4 of 6 tests failed"
<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?
<tohoyn>already found
***sneek_ is now known as sneek
<srandon111>anyone running guile on dragonflybsd ?
<chrislck>leoprikler: thx for pointers -- you gave confidence that modularisation could progress and it did
<leoprikler>I did? Modularisation of what?
<leoprikler>Either way, I'm honoured :)
<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)
<mwette>(sleep 60)
<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.
<dsmith-work>Thanks. I think I'll give it a try this weekend.
<civodul>yeah load-compiled does the trick, but plain use-modules does not