<anon9002>Hi. I've been playing with Guile's EcmaScript implementation, and I'm wondering if there's a way to reference scheme procedures that contains hyphens in their names (eg. array-ref) ? <paroneayea>wingo: it built with latest guix + guile-next :) <lloda`>guile doesn't seem to support (define-syntax (f stx) ...) ***dsmith is now known as dsmith-work
***dsmith-work is now known as dsmith
***dsmith is now known as dsmith-work
<lloda`>sometimes I'd like for errors to NOT truncate the output, b/c I don't know how to get it otherwise. Like in macro errors. <paroneayea>so wingo! you said that you think adding support for suspendable ports with custom binary i/o ports will be possible? <paroneayea>eg whether or not that would mean that probably a postgres library could take advantage of that and ettc <paroneayea>my guess is that it would have to provide something along the lines of a file descriptor to the scheduler for it to work <amz3>did anyone succeed at running both fibers/examples/ping-server.scm and fibers/examples/ping-client.scm? <amz3>Somehow localhost was not present in /etc/hosts <amz3>janneke: basically, with a 17kb binary and a bunch of source code, you can bootstrap a C compiler that will be able to compile TCC? <janneke>amz3: that's my next (or even next-next) target; compiling TCC <amz3>janneke: then I understand that it could be useful for guile <amz3>janneke: maybe you know how hash compiles hotspots to native code, does it use a known compiler like gcc or something? <janneke>amz3: the Scheme interpreter can do it, i'm working on the C compiler right now <amz3>janneke: it seems to me nash would require the same work you do <janneke>amz3: yes...but nash can depend on any library it likes <janneke>which is a good thing, Mes does not want to depend on anything <amz3>why is gnu lightning good? <janneke>amz3: i haven't looked at it, really <janneke>so many interesting things to look at... <amz3>maybe guile nash can only compile some kind of code, they may be translation barriers basically <amz3>also it doesn't do AOT compilation <amz3>so maybe there is many optimization it miss <amz3>that is a debate between JIT and AOT basically <janneke>what i remember from the talk on nash is that most time is spent in loops <janneke>or possibly, that was the hypothesis--not sure <janneke>if i had to do it, i'd start by targetting the simplest type of loop and see how much that helps <amz3>janneke: but you aim for AOT, is that correct? <janneke>amz3: no, not really -- i mean, i voiced some future pipe dreams yesterday <amz3>IMO your are reserved/humble about your goals with mes, which doesn't help to understand <paroneayea>and I was 1 degree off from my laptop auto-shutting-down <paroneayea>I need to install some cpu throttling stuff on here <amz3>why does fiber not use srfi-41? <amz3>it has it own test procedures <amz3>I understand something, the assert-equal macros are defined in every tests/ <amz3>I understand something, the assert-equal macros are defined in every tests/*.scm <amz3>there is bug in srfi-41, we don't use it in guile-git <amz3>strange i can't find the bug about the unit test framework found in guile <wingo>paroneayea: regarding the fibers tests, how about adding a phase before configure that does (setenv "XDG_CACHE_HOME" "/tmp/guile-cache") <wingo>that should fix it, making guile-fibers build in a reasonable time <wingo>and since /tmp is just a local copy it should work afaiu, dunno <wingo>see recent guix-devel discussion :) <codemac>Are there any atomic primitives in guile? searching the manual for "atomic" didn't lead me where I expected. <codemac>wingo: SUPER EXCITED ABOUT FIBERS! Congratulations on 1.0 <wingo>codemac: there are "atomic boxes" in 2.1.7 <codemac>ok cool. I'll make a thingie with a mutex, it'll be super low contention anyways with a TODO for 2.2 release :) <paroneayea>codemac: yay! I'm excited that you're excited. And I'm excited too. <wingo>it triggers another bug, which is exciting <TMM>I was wondering if maybe someone could point me at resources about vm design. <paroneayea>TMM: the manual has a really nice section on it, though I recommend reading the Guile 2.2 manual if you haven't <TMM>I'm working on a replacement vm for the godot game engine, my initial attempt has been reasonable at about 15-20x slower than C for a fib(42), which is more than twice as fast as the stack-based interpreter currently in use <paroneayea>TMM: I've been thinking how great it would be for Guile to be in Godot <TMM>I'm not sure if *that* is going to happen by default due to the licensing :-/ <TMM>godot is very married to it's mit license <paroneayea>TMM: I would be surprised if Godot doesn't rely on some LGPL third party libs anyway :) <TMM>yeah, they won't allow any non-mit licensed dependencies <TMM>it really doesn't everything is NIH, mit, or apache2 <TMM>'not invented here' ;) <TMM>as in rebuild for godot :P <paroneayea>TMM: so, have you read the Guile manual on this stuff? things have changed from Guile 2.0 to Guile 2.2 <TMM>I haven't, I'm not working on integrating guile but I've noticed that guile's vm is very fast <TMM>I'd like to learn more about how it's done on a theoretical level <paroneayea>TMM: are you using Guile stable or unstable (2.1 / 2.2)? <TMM>I have looked at guile 2.1 for benchmarking to see how fast I could theoretically be without a jit <paroneayea>TMM: cool. Also btw someone started a jit branch of Guile <paroneayea>it's not in mainline, but jit is a possible (and likely) future feature of Guile <TMM>that's cool, it may be worth integrating guile as an optional runtime <TMM>for users who don't want to deploy on non-free platforms <amz3>TMM: you do something like that in guile? <TMM>amz3, godot is totally awesome <jmd>What is godot? Does it have a lot of wait states? <TMM>amz3, no, sorry, I'm not using guile... I'm here because guile has a kick-ass vm and I'd like to know how it works <TMM>davexunit_, the project leaders don't want non-optional LGPL dependencies because godot is portable to platforms where even the lgpl requirements can't be met :-/ <TMM>wingo, I had not... I found the title but thought it wasn't what I was looking for... I'm a bad googler apparently <paroneayea>ACTION thinks, we should get Godot packaged in Guix <amz3>master documentation don't how up in google nor ddg <wingo>TMM: on np :) feel free to ask questions as you have them <paroneayea>well, when I asked Godot about whether Guile integration could happen <paroneayea>they said it was possible if someone wanted to work on it <TMM>davexunit_, godot is itself entirely free. <paroneayea>I don't think they're dropping their own language tho <davexunit_>I don't see why guile support would have to be mandatory though <davexunit_>TMM: yes I know, but prioritizing non-free platforms is bad. <TMM>davexunit_, as an option it would be perfectly acceptable. The point is that it can't be used to replace GDScript because that would make it mandatory on all platforms <paroneayea>yeah maybe if guile could be a compile-time option? <davexunit_>they are limiting Godot based upon the licensing restrictions of oppressive operating systems. <paroneayea>TMM: oh well if Guile could be a compile-time option <TMM>my work does replace the current gdscript parts, and has to be mandatory <TMM>and at this time that means it has to be mit-style licensed <amz3>you can't plug a new scriptign engine? <TMM>godot is fairly modular <amz3>I don't see a problem, the only issue is the maintainer of godot refusing lgpl as dependency <amz3>one can link mit with lgpl afaik <TMM>just to be clear, I'm literally a card-carrying fsf member. The only reason I put up with this is because right now is that unity is the first exposure to programming that many people have, and it is non-free <TMM>I'd like there to be a free system in that same niche <TMM>and while godot's licensing policies aren't the best, it is currently the only game in town. <TMM>It is entirely free software <amz3>TMM: can you maintain the plugin in your own repo and not merge it with the godot master? <TMM>I can, but my goal is to make godot faster. This means I need to make gdscript faster. <TMM>If I do this with guile's vm most people won't be exposed to it <amz3>except if you implement gdscript on top of guile <amz3>I mean you can add a gdscript frontend to guile <amz3>I mean you can add a gdscript frontend to guile wm <TMM>the downloads on godotengine.org would still not have guile :) <amz3>probably i need to hack on something <amz3>TMM: good luck with your research <TMM>ghehe, it is amusing that I came to the exact same conclusions and for the exact same reason as on that website about guile <TMM>paroneayea, pretty much, yeah <amz3>web stuff is full of MIT software too, people fear gnu for some reason <amz3>TMM: how do you know guile wm is awesome? <TMM>amz3, I benchmarked it :) <TMM>amz3, I know some common-lisp so picking up enough scheme to implement my micro-benchmarks wasn't hard <TMM>reading that document on the gnu website it appears that my worries about instruction size was stupid <paroneayea>TMM: well, I'm glad you're finding Guile interesting... and I encourage you that if you're interested, to explore that whole adding guile as a compile-time option thing ;) <paroneayea>I know *I* would be excited about a Guile option in Godot :) <TMM>the primary difference between my implementation and guile's on a design level appears to be that guile's vm really is not afraid to have super-specific opcodes <TMM>wingo, ^^ does that sound somewhat accurate? <wingo>TMM: not knowing your system i can't compare but it's true, we aren't currently afraid to add an opcode <TMM>wingo, my opcodes are all 32bits or less <wingo>for me i distinguish "opcode" and "instruction" <TMM>wingo, most of my opcodes have copious amounts of space for immediate values too <wingo>opcode being the instruction kind, and instruction being the opcode + whatever arguments it needs <TMM>my opcodes and instructions are almost 1:1 <paroneayea>wingo: btw, could I clarify if one bit of understanding in GOOPS is correct? Are generic methods O(n) dispatch per number of method implementations sharing the same arity? <TMM>all my opcodes only have a 3 bit modifier about the arguments <wingo>having minumum 32-bit instructions works well when you encode operand arguments by index -- then you can have 8 bits for the opcode itself and divide up the rest as needed <TMM>yeah, that makes sense <wingo>paroneayea: right now or in theory? :) right now they are O(n) yes. other strategies are possible <paroneayea>wingo: that was my reading while going through the code, and I've been wondering if right, and if we could improve it <paroneayea>ok, yeah :) it looks like other implementations use tables to do dispatch, and I wondered whether or not the cache could use hashq's on the types <wingo>guile 1.8 had a hashing strategy for example <TMM>wingo, do you do any type of instruction decoding? I currently waste a bunch of time shifting bits around to get to the correct switch branch. <wingo>just was never implemented iirc <paroneayea>wingo: but I wonder if (hashq -> (hashq -> (hashq -> #t))) might work <paroneayea>wingo: I've thought maybe that would be something I could take a crack at implementing <wingo>never implemented in 2.x i mean <amz3>paroneayea: did you think about p2p while building 8sync and mudsync? <wingo>paroneayea: it could be. it could be there are other alternatives; dunno. assuming everything is inlined, it could be that a better chain-of-ifs compilation could be sufficient (like compiling a "switch" in c; will clinger wrote a good paper on this) <wingo>TMM: see definition for NEXT() in libguile/vm-engine.c <TMM>wingo, do you have any documentation on the generalized state of the art of vm design? I was told by someone that you're basically the person to talk to about this kind of thing :) <wingo>hehe i don't even know if that's true :) things are in flux and the real wins are in native compilation <wingo>so what point do bytecode interpreters occupy? i don't know. <wingo>they can be OK though evidently :) <TMM>wingo, yeah, I've come to the same conclusion as you basically. I'm creating a bytecode vm and then a compiler for gdscript to that vm. <paroneayea>amz3: I've thought a lot about cyberpunk dreams of crypto-MUDs as entrypoints into a secure social network :) <paroneayea>amz3: I even wrote up a short story exploring the idea, but I'm a bit too embarassed to post it ;) <amz3>paroneayea: is there a notion of inbox and outbox in 8sync? <paroneayea>amz3: sorta, really just inbox, "outbox" is kind of abstracted through the <- message passing procedures <wingo>but people make interpreters in assembly not so much for speed but to be able to control stack layout so they can tier up/down to/from higher JIT tiers <amz3>paroneayea: you shouldn't be ambarrassed maybe cross chekc with friends <janneke>amz3: i'm being humble about any targets > 1year from now. mes is quite young, my first target is simply removing the bootstrap binaries and that's still a lot of work :-) <wingo>gcc doesn't do a bad job on guile's vm iirc <amz3>paroneayea: in the p2p db i have in mind, each "node" has an inbox and outbox like in the federation api <amz3>I am wondering where I got that idea, I think it's the federation api <TMM>wingo, that gmane link is great <wingo>too bad mike pall is shoveling bits into the boilers at cloudflare ;) <paroneayea>amz3: not sure if you watched the 8sync talk either from FOSDEM or at the Chicago LUG talk <paroneayea>but at the end I talk about the overlap between the actor model and federation <paroneayea>amz3: if you haven't watched it, it's a pretty fun / silly talk <amz3>paroneayea: I watched the fosdem talk <TMM>wingo, at least I'm using my powers to write free software, even if it's not copyleft :) <amz3>the federation part of the talk start at 30:00 <paroneayea>TMM: while I think it's too bad that Godot takes an anti-LGPL stance, I also think it's super important stuff <TMM>wingo, if I understand this all correctly I may be able to horribly abuse gcc's global register value feature to alleviate some of the problems in the optimizer <wingo>TMM: sounds cool. happy hacking :) <TMM>wingo, switch ((short) op) {} actually produces surprisingly nice code <wingo>goto *jump_table[op & 0xff] is better tho <TMM> 400505: 8b 45 fc mov -0x4(%rbp),%eax <TMM>is the jump table better? <wingo>there's more than that to jump <wingo>see literature for "indirect threading", there are some papers on it <wingo>in guile the HAVE_LABELS_AS_VALUES configuration is a winner <TMM>right because you have the cmp as well <TMM>wingo, but function calls are really expensive compared to just a jump right? <wingo>where is the function call? :) <TMM>oh... I had no idea you could do &&label in C <wingo>it is a gnu extension but widely implemented <TMM>wingo, I see, this makes the whole ordeal just 3 insn <TMM>wingo, do you happen to know how portable this is? <wingo>gcc + clang afaiu. in guile we fall back to a switch statement. not hard to support both <TMM>wingo, interesting, erlang 'solves' this by building the main interpreter switch with gcc on all platforms, and the rest on whatever native compiler there is <TMM>wingo, but yeah, it appears every current compiler except msvc actually supports this <amz3>done my first program in fibers <amz3>basically a peer-loop which represent an actor or something, and init the conversation with the multiplexer (which another loop inside untangle) <paroneayea>I need to write something in fibers to get my head wrapped around it <amz3>when a actor says it's ready (via a ping) the multiplexer asks the actor to talk to the peer 1 <paroneayea>maybe I should write some sort of "monitoring" application <wingo>could be. i'm pretty sure 8sync itself could be implemented well on top of fibers <amz3>I need to create a socket in my code so that I can ask the multiplexer to execute commands sent from the outside of the program <paroneayea>so it should be possible to implement one on top of the other <amz3>wingo: can I add a REPL inside my program, and do something like (get-message repl-channel) <amz3>and connect to that repl from cli <wingo>amz3: would be nice, but you would have to use a repl thread or something <wingo>because the repl uses read/display/write it doesn't nicely integrate with fibers right now <amz3>I know what will do then <paroneayea>wingo: if you end up working on making integration closer re: repl, I'd be interested in seeing what you do <paroneayea>wingo: I've thought it would be nice to be able to send messages directly from the repl while live hacking in 8sync <paroneayea>but because the repl isn't running "in" the hive execution environment <paroneayea>it isn't really possible, except through some hackery where you pass off a message you'd like to send to something listening to proxy it, and get some box at the repl where you can get the value that might eventually be returned to it <wingo>i think a closer integration would have a scheme read/write/display written in the suspendable subset of guile, then it could push that datum to some worker fiber to evaluate <wingo>basically a repl reimplementation i think <wingo>maybe there is a way to customize repl-reader or so <paroneayea>wingo: makes sense. the repl code looked not quite written in a way where using the existing code would be easy <paroneayea>I tried to do so then realized I would be rewriting most of it anyway <wingo>yeah. we should not be afraid of rewriting things :) <paroneayea>I still think I feel internally like I'm not "good enough" to contribute to Guile core properly! <paroneayea>not saying that anyone else is saying that, just internal insecurities <amz3>I am not the good person to do so. To avoid the issue with write and read, I havea scm->string procedure that push scm values through a string port so I assume this blocks somewhere but anyway I am not looking at performent code right now <amz3>when my project will be useable I hope things will be better wrt write/read <wingo>heh it is probably not true and anyway whether or not it is true, the only way to get better is to hack code :) <wingo>i always loved the goethe quote that's in the beginning of some 'joy of cooking' editions <wingo>something like "that which thy forebears possessed, earn it anew if it would be yours" <wingo>just because someone hacked a thing in the past doesn't mean you can't do it now (and indeed the reverse: if you want to do that kind of work, you have to hack it again!) <amz3>wingo: is there a procedure that looks like `select' and does "wake me up whenever one the following channel is ready or port" <wingo>amz3: currently there is no support to make a CML operation out of a port. probably we should have this. <wingo>but for channels you use choose-operation <wingo>(perform-operation (choose-operation a b c d ...)) <wingo>a b c d ... can have wrap procedures too <wingo>you need to read up on cml, for better or for worse :P <amz3>that's what I've been thinking <wingo>dunno, maybe not the best place. <wingo>this part of the manual needs more elaboration :) <amz3>what happens if I create a global with channel, and then put-message stuff in it using my own thread? <amz3>what happens if I create a global with make-channel, and then put-message stuff in it using my own thread? <wingo>guile-guest3: not currently. why do you ask? :) <paroneayea>guile-guest3: no, but there was a guile-user or guile-devel thread about it recently and incorporating some code that had been written <wingo>you can put-message etc from threads that aren't in fibers. <wingo>fixed the goops thing i think <TMM>aaaaand I broke my vm <TMM>... yeah, incrementing my instruction pointer after a jump... <wingo>maybe fibers should allow for ports or other data types to be implicitly "synchronizable" <TMM>my move to computer goto was not without casualties <amz3>wingo: I don't understand what it would mean, so i can not give you my pov <wingo>racket's sync is fiber's perform-operation <amz3>I didn't understand the part about perform-operation yet <amz3>I will have a look at both this seems very funny <TMM>wingo, your suggestions improved my vcpu implementation by a lot <TMM>wingo, it's now 1.7x faster