***karswell` is now known as karswell
***michel_mno is now known as michel_mno_afk
***michel_mno_afk is now known as michel_mno
<ajnirp>when would i use a vlist and when would i use a hash-table? <ajnirp>AFAICT they both have constant-time key access, which i want <ijp>well, that is only truthy in both cases, but anyway... <ijp>the hashtable api is very imperative, the vlist one is slightly more functional, I guess <ijp>and vhashes would make for a better comparison than vlists <ajnirp>ah right sorry, i meant to say vhashes <ijp>you might also consider my hamt code if you want an immutable map, but that doesn't come with guile <ajnirp>so it's a stylistic difference for the most part? the mapping i need only has 255 entries at most so speed isn't really a worry <Arne`>short feedback: I always forget the header for calling a guile module from the shell, so I think it would be useful to have a short option. <Arne`>(I write this now, because I have to look up again how to write the header) <davexunit>I have used delimited continuations a bunch and this explanation is helping me understand them better. <daviid>very funny, the type system especially ... haha ***michel_mno is now known as michel_mno_afk
<daviid>do we have something like racket's ffi/cvectors ? <bipt>Arne`, re: your questions from yesterday, loading .elc files doesn't work at all because the byte-code interpreter is gone, and you can't currently pre-compile elisp because guile doesn't know how to dump/load elisp strings <bipt>Arne`, i pushed a change that should stop it from trying to load ".elc" files <ArneBab>bipt: Do I guess correctly that to get guile-emacs fast, you’ll have to compile it to guile *.go modules? <bipt>ArneBab, yes, either that or write a jit compiler :) <ArneBab>wouldn’t the existing compilation from guile already help a lot? <ArneBab>bipt: guild can already compile some elisp files <ArneBab>$ guile/bin/guild compile --from=elisp ./emacs/share/emacs/24.4.50/etc/themes/deeper-blue-theme.el <ArneBab>wrote `/home/arne/.cache/guile/ccache/2.2-LE-8-3.6/home/arne/guile-emacs/emacs/share/emacs/24.4.50/etc/themes/deeper-blue-theme.el.go' <ArneBab>bipt: would this work? find . -iname *el -exec guile/bin/guild compile --from=elisp {} ";" <ArneBab>seems that it only works for some files <bipt>ArneBab, not currently, because emacs uses a different string type and the elisp compiler/reader/etc. only use it when run in an emacs process <bipt>also some programs probably depend on functions from the emacs C runtime to compile <bipt>not for use in emacs, because the string literals will have the wrong type when loaded <ArneBab>ok, so I should stop the precompilation h) <bipt>yeah, at least for now :) <bipt>another problem is that guile only allows you to load a fixed number of compiled programs, so it's not practical to simply compile and execute each toplevel form as a file is loaded; guile-emacs has to 'eval' tree-il expressions to avoid hitting the limit <bipt>if the limit didn't exist, startup would still be slow (maybe slower!) but overall performance would be better <civodul>bipt: a fixed number of compiled programs? <bipt>oh, i should have added that it only happens in master <bipt>the limit is several thousand roots (libgc's MAX_ROOT_SETS), so it's not normally a problem <bipt>(and 'mutable constant data' is not the best phrasing; IIRC a root is added for mutable ELF sections that contain non-immediate literal objects, which the loader must initialize) <bipt>paroneayea, i think your guile-emacs guix package builds successfully after today's emacs update (testing with commit e709371) <civodul>bipt: oooh, i had overlooked that one <bipt>paroneayea, i haven't fixed the load-path heuristics so to run it you have to set EMACSLOADPATH to $d:$d/international:$d/emacs-lisp:$d/leim where $d is the directory where the lisp files are installed <paroneayea>bipt: hm, okay. The thing will be "make install"'ed and that's the version of emacs that's run <paroneayea>and maybe I can set a post-make-install build phase, or something <paroneayea>because the build directory will not be kept around or be accessible <bipt>it's set by load_path_default in lread.c. "normal = PATH_DUMPLOADSEARCH" is what makes it look in the source dir ***cluck` is now known as cluck
<paroneayea>so if I set the environment variable, will that affect it? <paroneayea>bipt: forgive me, I'm not very suave when it comes to autotools <bipt>paroneayea, PATH_DUMPLOADSEARCH is set in src/epaths.h which is generated with autotools. its value is ok, but it should only be used as the search path while building <bipt>PATH_LOADSEARCH has the normal default load paths, but when dumping is disabled, emacs doesn't use the code that would normally choose the path based on whether it's running from the build directory or not (i don't know why it doesn't) <paroneayea>bipt: btw what is "dumping is disabled", dumping core or something? <paroneayea>also, how would you suggest I change said path? Should I modify it after the fact by substituting the text that autotools generated, or is there a flag I can pass into the autotools pipeline, or? <bipt>and as the author hoped, guile-emacs does get rid of it, because it's a really fragile process and, for example, doesn't work at all when libgc is used <dsmith-work>Most lisps have historically done something like unexec, didn't they? Write some code, test, save the memory image. repeat. <paroneayea>So that’s why. Pauses are only perceived as OK if they free memory. Reminds me a bit of the story about Erik Naggum deactivating the garbage collection messages Emacs displayed back then to see whether it would end the complaints of it being slow coming from a group of Emacs users. Surprisingly enough, it did." <paroneayea>I've just been C-x C-e'ing all these years in scratch bufferse <cluck>dsmith-work: afaik, yes, it was a common practice because it saved some very precious resources (it's also a rather straightforward hack that speeds things up quite a bit for relatively little effort) <cluck>paroneayea: then your mind is going to blow when you find out about eshell 