<ArneBab_>johnjay: when I say Guile Emacs, I mean every Emacs package working with the elisp implementation in Guile <ArneBab_>johnjay: but that needs someone to take up Guile Emacs and finish the opitmization work. <str1ngs>ArneBab_: I have been meaning to look at scheme and elisp interaction. specifically calling scheme from elisp <johnjay>ArneBab_: i guess. but that would mean porting every package to a certain extent <johnjay>but to that idea: why would you need to? <str1ngs>johnjay: not really it would essentially be Emacs but using guile elisp <johnjay>if something is related to text editing then put it in a program called guile-super-text-editor <johnjay>if it's not then put it in nomad-browser. or guile-player. or guile-scape. etc <str1ngs>johnjay: Guile Emacs is Emacs that uses guile for elisp <str1ngs>so you would not have to port packages, you just need to port Emacs <johnjay>i guess. but you are calling elisp from scheme in that scenario which sounds messy <johnjay>mitscheme has that edwin thing right <str1ngs>problem is guile elisp is really good it has jit bytcode etc. but Emacs developers don't want guile. <str1ngs>it's kinda a shame because it would reduce duplication of effort <str1ngs>you can edit text with nomad btw try M-x find-file <mwette>What about a translator that converts elisp to scheme? Doable? <str1ngs>the underlying text buffers work great but the GUI implementation needs work. <str1ngs>there is no need to translate elisp to scheme you can just use language elisp <mwette>unless you want to write new extensions in scheme <johnjay>if the goal is elisp from guile then what's wrong with doing the slow way <johnjay>like, make the interpreter implement the emacs interpreter ***catonano_ is now known as catonano
<johnjay>i specified -j3 and it's still going <johnjay>mwette: well honestly that's going to have to happen at least for c-mode <johnjay>some of the complaints people make are about slow speed on syntax and indenting <johnjay>so you'd need to rewrite it to use threads ***apteryx is now known as Guest33093
***apteryx_ is now known as apteryx
<ArneBab_>str1ngs: well, the porting to guile-emacs never included the bytecode-improvements needed to actually make guile-emacs fast. <ArneBab_>johnjay: elisp in Guile already exists. Just start Guile as guile --language=elisp; then try (defun foo() (print "foo")) (foo) <wingo>hoo, i would hesitate to do serious gc hacking in c without constexpr. i really miss that from c++ <civodul>constexpr is pretty cool, i miss it even in Scheme :-) <wingo>how important is it to be able to compile guile with only a C compiler? <wingo>obviously we have C ABI that we need to preserve <wingo>but inside guile we could use whatever. i don't know what the tradeoffs are <civodul>from a bootstrapping perspective, having Guile in C is great <civodul>even if it's not a property we take advantage of currently because we first build GCC <civodul>but in theory, we could do mess -> mescc -> [...] guile <wingo>that would be some serious heavy lifting <civodul>so what i mean is we can do that if Guile is in C, but we can't if it's in C++ <wingo>i am just saying that there are tradeoffs and we should be sure that we're making the right ones <civodul>so i find constexpr great, but i wonder the extent to which it would simplify the implementation of a GC :-) <wingo>yeah, just wondering if e.g. avoiding gcc or clang is (1) really feasible and (2) important <wingo>right, it's just one thing :) <civodul>i also wonder how much of the GC could be in Scheme <wingo>Handle<SCM> would be nice too :) <wingo>in general, RAII-like abstractions would be really nice <wingo>but it's not a thing for c, obviously <wingo>anyway, might not be possible <civodul>there are various GCC attributes for things like destructors (heavily used in systemd) <wingo>civodul: can't rely on them though <wingo>like the whole point would be to be able to rely on a standard <wingo>if we prevent compilation from tcc, we gain nothing <civodul>anyway, i guess i can see C++ has nice features while being at the same time on the not-fond-of side :-) <ArneBab_>wingo: having more of the gc in Scheme sounds interesting <johnjay>civodul: what exactly is the bootstrapping? <johnjay>you compile a certain version of gcc then compile guile then use guile to compile scm? <dsmith-work>johnjay: Guile uses compiled .go (Guile Object) files. The compiler is in Scheme. There is a minimal "bootstrap" interpreter/compiler written in C that is used before the Scheme compiler has been compiled. <johnjay>right that's what the other schemes do <johnjay>c compiler compiles the scheme compiler which compiles the scheme <dsmith-work>The distribution tarballs contain pre-compiled .go files for various machines. <dsmith-work>Building from a tarball is *way* faster than building from git. <johnjay>right. so the scheme compiler part is called mess? <dsmith-work>No, that's a different project. I thought you were talking about building guile. <dsmith-work>There is an effort to get resporoducible builds from base human readable sources. Completely bootstrap the whole tower from nothing. <dsmith-work>The normal guile build just uses your system C compiler. (or whatever you ./configure) <johnjay>if you'll indulge me once more, what is "reproducible"? <johnjay>as in, a c compiler compiles everything? <ArneBab_>johnjay: you start with human-verifiable hex and only ever add human-readable sources to arrive at gcc that can compile everything, and you never needed binaries a human cannot check for that. <ArneBab_>johnjay: in a perfect world you start at pure sources with a given hash, and the binary you get is always the same if you compile them again. <ArneBab_>You could say that the commit-IDs of all the source-code repositories involved (containing only human-readable stuff) should always lead to a binary with the same hash. <str1ngs>hello, daviid I hit a bit of a hiccup with a new patch to version bump g-golf in guix. The original submission had version 1 which does not reflect the autotools version 0.1.0 . The patch was merged before I can fix it. I've now updated it to 0.1.0 but that might cause an upgrade path issue. My proposal use the autotools version as being more correct. is 0.1.0 okay with you? It's better to fix this now than later. <g0d_shatter>asking again so forgive the noise, but does anyone know if the recently updated GDB->Guile bindings will now also work with guile-3.0?