IRC channel logs


back to list of logs

***karswell` is now known as karswell
<nalaginrut>morning guilers~
***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)
<dsmith-work>Tuesday Greetings, Guilers
<paroneayea>ohhhhhh this post was very useful for me
<taylanub>wow, that's hell of an aswer
<davexunit>paroneayea: yeah, wow! that's great.
<davexunit>I have used delimited continuations a bunch and this explanation is helping me understand them better.
<paroneayea> (sorry to link this blog again, but perfect this time)
<davexunit>paroneayea: hahaha
<daviid>very funny, the type system especially ... haha
<nalaginrut>interesting ;-)
***michel_mno is now known as michel_mno_afk
<zacts>hello guilers
<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: thanks!
<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'
<stis>evening folks!
<ArneBab>good evening stis ☺
<ArneBab>bipt: would this work? find . -iname *el -exec guile/bin/guild compile --from=elisp {} ";"
<ArneBab>within ~/guile-emacs
<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
<ArneBab>bipt: are those which compile ok?
<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?
<civodul>where is that limitation?
<zacts>davexunit: mark_weaver:
<zacts>(if you have x11 enabled)
<taylanub>a keyboard for ants :D
<bipt>civodul, it's due to the use of GC_add_roots with ELF images that have mutable constant data
<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
<civodul>this is terrible
<paroneayea>bipt: !
<paroneayea>bipt: aweesomeee
<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>could you show me where the path is set
<paroneayea>and maybe I can set a post-make-install build phase, or something
<paroneayea>that has access to it?
<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>bipt: cloning and checking it out...
<paroneayea>bipt: what sets PATH_DUMPLOADSEARCH ?
<paroneayea>I see
<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>by dumping i mean the process described in
<paroneayea>haha what a domain
<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
<cluck>zacts: never laugh at history, because it repeats itself and laughs back at you when you least expect it
<dsmith-work>Most lisps have historically done something like unexec, didn't they? Write some code, test, save the memory image. repeat.
<paroneayea>bipt: wow, that blog
<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>also how did I never know about M-x ielm
<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
<paroneayea>cluck: oh I knew about eshell
<paroneayea>but I don't consider that a traditional repl
<paroneayea>well, it is a traditional repl