***dje is now known as dje42
<civodul>davexunit: just tried Lisparagua, it's awesome! :-) <civodul>paroneayea: mudsync lacks a guix.scm file, bah! :-) <mthl>civodul: Guix have one, but it doesn't do what it is supposed to do! :) <civodul>but that convention didn't exist back then! <mthl>civodul: Sure. To be honest I don't get the point of these files since you have to manually set the current commit + fix the hash each time you want to make a test. <mthl>Maybe it would be possible to provide a generate a “origin” record which use the current repository commit and doen't check the hash. <mthl>anyway should be on #guix <civodul>mthl: the way to use it is: "guix environment -l guix.scm" <civodul>but it doesn't matter for 'guix environment' ***karswell` is now known as karswell
<paroneayea>and maybe release 8sync and mudsync packages for guix :) <wingo>yeah, all the things for guix! <wingo>i have like thirty things i should publish <wingo>ok so apparently we can follow posix and it ilk very closely as regards nonblocking i/o <wingo>because mingw has a poll module and now you can run native guile binaries under windows <wingo>so we don't even have to think about i/o completion ports and the like. cool beans <wingo>last time i tried to update gnulib it didn't work <cluck>wingo: i thought win's new linux subsystem only allowed console stuff (ie, anything using a gui in guile would be out) <wingo>cluck: yeah i suspect that's the case <wingo>but i wonder, is it that bad; dunno <wingo>what would the model be, ship gtk on windows or something> <wingo>i wonder how good the glib poll is. <cluck>this being microsoft i can't shake the feeling of a honeypot for EEE for some reason (maybe past experience?! :P) <wingo>to me i see it as commoditizing their OS <wingo>a losing proposition to them in the end <wingo>because what does window offer but compatibility with legacy gui apps? <wingo>and now they are compatible with console things like databases and such <cluck>the buggers have a monopoly in pretty much any hardware :| <wingo>you miss windows drivers? i haven't used them in decades so i perhaps have stockholm syndrome ;) <cluck>i wouldn't say miss (quite honestly the quality of drivers and firmware is generally piss poor) <cluck>but certainly the availability is nice to have (bad code beats no code) <cluck>ACTION angrily waves cane at 32bit uefi <cluck>xkapastel: i thought it was datafarming and doxing users with their latest spyware^H^H^H^H^H^H^Hoperating system <xkapastel>no way datafarming makes as much money as saas, that's a side business :P <wingo>i assume they play a super-long game tho, they have billions in the bank <wingo>and a solid revenue stream via windows & office... dunno tho <wingo>i am just happy i don't have to learn about windows sockets :) <spk121>i did once write a gtk terminal widget that ran guile. in the glib event loop it called the guile vm single stepper. <wingo>i wrote something like that too at one point <wingo>it was kindof a pile of hacks ;) <wingo>i think it involved continuations.... <wingo>any time you reinstate a C activation from foreign code we should require a signature from that frame allowing it to be rewound :P <wingo>right! while i seem to be opining <spk121>wingo: too deep for me. the vm single step in the event loop worked alright, and simple code ran fine, but I never got the full repl or debugging to work, as I recall <wingo>do people here use call/cc from Guile to do things to their C programs? <wingo>i wonder if the ability to reinstate the C stack is important, or not <wingo>i suspect not :) but i don't know <spk121>i haven't, no. GOTO considered harmful. might be useful is some debugging or exception context? I should stop showing my ignorance, now. <wingo>one: non-local exits which might span foreign C code <wingo>for the first we have to support this forever in guile <wingo>if there's an error you want to be able to scm_error and it throws an exception. <wingo>that might mean that cleanup code in intervening C frames doesn't run <wingo>though it could run via the scm_dynwind api <wingo>or, we could integrate with some platforms to run RAII-style destructors <wingo>but, i am ok with the first thing. <wingo>the second, it can make sense; <wingo>but you are introducing concurrency into a C code base that might not be expecting it <wingo>which can cause logic and also safety errors <wingo>the third, i think it's useless. it has some limited uses in Scheme, but making C frames handle multiple "returns" through them is a bug farm <wingo>i am allergic to bug farms :P <wingo>if we could restrict the applicability of continuations to (1) then guile's continuations could be cheaper <wingo>both in space and time and in implementation. <spk121>there is some better concurrency support in C11, but, know that is probably not helpful <wingo>yeah but it's not oriented towards non-local unwinds, not to mention rewinds <trough>How can I load an SXML file's tree into something like sxml->xml ?