IRC channel logs


back to list of logs

***karswell` is now known as karswell
***dcs is now known as pobrema
<paroneayea>well, that's one mystery solved :)
<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
<ArneBab>ecraven: what happened with guile 2.1 in your benchmarks?
<ArneBab>I only see 2.0.12 there
<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
<ArneBab>ecraven: thank you!
<ecraven>thanks for telling me
<OrangeShark>hello everyone
<davexunit>yo OrangeShark
***whiteline_ is now known as whiteline
<dsmith-work>Wednesday Greetings, Guilers
<civodul>artyom-poptsov1: hello!
<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
<OrangeShark>hey amz3` how are you?
<sapientech>zv: thanks for the response, got it working!
<wingo>greets :)
<wingo>ACTION just watched civodul's cufp talk
<wingo>v nice :)
<paroneayea>oh nooooooooo
<paroneayea>ACTION realizes a catch-22
<paroneayea>actually it's resolvable (probably.)
<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!"
<paroneayea>but I guess the answer is simply
<paroneayea>build a new gnutls with guile-next support?
<paroneayea>assuming that'll work.. :)
<wingo>i think civodul made the patches for guile 2.2 support
<paroneayea>wingo: ah nice
<wingo>in gnutls
<paroneayea>I imagine those people experimenting with using guix with gnuile-next *must* have been using a gnutls compiled with guile-2.2
<paroneayea>otherwise how would all those https links work
<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>that's what I hear anyway
<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.
<paroneayea>I don't know
<davexunit>it worries me, too.
<davexunit>the ubiquity of C is hard to beat
<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>it's changed a *lot*
<paroneayea>but, I'm not a user
<paroneayea>but, I do think a move towards things that are "safer" than C is good
<paroneayea>I'm not sure if Rust is it
<paroneayea>maybe it will be, I dunno
<paroneayea>by safer I mean memory safe
<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>or is it static linking only
<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...
<davexunit>they overlap in a lot of ways
<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>yeah, it's better than that.
<paroneayea>(from the "industry" at least)
<davexunit>but if someone gave me a piece of software written in rust I wouldn't know how to build it
<davexunit>not good for users yet
<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>but I think that's the right direction
<paroneayea>davexunit: yeah :
<avoine>that would be cool
<paroneayea>I guess we don't talk about gpd ;)
<dsmith-work>Shell as a backend is just..
<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!
<paroneayea>*and* easy to reason about
<paroneayea>davexunit: right
<dsmith-work>You would need guile just like you need auto*
<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.
<dsmith-work>That reminds me
<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.
<davexunit>avoine: make already does that
<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"
<davexunit>it's just a simple task runner
<paroneayea>davexunit: yeah just look at the mess the js world is in
<davexunit>yeah same with grunt and gulp
<dsmith-work>paroneayea: Exactly
<davexunit>they don't do anything that make does that makes it useful
<paroneayea>make leaves out a lot though
<paroneayea>I've tried doing just-make without autoconf, eventually you need something like autoconf
<davexunit>yeah using just make is bad
<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"
<davexunit>and write a "simple" makefile
<paroneayea>davexunit: well and I think it's a fair criticism
<davexunit>that is simple because it doesn't support user defined prefixes
<paroneayea>davexunit: I still don't understand autotools
<random-nick>there's also cmake
<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
<dsmith-work>clean and simple
<davexunit>dsmith-work: but they never work
<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>when packaging for guix.
<paroneayea>autotools "just works" for users
<davexunit>they *always* forget something important
<paroneayea>but, extending or understanding it is hard
<davexunit>sometimes it's as simple as forgetting an equivalent of --prefix
<paroneayea>everything else is terrible
<dsmith-work>Hmm. Ok.
<davexunit>harcoded /usr stuff everywhere usually
<paroneayea>I think "a guile based build system DSL with an output target of shell"
<paroneayea>is the nicest possible direction
<davexunit>I think we need a make that makes doing the right thing simple
<paroneayea>that would be a world of work though
<davexunit>because make on its own just doesn't cut it
<random-nick>paroneayea: why not target make?
<dsmith-work>You know, this discussion happened right here about 15 years ago.
<paroneayea>random-nick: sure, target make + shell I guess
<paroneayea>dsmith-work: did it? :)
<dsmith-work>jao and rotty were working on it.
<dsmith-work>conjure I think it was.
<paroneayea>an scsh type syntax + shell *output* would be a dream
<paroneayea>dsmith-work: cool
<davexunit>surely we've learned since then :)
<dsmith-work>A "make" written in (guile)scheme
<random-nick>what's wrong with autotools?
<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.
<davexunit>that is nearly impossible to reason about
<paroneayea>tl;dr hard to understand and extend, especially for non-C systems
<paroneayea>and what davexunit said
<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
<davexunit>to improve the developer interface
<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.
<dsmith-work>THey just don't like me!
<davexunit>dsmith-work: you mean writing a yeah it's not great
<davexunit>that is what we're saying needs improvement.
<paroneayea> is a ton of magic
<paroneayea>the prefix and suffix stuff especially
<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
<random-nick>a guile dsl for generating ./configure
<davexunit>a lot of new languages conflate the build system and package manager
<davexunit>and that's a mess
<paroneayea>davexunit: yes, agreed there
<paroneayea>davexunit: I used to think that was fine, but after 5 years of struggling with people updating mediagoblin
<paroneayea>I think that's a mistake
<davexunit>those two fundamental things autotools got so, so right. just a shame it got the implementation languages and API so, so wrong.
<random-nick>I think Common Lisp ASDF got it right
<paroneayea>and at least python you *can* separate
<paroneayea>random-nick: yeah? I don't know much about asdf
<davexunit>common lisp seems to have the same problem I mentioned above
<paroneayea>davexunit: I think asdf predates quicklisp
<davexunit>at least quicklisp does, which uses asdf
<paroneayea>so I do think they have a separation
<davexunit>perhaps asdf itself is fine
<paroneayea>in theory at least
<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 ;)
<random-nick>davexunit: quicklisp is a package manager for asdf
<paroneayea>too bad when I talk to some CL people about Guix they say "YUCK a lisp-1!"
<paroneayea>and I'm like, can't we just get along
<paroneayea>we're lispers
<random-nick>davexunit: asdf only does dependency checking, quicklisp downloads
<davexunit>yuck, unhygienic macros!
<davexunit>random-nick: sounds like asdf is okay then
<paroneayea>yes, the eternal battle :)
<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
<paroneayea>common lisp has a lot of nice things
<paroneayea>even if you don't agree with lisp-1 vs lisp-2
<paroneayea>I agree davexunit, spread the sexp!
<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.
<davexunit>it should be, anyway, IMO.
<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?
<paroneayea>if you have time to respond :)
<davexunit>random-nick: it's a pretty big difference.
<davexunit>very philosophical. should a function be treated as different from any other object?
<davexunit>common lisp says "yes", scheme says "no"
<daviid>yes, no!, yes for the no :):)
<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>wingo: thanx for the info
<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>srfi-18 is clownshoes
<wingo>"it is not an error to unlock an unlocked mutex"
<paroneayea>the lock just spins in its socket
<paroneayea>I've opened those kinds of doors :)
<daviid>its spins in his socks rather :)
<daviid>because clown shoes
<janneke>ACTION finally got pre-r6rs [p]syntax case going in mes!
<wingo>neat :)
<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>but it is the case in guile
<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>such a bad idea
<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