***karswell` is now known as karswell
***dcs is now known as pobrema
<zv>hey guys, I'm thinking about trying something a little interesting for SICP chapter five: Implementing the actual register machine inside C using SCM* objects - Does anyone whose read the whole book think this approach would be workable for all the exercises? <sapientech>is there any way to purposely capture variables with define-syntax+syntax-case? <zv>sapientech: yes, it's described in the documentation on macros <zv>you can use datum->syntax + with-stynax <zv>alternatively you can just expose another syntax-case that binds variables in the lexical environment, that still uses `datum->syntax' however <ecraven>ArneBab: good question, I thought I had run 2.2 a few days ago.. I'll investigate in a few hours, when I have some time ***whiteline_ is now known as whiteline
<sneek>civodul, you have 2 messages. <sneek>civodul, amz3 says: yes the bindings make good progress <sneek>civodul, amz3 says: can you explain me in layman terms how you need to do with libgit2? <civodul>artyom-poptsov1: what about renaming 'get-key-type' (and likewise for all the 'get-' procedures) to 'public-key-type', and depreating the old name? <civodul>amz3: i need to be able to do 'git clone', 'git pull', and to traverse the commit log as i showed with the original code snippet <wingo>ACTION just watched civodul's cufp talk <paroneayea>"why isn't the old gnutls-enabled https support patch I was hacking on working any more?" <paroneayea>"ohhhhh, the gnutls library it's accessing is for guile 2.0... well no problem, I'll just hack on the patch on stable-2.0" <paroneayea>"oh right the new feature is custom binary i/o ports on master!" <wingo>i think civodul made the patches for guile 2.2 support <paroneayea>I imagine those people experimenting with using guix with gnuile-next *must* have been using a gnutls compiled with guile-2.2 <avoine>paroneayea: I just saw your comment on “Thoughts on DX: GNOME and Rust” blog post about the GTK API for Guile, have you found how that Rust/C/Guile API would work? <avoine>ACTION don't know what to think about rust vs c <paroneayea>avoine: I don't know exactly but apparently rust allows you to expose / preserve a C API / ABI <paroneayea>so even if GTK was rewritten part or all in Rust, it sounds like our bindings would be fine <paroneayea>I have mixed feelings on really critical infrastructure moving to Rust. Rust seems cool, and moving away from C is good <paroneayea>and hopefully its community is stronger than just mozilla these days <paroneayea>as much as I like mozilla in *most* contexts, they haven't done a good job of preserving big initiatives that aren't firefox itself <paroneayea>but, maybe rust is stabilizing, and has enough external momentum, where nobody needs to worry. <avoine>I guess that's what they try to convince us by have the big "See who's using Rust." link right after the headline in there front page <paroneayea>rust doesn't seem like a stable language quite yet <paroneayea>but, I do think a move towards things that are "safer" than C is good <paroneayea>the types stuff is ok too but I worry about that a lot less <davexunit>rust is in the same package management pickle that all new languages seem to find themselves in <davexunit>and then there's the static linking philosophy <davexunit>so far I can see it bringing nothing but discomfort for distribution maintainers <paroneayea>davexunit: ah right, does it have any dynamic linking answer? <paroneayea>I mean you'd think it would if it boasts exposing C ABI/API compatibility <davexunit>not totally sure, I get rust and go things mixed up a lot... <paroneayea>well, at least it's nice that people are working on cool language things again <davexunit>like preferring static linking to the point of dynamic linking being an after thought, if supported at all. <paroneayea>it's better than a decade ago when the answer was "Java and .NET are the only language worlds!" <davexunit>but if someone gave me a piece of software written in rust I wouldn't know how to build it <paroneayea>I still wish we had an autotools like answer that was mostly written in guile <paroneayea>civodul mentioned the idea of a guile output target of shell <davexunit>then everyone in the thread proceeded to misunderstand him <paroneayea>dsmith-work: to be clear, mentioned the idea doesn't mean work has been done :) <paroneayea>so, it would be nice to have a build solution that would be easily adapted to different languages <davexunit>people kept bringing up how it would be bad to need guile in order to build... but the whole idea was that you wouldn't need it! <davexunit>the release tarballs that you'd distribute would have configure and co. already generated <davexunit>so the user would only need make and bash, just like today. <avoine>would be cool if it could helps building only parts of the code that changes instead of the whole project <dsmith-work>Why is there such a proliferation of make-like tools? Seems like every new language ends up inventing a build tool. <paroneayea>dsmith-work: well, all the other language tools have one, so why not another :) <paroneayea>but you could also say it might be that sans guix/nix, most distros don't make working with "development" environments easy <davexunit>I get annoyed when people tell me that Rake, the ruby make-like tool, is better than make <davexunit>it has *no* idea about parallel building or dependencies <paroneayea>and encourage each language to set up their own "ecosystem" <paroneayea>davexunit: yeah just look at the mess the js world is in <davexunit>they don't do anything that make does that makes it useful <paroneayea>I've tried doing just-make without autoconf, eventually you need something like autoconf <paroneayea>and then autoconf doesn't give you all the gnu style tooling, so eventually you use autotools <paroneayea>and eventually, you don't have "just make", you have a huge pile of tooling that's hard to reason about <davexunit>people do that because "the autotools are bloated" <paroneayea>davexunit: well and I think it's a fair criticism <davexunit>that is simple because it doesn't support user defined prefixes <davexunit>or all of the other things that that autotools give you for free <dsmith-work>bare make with pkgconfig can have some very clean makefiles <paroneayea>I also don't understand where I would start to extend autotools <paroneayea>I think, to me, it does feel like none of the build systems are really great <davexunit>not once have I encountered software with a hand-written makefile that didn't need to be hacked to work. <davexunit>sometimes it's as simple as forgetting an equivalent of --prefix <paroneayea>I think "a guile based build system DSL with an output target of shell" <davexunit>I think we need a make that makes doing the right thing simple <dsmith-work>You know, this discussion happened right here about 15 years ago. <paroneayea>an scsh type syntax + shell *output* would be a dream <paroneayea>random-nick: well I wrote my issues with it above <davexunit>random-nick: it's a nasty pile of m4, bash, etc. <dsmith-work>Conjure is a make(1) replacement written in Scheme. Makefiles are substituted by Scheme scripts, which brings the power and expressivity of a high-level language to the stage. At the same time, a DSL tailored to describe software construction tasks allows non-programmers to write build scripts in a declarative way, while Scheme-savvy users can extend the system through modular, shareable libraries. <paroneayea>tl;dr hard to understand and extend, especially for non-C systems <davexunit>autotools got the most important thing right, though, and that's the interface for users <davexunit>I've never seen anything work better than ./configure && make <davexunit>so that should be preserved, but the implementation should be replaced <paroneayea>davexunit: and combined with something like guix, you *do* have a nice system for hacking <dsmith-work>davexunit: The people who run ./configure, sure. I alway have hard time with .am files. <davexunit>dsmith-work: you mean writing a makefile.am? yeah it's not great <davexunit>that is what we're saying needs improvement. <davexunit>the user experience is good, so we should kep that. <paroneayea>the way I write my variable names shouldn't affect how it generates code IMO <davexunit>it's also good that autotools aren't tied to a package manager <davexunit>a lot of new languages conflate the build system and package manager <paroneayea>davexunit: I used to think that was fine, but after 5 years of struggling with people updating mediagoblin <davexunit>those two fundamental things autotools got so, so right. just a shame it got the implementation languages and API so, so wrong. <davexunit>common lisp seems to have the same problem I mentioned above <davexunit>if asdf downloads dependencies on its own, then it's bad. <paroneayea>it would be nice if we could convince the CL world to use a lispy package manager, say Guix ;) <paroneayea>too bad when I talk to some CL people about Guix they say "YUCK a lisp-1!" <random-nick>davexunit: asdf only does dependency checking, quicklisp downloads <davexunit>ACTION really doesn't like common lisp, but cares more about unity <davexunit>the enemy are those other non-parenthetical languages! <random-nick>I like the common lisp "spirit" but not the actual language <avoine>but if you look at package management and autotools from an operating system point of view aren't they the same thing but at diffenrent level of abstraction? Like function and module for example? <random-nick>common lisp has a big community and scheme has a nice language <avoine>if that's right that would make sense to do it with the same tools <paroneayea>avoine: right, there's an abstraction barrier traversal though <random-nick>(unfortunately for common lisp they have the language is big too) <paroneayea>avoine: even slackware, which is as close to "just autotools and tarballs" as you can get iirc <paroneayea>you need some distribution layer that's not the same as the packaging layer <davexunit>the build system is package manager agnostic <dsmith-work>There was this web server running cl. It had been running for years, and the code had been modified quite a bit. But it was the SAME PROCESS that had been running all that time. Amazing. <random-nick>asdf is basically a build system which does dependency checks, and quicklisp takes care of the missing dependencies <paroneayea>dsmith-work: wonder how many security vulnerabilities that server had on the kernel level and etc... ;) <random-nick>I don't get why some people get so emotional about lisp-1 vs lisp-2 <paroneayea>wingo: get-bytevector-n! / put-bytevector <- would that be the best procedures to use in the custom-binary-input/output-port wrapping the gnutls connection to do read! / write! with? <davexunit>very philosophical. should a function be treated as different from any other object? <wingo>paroneayea: those are good ones i think, yes :) <wingo>oddly get-bytevector-n is on the suspendable ports path and get-bytevector-n! isn't? not sure <wingo>anyway if you don't need the imperative thing, use get-bytevector-n <paroneayea>wingo: imperative thing not needed, just thought it might result in one less copying operation <paroneayea>random-nick: keep in mind that also when common lisp was being developed <daviid>ACTION is [also] working on guile-vigra (as if he did not have too many things to do already :)), slowly ... yesterday night, got the 1st rgb image loaded in guile's srfi-4 f32 vectors (1 vector per channel) <paroneayea>macro hygeine as it exists in scheme today *didn't exist* yet <wingo>"it is not an error to unlock an unlocked mutex" <wingo>wtfffffffffffffffffffffffffffffffff <daviid>its spins in his socks rather :) <janneke>ACTION finally got pre-r6rs [p]syntax case going in mes! <janneke>also looked into reproducible-go files, see -devel <janneke>ACTION has more questions than answers on that subject, of course <wingo>civodul: i have a proposal. it is to _slightly_ degrade our srfi-18 support. the reason being, it is too complicated -- we should be providing simple primitives and when we added srfi-18 support, things became verrrry not simple. with a small change we could improve things. <wingo>specifically srfi-18 has this concept of mutex owners. you can lock a mutex on behalf of another thread, or on behalf of no thread (the default i think). <wingo>you can unlock a mutex from any thread. interestingly this is not the case for pthreads, <wingo>as we implement our own mutexen. <wingo>the only serious implication of mutex ownership is that if a thread exits and it owns mutexes, then those mutexes become abandoned. <wingo>this is a very complicated requirement that i wish we didn't have, but ok. <wingo>trying to lock an abandoned mutex fails once, throwing an exception, then transfers ownership to the locking thread <wingo>and the thread can then unlock the mutex and proceed. weird stuff <wingo>i want to make it so that threads can only lock mutexes on their own behalf <wingo>effectively requiring the third argument to srfi-18 mutex-lock! to be either #f or the current thread <wingo>actually i think in practice all mutexes are owned in guile, if i don't read the code wrong <wingo>so this would not be a change for any user -- except those users that strictly want to build on srfi-18 and use this ownership thing <wingo>i think that srfi-18 is actually not what we should be recommending to our users -- it is a thick wrong set of primitives -- <wingo>and so if there is a tension between full srfi-18 and a significant maintenance/documentation improvement, we should consider degrading our srfi-18 support <wingo>gaah all these mutex introspection procedures make me sad <wingo>asking about the state of something that is defined to be changing because other threads are doing things... yarrrrr <wingo>haha maybe my problems will be solved if i add a section called "Bad Ideas" to api-scheduling.texi ^^ <wingo>& move all the bad procedures there <wingo>i think i will do that :) easier than making changes in this area <civodul>wingo: wouldn't it be possible to remove the "ownership" concept from libguile's mutex, and yet have them implement in srfi-18.scm using a disjoint mutex type and thread cleanup handlers? (in theory at least <wingo>civodul: yes i think that could work. it would keep srfi-18 fidelity high but would make srfi-18 mutexen disjoin from guile's mutexen <wingo>so that is another possible solution <civodul>i suspect srfi-18 is not that popular anyway, and that this specific semantic point is not necessarily relied on <civodul>at the Scheme Workshop someone presented an implementation of multithreading primitives on top of srfi-18 <civodul>that would be a good thing to look at