***michel_mno_afk is now known as michel_mno
<musolinoa>Is it possible to modify a C variable using the FFI? In particular, I want to modify a global string in libreadline. <musolinoa>I know how to read its contents, but I can't see how I can transform it and write it back. <adhoc>is there any kind of Continuous Integration tools in guile ? ***michel_mno is now known as michel_mno_afk
***michel_mno_afk is now known as michel_mno
<wleslie>gah people probing for old routers on most channels <please_help>What would be the best way to attach information to an array? Use a record that include an array slot? <please_help>In general, is there any way to more efficiently perform the same operation over each element of an array? (in terms of the constant). <taylanub>please_help: there's `make-object-property' or some such for attaching extra information to arbitrary objects; this internally uses a weak-key hash-table <taylanub>(or ephemeral, i.e. weak-key-weak-data. not sure which is correct here.) ***michel_mno is now known as michel_mno_afk
<solrize>anyone know how much ram you need to run guile embedded, with fairly small scripts? <davexunit>solrize: I'm not sure, but I just launched a Guile REPL and checked the initially memory usage: 7.4MiB <davexunit>how memory restricted are you that 8MiB is an issue? <davexunit>note that I have *no idea* if using the Guile C API uses the same amount of memory <solrize>well i personally do lots of stuff in 128 meg vps containers, other people use mobile phones that have lots of suspended apps, etc. so i think keeping the ram footprint reasonably small is important. lua runs ok with 64k of ram, though the lua repl is about 1 meg (i just tested with "ps u") <davexunit>lua is built to be very lightweight, so that makes sense. <solrize>guile is supposed to be an extension language embeddable everywhere, so if it's not competitive with lua space-wise that impairs its mission <davexunit>I feel the need to make an important distinction between embedding and extending. <davexunit>it's preferable to extend an application with guile, rather than embed guile. <taylanub>remember that Guile's run-time includes its compiler, being a Lisp environment and all. the power comes at a cost. <solrize>but why is the compiler part of the guile runtime? why isn't it just a guile script that you load into the vm? <taylanub>hm, maybe loading only libguile doesn't load the compiler; I'm not sure now <davexunit>disclaimer: neither myself nor taylanub are guile maintainers, so we have limited knowledge of the implementation details. <solrize>i've been using guile as a general purpose scheme repl and it's fine for that, but an embeddable scheme seems like a different goal <solrize>i like the lua vm but the language itself is yeccch <taylanub>I think the word "embeddable" has a few different meanings <davexunit>I think embedding is an inferior technique for application extension. <solrize>lua does it really well, and it was part of the goal of guile, i thought <taylanub>specifically, "embedding an extension language engine/runtime to your C application" doesn't carry any implication of it running on "an embedded system". <solrize>like i'd consider emacs lisp to be embedded <solrize>embed vs extend i thought distinguished between what part of the program owned main() <solrize>i.e. if main() is part of your c program and loads guile and passes stuff to it, that's embedding <solrize>but if main() is part of guile and your c program is some .so's that guile loads, that's extending <davexunit>though of course it's better to just write it all in Scheme instead of writing C <taylanub>and I don't think Guile ever had the express goal of running well on "embedded systems," rather being embeddable into larger applications as an extension language (though the newer trend I think is to turn your application into a number of library extensions *for* Guile, then make the main corpus of your program a Guile script) <solrize>yeah when i spoke of embedding i meant an embedded interpreter in a c program (like emacs lisp is embedded in emacs) <solrize>not something that runs on a microcontroller <solrize>anyway this distinction is irrelevant, the point is that even on enormous servers there's still some value in keeping programs from getting unnecessarily bloated. thus comparing the size of guile vs lua is valid. <taylanub>well in that case 8M is really minor on modern hardware, even decently new smartphones (I develop iPhone apps; we can use up to hundreds of MB of memory. coworkers program for Android and I don't think they support devices with that little amount of memory either.) <solrize>didn't you just tell me the repl is 7 meg? <solrize>i don't use a smartphone but i keep being told that people who use them are constantly running "process manager" and killing apps <daviid>solrize: i don't think so, you are comparing thigs that just can not be comprared, hence th impossible... :) lua will never ever give the smalest pat of the power you have programming in scheme.. just as a reminder... <solrize>if the app used 20k instead of 7 meg you could have hundreds of them running and not have to kill them <dsmith-work>solrize: You might be interested in chibi scheme. Smaller than Guile. <solrize>daviid what is the diff between lua and scheme, other than lua's godawful syntax and lack of type safety? <davexunit>both of which are less featureful, but have a smaller footprint. <solrize>i haven't used chibi scheme but have been looking at tinyscheme, picobit, and microscheme <solrize>is chibi scheme related to chibi os? <taylanub>Chibi is cool but just FYI, be warned about its small (near to nonexistent?) userbase and therefore unpolished codebase (I hit some silly bugs immediately when I tested my R7RS SRFI implementations on it. Alex Shinn was very quick to respond to my bug reports though.) <solrize>is call/cc in r7rs? i remember there was some talk of replacing it with delimited continuations <taylanub>call/cc will remain for backwards compatibility, and so far there's no delimited continuations standardization in any RnRS or SRFI :( <davexunit>to give you ideas about what might come in the future: someone embedded tinyscheme into the early HURD boot process, which opened the doors for neat things that weren't possible before. <dsmith-work>solrize: Lua as a language was designed to be small and embeddedable, with a very small and efficient VM. Scheme is a standard language, not specifically designed for embedding. <daviid>solrize: if there are no diff, just use lua? <davexunit>we'd like guile to fill that role, so there's been some musings about making a stripped down, statically linked guile that can do it. <solrize>daviid, i don't want to use lua because of its godawful syntax and its lack of type safety. what i'm asking is what difference between guile and lua accounts for the size difference? if anything lua should be bigger because its godawful syntax requires a full blown parser instead of just a lisp reader <solrize>tinyscheme is a very small program but has a big ram footprint because it's a tree walking interpreter instead of a vm, and most of its standard vocabulary is in a scheme library that it loads, so it immediately conses almost a megabyte of sexps just to hold the standard functions <daviid>i m off this conversation, good luck <taylanub>that's a pretty simplistic way to look at it :-) what do you mean with lack of type safety by the way? does a Lua program misbehave/segfault (instead of aborting with an uncaught exception error) when you pass an object of the wrong type to a function? <solrize>i mean (1 + "1") doesn't throw a type error. it's like perl and javascript that way. <dsmith-work>Down the road, things may be way better. Guile 2.2 uses elf as the compiled output foramt. Still soemthing like bytecodes for a VM, but eventually (2.4?) will be native code. There are hopes we can build completey native execuables in Scheme. (Woo!) <taylanub>oh, muddy polymorphism baked deep into the language (not sure if there's a precise term for that but I think "type safety" is not it) <taylanub>dsmith-work: hm, I thought we didn't want to go all-native for some reasons? <solrize>taylanub, yeah, maybe there's some other term for that. like "doesn't prevent type confusion" <taylanub>(and with "we" I mean the core developers which doesn't unfortunately include me :P) <solrize>there's tons of native code scheme implementations and featureful implementations around, and if the guile maintainers want to write something like that, then that's great for them, but then that leaves an unfilled need for an extension language for non-scheme programs <taylanub>compiling to native instructions doesn't contradict embeddability <dsmith-work>solrize: It will still be able to extend C programs. <solrize>compiling to native instructions means retargeting the guile compiler to every platform the embedding app has to run on <taylanub>I think that was indeed one of the reasons cited for "the bytecode VM will still be there for a looong time" <dsmith-work>solrize: True. But it doesn'e HAVE to be native everywhere. <solrize>oh ok, that's reasonable, if there's some native targets but also the bytecode vm <solrize>anyway what brought this on was i was just looking at zile (stripped down emacs-like editor that's part of the gnu project), and its developers are talking about rewriting it in lua (it's currently in C) and the possibility of getting resistance from the gnu project because it's not in guile <solrize>and the obvious response is "well why not use guile instead of lua" <solrize>and one issue seems to be, an explicit goal of zile is to be small, so if guile bloats it up then guile isn't doing the job of a use-everywhere extension *taylanub wonders how this would relate to Guile-Emacs <solrize>taylanub, guile-emacs is full blown emacs with guile replacing emacs lisp <solrize>i.e. still a big program with tons of creature comforts <taylanub>I know, just wondering if there would be interaction <solrize>yeah it would be nice if there was some communication between them, but right now guile-zile isn't even a serious hypothetical <taylanub>anyway, if Zile intends to be tiny (like vi(1) and mg(1)), then Guile might be out of the question for the foreseeable future (but don't quote me on it; I have no idea what currently makes Guile big in terms of memory usage) <solrize>yes, that's the intention of zile, but i have to say that it's currently about 200k which i'd consider "small" rather than "tiny" <davexunit>you have an unrealistic expectation of memory usage on modern systems. <solrize>davexunit it's not just the mem usage, it's also the download size <solrize>every time i try to run a command on a new small vm, it's not there and i have to stop what i'm doing and apt-get install <solrize>and at slow times of day the download runs at 20k-30k a second <solrize>so a 200k download is tolerable but 10 meg is a pain in the **** <solrize>and i think because of containerization, "modern systems" are now smaller than they used to be <solrize>those are much more modern than the 512 meg pentium boxes from the early 2000's :) <taylanub>honestly I wouldn't be too bothered by a lisp environment taking 1/16 of my memory in such a highly constrained environment. something like Lua is just an entirely different thing. <solrize>well i'm not one of the zile developers but it sounds to me like they might think it's an issue <taylanub>sure, if they wanted an editor that includes a full-blown lisp environment then they would just use Emacs :) <solrize>right, so are you saying guile is only suitable for big programs like emacs? we're going in circles, a 200k program is not minimalist, it's reasonable to want it to be extensible <taylanub>in other words it sounds to me like Guile (in its current state) is simply the wrong choice for them. <solrize>yes, it does look that way, and imho it's reasonable to call that a deficiency of the current state of guile, rather than saying zile is a special application with niche requirements <solrize>i wanted to customize something in zile, couldn't figure out its customization interface so i thought hey, i'll just hack my customization into the C code and rebuild it, and then it turns out that it has about a zillion build dependencies <solrize>so having a script interpreter in zile would be very useful <taylanub>I would see Guile *broadly* in the same category as Emacs, though Emacs ships with many more libraries. on my system, a fresh 'emacs -nw' instance uses 21 MB of residual memory, a fresh 'guile' instance 15. <dsmith-work>Guile was often criticized for being non-standard. It's much more standards compliant now. And that does add stuff. <solrize>well i don't know what the guile repl is really doing. is there a "hello world" that loads libguile? <taylanub>solrize: the manual might have something like that. IIRC it's as simple as calling scm_init_guile() or so in your main() <dsmith-work>YEah, that's basically what the guile executable is. Just a thin wrapper around libguile. <taylanub>dsmith-work: it could be that calling the REPL makes libguile load the compiler module or so? <solrize>i thought tinyscheme was r5rs compliant, and it's about 40k <solrize>and that includes the reader and printer written in c <solrize>i'd imagine an extension interpreter to just have a lua-like bytecode vm in the loadable library, and the reader, printer, and compiler would all be written in scheme <dsmith-work>solrize: One of the problems of being an extension language, is you need to obey both C and Scheme (for lack of a better term) "stack" protocols. <solrize>dsmith-work, yeah, but it's not too big a problem for emacs lisp, which i used to understand pretty well at the C level. i've never looked at guile's implementation though <solrize>hmm yeah if you want to support continuations... <dsmith-work>solrize: Think C -> Scheme -> C -> Scheme and call/cc <taylanub>hm, how do I find out the "true" memory usage of a program that loads libguile? I have a trivial test.c doing scm_init_guile() and sleeping and top(1) says it uses only kilobytes of memory; libguile.so being 2.2M I'd expect it to use at *least* that much? <taylanub>(well, I suppose not all sections of an ELF .so need to be loaded into memory. I know very little about this stuff...) <davexunit>taylanub: try calling some scheme functions? <taylanub>huh, a CLI tool I had never heard of, I thought this doesn't happen anymore :P <taylanub>was about to ask if you mean "du -sh" :P <solrize>taylanub, can you sendlibguie some scheme code that writes the letter "a" to stdout? <solrize>is call/cc really necessary? lua has coroutines but not first class continuations <taylanub>call/cc is unnecessary when you have delimited continuations :) <taylanub>if I'm interpreting size(1) output correctly, libguile should load at least about 1.5MB into memory <solrize>well if scheme inflicts call/cc on every implementation then was it really that good a choice as an extension language? but, i guess the wisdom that call/cc is overkill is relatively recent <taylanub>I think you're too fixated on the size of an extension language runtime. it's a neat feature to be small, and maybe Guile will have it one day, but there are many other goals to achieve. <dsmith-work>I was appalled that lua doesn't have bit operators! (I tried to use it as a wireshark dissector once.) But that's just one example of trimming out stuff to make it small. <solrize>well if being small gets more programs to use it, then that's a good goal. i mean what other goals are there? being a high performance app development system doesn't seem like a really worthwhile one. not many people want to write applications in scheme. <solrize>dsmith-work, they finally fixed that, in lua .3 <solrize>it didn't even have integers before :) <solrize>picobit's runtime is around 10k including call/cc and bignums <solrize>but, it's c interface is not so good <taylanub>solrize: I think having amazing debugging/development experience in the Lisp tradition is a very good feature. see e.g. Emacs. <dsmith-work>Not sure what the progress is, but there have been attemps at adding a lua language frontend to guile. I'm sure it won't be as eficient as lua. Well, not until we have native code. <taylanub>hm, I let libguile do something nontrivial by calling scm_c_eval_string("(display \\"foo!\\")") but the program still uses a tiny amount of memory. 48k virtual, 8k residual, 3k shared. *shrug* OS magic I guess <solrize>taylanub, the emacs debugger is a loadable lisp library, it's not loaded into emacs when you're not using it <dsmith-work>taylanub: Yeah, I had to mess around with ps when I was trying to locate a memory leak in sneek <taylanub>ugh, yeah, apparently top(1) implies KiB when there's no suffix <dsmith-work>taylanub: mark-weaver suggested the correct things to look at. <wingo>guile -c '(sleep 100)' uses 1.86 MB of private dirty memory <wingo>guile 2.0 uses 3.1 MB of private dirty memory for that same task <wingo>that's probably just because guile 2.2 lazily grows the stack <wingo>this is measured from /proc/PID/smaps <wingo>i have a guile thing for the same purpose but i got used to a previous version in python :P <solrize>i remember rms saying microemacs (forerunner of zile) would have been better if it had a forth interpreter embedded for user extensions <solrize>carl is interpreter size an issue for guile as an extension? 3MB of dirty memory per client sounds enormous <solrize>even if the size of libguile isn't important since it's shared <solrize>andy right? carl wingo is someone else entirely <solrize>carl wingo is a cs grad student i knew a while back, so his being involved with guile was not inconceivable and somehow i thought you were him <solrize>it seems relevant to that slide deck <solrize>the main thing i kept thinking is C is a dinosaur that should really have been outlawed by now :) <taylanub>solrize: I think it's customary to use a person's nick on IRC so their client can do highlighting properly <solrize>i guess calling someone by their last name just felt sort of rude <solrize>Geiser is a collection of Emacs major and minor modes that conspire with one or more Scheme interpreters to keep the Lisp Machine Spirit alive. <solrize>the spirit of the lisp machine was one huge namespace with a million programs stomping on each other, i thought <taylanub>that's just Emacs nowadays :P except they don't stomp on each other even in Emacs (despite single namespace + dynamic scoping) because people keep to some simple best-practices <solrize>that plus emacs is single threaded :) <solrize>i want something like a poor man's erlang, i.e. a scheme where the vm itself is a first class value and you can cons up new ones that can communicate by message passing, but have completely separate heaps and maybe separate gc's <solrize>i like hedgehog lisp's vm and have thought about adding something like that to it <solrize>the slide deck i linked further up is interesting and makes the case for writing the application top level in guile... that turns guile into something like JVM or CLR though <taylanub>AFAIK the JVM and CLR are *much* more heavyweight, and integrate less with a traditional Unix environment; a better comparison would be e.g. Python <solrize>does guile support ecmascript for realsies? <taylanub>not really; there's some incomplete parser IIRC which can run some code <taylanub>likewise for Lua IIRC. the only fully complete languages are Scheme and brainfuck :P (the latter is for the sake of a simple example on how to write new language front-ends.) and the Elisp front-end is pretty much or almost there on bipt's repo. <solrize>is there really a serious attempt to replace emacs lisp with guile in emacs itself? like, will it still be able to run calc.el? <solrize>but, sometimes i feel like bertrand russell the day he rode his bicycle home from work and realized he didn't love lisp any more :( <bipt>solrize, it can _already_ run calc.el along with the rest of emacs :) <taylanub>I think if I were a mathematician, I wouldn't like any programming languages either ;) <solrize>there's a quote from someone on #haskell that i always remember, "PenguinOfDoom: Being enlightened gentlemen, we split all <solrize> programming languages into two groups, sucks and doesn't-suck and <solrize> put all of them into the first group." <solrize>bipt does anyone care about the speed of emacs lisp any more? once i stopped seeing calc.el pausing and gc'ing all the time, i figured lisp had arrived :) <solrize>A third advantage is all Guile APIs/libraries becoming available to Elisp code --- do many such libraries actually exist ? <dsmith-work>solrize: That's like a guile package repository thing. *dsmith-work hasn't used it <solrize>Guile is getting pretty good now, but there is more to be done before it is as cheap to run a program written in Scheme as it is to run a program written in C. <bipt>solrize, speed means more things can be written in elisp/scheme instead of c <solrize>but kind of different than an extension language *jao is also interested in guildhall's status (that blog post if four years old) <solrize>bipt i think emacs would be these days if it were 100% in scheme <solrize>using one of the native compiled schemes <solrize>s/would be these days/would be ok these days/ <solrize>although, i'm disillusioned with the concept of writing big scheme or lisp programs <solrize>it might be interesting to target purescript to guile <taylanub>solrize: re. "Guile APIs/libraries becoming available to Elisp", that includes e.g. the FFI, record types, many SRFIs, SXML, guile-opengl, guile-wm, ... not a huge number of Guile libraries, but some very significant ones that Elisp lacks. <solrize>hmm ok, so we'll be able to have serious GUI's written in emacs, i guess that's something <bipt>as well as the numeric tower and, if the emacs developers approve, a module or package system <daviid>as well as goops, guile-gnome, guile-clutter, guile-cairo, guile-charting... <ArneBab_>solrize: even a tiny KDE program like kollision uses 11 MiB RAM, and guile already provides many features out of the box which aren’t used in that program (it’s repl loads many convenience libraries). So I don’t consider it big. <solrize>ArneBab_, if kollision uses 11mb it is not tiny :). 11mb is reasonable for a gui client running on desktop hardware these days but it's on the large side for a mobile app, and bloated for a headless command line program <ArneBab_>solrize: for the download size, guile is perfect: You download guile once, and then all additional scripts are tiny. <ArneBab_>solrize: kollision is tiny compared to other KDE programs - desktop GUI. <ArneBab_>solrize: I agree that it isn’t tiny by the standard of sed and grep, but it shows the current standard for “small” <ArneBab_>Also Emacs was called “Eight Megabyte And Constantly Swapping” ← Guile is still well below that ☺ <taylanub>solrize: by the way, would you consider Emacs a big program, in terms of project size? <ArneBab_>“It effortlessly handles numbers with a size on the order of 10⁸⁰⁰⁰” <solrize>emacs is big enough to create a reason for zile to exist, so in that sense it's big. certainly i think c programs the size of emacs shouldn't be allowed to exist any more, so in that sense it's also big. i agree about exact math being important and picobit supports it and it uses maybe 1k or 2k of code space there, so it doesn't justify a 7mb image <bipt>ArneBab_, that's pretty neat :-) i found guile very nice to use for project euler problems thanks to the numeric tower <ArneBab_>solrize: does picobit provide the same performance? <solrize>ArneBab_, definitely not but for an extension language imho that is ok. <ArneBab_>a newly started python takes almost 10MiB for me <solrize>python on 32-bit linux uses about 3.5M according to ps u just now <ArneBab_>solrize: whether being slow is OK again depends on the usecase. <ArneBab_>the more you do in Scheme (i.e. because you use your the extension language in your own program), the more its performance matters. <solrize>ArneBab_, if you want the extension language to be fast then it needs a compiler, but the compiler doesn't have to be resident in the runtime image 100% of the time <solrize>the more you do in scheme, the more you're using it as the application implementation language and not as an extension language <solrize>i don't think they are the same thing <ArneBab_>if you use the language you want your users to use for extension, then chances are high that extending the program will be a nice experience. <solrize>extension language to me means the application is written in $LANG but you want a more flexible mechanism for user customizatoin than just having a config file <ArneBab_>and once users have a turing complete language for customization, they will turn your program into a kind of Emacs - just look at blender :) <ArneBab_>solrize: in short: I think it is a good thing when more and more parts are written in the extension language <solrize>hehe. i haven't looked at blender but, i don't think that has happened with gimp <ArneBab_>the scheme in gimp didn’t really take off, yes. I think that’s sad <ArneBab_>lots of plugins there, but it always feels bolted on to me <ArneBab_>solrize: for scheme, the compiler does macro expansion of expressions you write at the REPL, so it needs a compiler at runtime. <solrize>ArneBab_, nah, a simple interpreter is good enough for that <ArneBab_>or put differently: Guile allows you to customize the compiler while you use it. <solrize>by compiler i mean something that makes optimized native machine code <ArneBab_>that’s not what the compiler it Guile does (right now) <bipt>well, then guile already lacks a compiler and it's not contributing to the library size (: <solrize>and, you might have reason to write the main app in java or haskell, which have huge pervasive runtimes of their own and you can't really extend guile with a JVM. it's reasonable though for a java program to call libguile through JNI <ArneBab_>guile -q -c '(sleep 100)' only takes 2.8MiB <ArneBab_>-q means: Don’t load my user init file (which for example adds readline). <ArneBab_>lua is 316KiB, but different from Guile, Lua is built to be tiny <please_help>would it be possible to add a "minimal runtime" that could be enabled with an option that's in this kind of size range? <ArneBab_>hm, detailed memory usage shows 4.8MiB (via KDE memory monitor) <ArneBab_>according to KDE it isn’t - you’ll have to ask others for details. <ArneBab_>if I start another instance of guile, libguile is shown as shared <ArneBab_>and the memory usage as 3.4MiB, with 2.9 of that privately, of which 2.676kiB is heap <please_help>is the heap preallocated in huge chunks or something? <ArneBab_>wingo said something to that effect (as what he optimized for guile 2.2: less heap preallocation) <solrize>my feeling is that everyone will always have their favorite languages, and it's not nice to ask people to write big programs in languages they don't like, but it's ok if the programs are small. so maybe i'm fine with writing little extensions or customizations in scheme but want to use $LANG for the main application. the whole point of an extension language is to enable that approach. if you want to write the whole app in scheme, that's great, bu <solrize>t stop calling it an extension language :) <taylanub>it is an extension language because you can put it in your program and extend it. nobody ever put a size limit on extension languages, did they? :) <ArneBab_>solrize: did you look at the stats of the second guile instance? <please_help>But what if I want to use guile as an extension language on a small system that doesn't have that much memory? <ArneBab_>so we could ask, why guile uses 2.6 MiB heap. <solrize>yes, hedgehog uses a pretty simple encoding and has a generational semispace gc and claims to run ok with 256k of ram or so <bipt>please_help, i would not use guile in low-memory embedded applications without customizing it. there are scheme systems that are better suited for that task <ArneBab_>in the previous version (lower down in the paste) KDE did not properly detect libguile memory as shared. <solrize>ok that's the non-shared part, and there's 1mb shared <bipt>please_help, then modify guile so it works for you :-) <ArneBab_>solrize: you’ll want to write many programs with guile, then the 1MiB shared don’t matter *taylanub wonders what stuffs that 2.6 MB heap contains <bipt>if your question is not hypothetical, you could post your situation and the problems you're running into on the mailing list <taylanub>hm, the shared libguile is just the VM, and the heap contains all Scheme modules perhaps? maybe making slightly smaller Guile processes is just a matter of tweaking the boot. <taylanub>but anyway, 1 MB or 3 MB just seems irrelevant to me :) <ArneBab_>a friend of mine works with microprocessors, so I’m tangentially interested in this :) <solrize>ArneBab_, yeah, i've been interested in microprocessor lisps for a while and this sort of overlaps <solrize>taylanub, 1MB and 3MB aren't that different but 100k is different <solrize>and if the 2.6MB is scheme modules i wonder if they could be loaded into the shareable part somehow <solrize>and also have to wonder why there are so many <taylanub>modules are all mutable in Guile so they're probably fine in the heap. there are so many because Guile has so many great features! <solrize>why are they mutable? what kind of FPL is that? :) <taylanub>solrize: really, if you want Lua or Chibi they're there waiting for you <solrize>i think i want something like purescript with the hedgehog vm <solrize>not just for the microcontroller angle <solrize>really, for better or worse, javascript has taken over as the universe-conquering scripting language. there are even c compilers that target it <ft>IIRC technomancy used microscheme for his keyboard firmware. (apologies, if this was mentioned before; I'm too lazy to read to whole backlog *g*) <ArneBab_>is it possible that the heap is simply preallocated to speed up operation? <solrize>ft that's interesting if someone used microscheme for something real <ft>He built a completely custom keyboard with his own firmware, for which he used microscheme. <ft>I think he sells them. Or kits at least. :) <solrize>even if modules are mutable i'd think the code fragment for any given function should be immutable, and a module would basically be a dictionary mapping some function names to code. and heck, that could be immutable too, and located in a mutable box so you could replace it if you wanted to monkey patch something. then each module would have just one mutable cell unless you decided to patch it <solrize>plus maybe some closure cells made by init code in the module <solrize>ArneBab_, thanks, that looks interesting <solrize>it looks like a good idea based on that article <solrize>ic, so if the current version doesn't do that, it might explain the bigger heap size <solrize>Finally, all of this has a positive impact on start-up time. While I can get Guile 2.0 to start up in 11 milliseconds, with Guile 2.2 I am down to 8 milliseconds. Likewise guile -c '(sleep 100)' in Guile 2.0 uses 3144 kB of private dirty memory, compared to 1852 kB with Guile 2.2. There's still improvements to be made, but things are going well. <solrize>i wonder what the startup time is for helloworld.c? i mean that's the practical lower bound and it wouldn't surprise me if it's still in the milliseconds <solrize>and is that still 8 msec if libguile.so is already being used by some other process so the shareable part is in ram? <dsmith-work>solrize: Heh. Really tweaking C might depend on if you use printf or write. And if you statically link or not. <solrize>there's a viewpoint that shareable executables have been a net loss and it would be better to statically link everything <dsmith-work>ISTR a C hello world that was only a few hundred bytes. <solrize>i am enough of a luddite that i still write a fair number of web cgi's (mostly in python for very low traffic pages). with sub-msec load times that could be viable for pages that actually get some traffic <ArneBab_>it goes down to 8ms without the site file <ArneBab_>but then it misses most of the libraries. <solrize>but if modules are immutable then the library can just be mmap'd...