IRC channel logs

2020-05-06.log

back to list of logs

<daviid>sneek: later tell lafrenierejm get-keyword is defined/exported in/from (oop goops), so you may either (use-modules (oop goops)) or 'snarf it' if you don't want to use the all (oop goops) module, just bind the following to a 'local' name: (@ (oop goops) get-keyword)
<sneek>Got it.
***catonano_ is now known as catonano
<ennoausberlin>Hello. Is there a srfi function to convert a number of seconds (I get this from /proc/uptime) to a more readable form , e.g. 1 year 6 days 2 hours 30 minutes?
<chrislck>localtime and mktime
***apteryx is now known as Guest182
***apteryx_ is now known as apteryx
<wingo>those are for dates
<wingo>not durations
<wingo>i think for durations you need to roll your own thing
<ennoausberlin>@wingo: I could not find any, but I wanted to ask here before I do the calculations by myself. Thank you
***deesix_ is now known as deesix
<dsmith-work>Hey Hi Howdy, Guilers
<mwette>Greetings!
<wingo>o/
<dustyweb>hi wingo
<dustyweb>wingo: so what do you think about trying to get fash.scm into Guile proper?
<dustyweb>if I volunteered to do the work, do you think it would be welcome?
<dustyweb>I think it would be nice to make it broadly available
<dustyweb>we do have vhashes but they aren't thread safe. IIRC fash is right?
<dustyweb>and seems better performant I thiiink but i don't remember
<wingo>happy to include it in guile, fash should be thread-safe but needs to use atomic boxes rather than its own thing
<dustyweb>it's been a while since I remember why I liked it better
<dustyweb>wingo: cool
<wingo>can you check with rlb if fash is the right thing? he is working in similar areas
<dustyweb>oh great
<dustyweb>rlb: hi!
<dustyweb>let's talk
<dustyweb>wingo: I'm going to start porting Goblins to Guile
<dustyweb>and I want to get my Racket and Guile programs talking
<dustyweb>but first thing's first: we need to agree on a nice functional hashtable :)
<dustyweb>(yes that can be changed later but I'd love to do it sooner than later!)
<dustyweb>rlb: wingo: btw I really like that Racket has separate hashtable types for hash(equal), hasheq, hasheqv
<dustyweb>something I hate about the default hashtables in guile is that it's the *operations* that determine that
<dustyweb>and then you can mess up your hash
<dustyweb>so annoying
<wingo>indeed
<dustyweb>but fash does better
<dustyweb>I'll also say something that may be controvercial in scheme-land: Guile's default syntax would be improved if we had a first-class representation of hashtables. it's not super high priority but
<dustyweb>I noticed I chose the right datastructure more often in Racket because I wasn't aiming for repl prettiness as much
<dustyweb>O(n), O(no)
<dustyweb>the wrong datastructure obviously being alists
<dustyweb>which like yes they're perfectly fine and fast for small things but it's tempting to lie to yourself "well this will probably stay small!" until it doesn't
<dustyweb>and then you have Regrets (TM)
<dustyweb>and hashtables are such a common use case
<dustyweb>I think it's worth it
<dustyweb>but again, not a killer issue
<dustyweb>anyway hi! I hope everyone in #guile has been having fun in my pseudo-absence :)
<dustyweb>and isn't too annoyed by my wordy return either ;)
<dsmith-work>dustyweb: What do racket first-class hash tables look like? (got a url?)
<dustyweb>dsmith-work: like so:
<dustyweb>#hash((a . 1) (b . 2))
<dustyweb>#hasheq((a . 1) (b . 2))
<dustyweb>#hasheqv((1 . a) (2 . b))
<dustyweb>now here's the gross part
<dustyweb>notice that the symbols aren't quoted
<dustyweb>you have to use quasiquote to insert values
<dustyweb>which makes no sense to me
<dustyweb>I mean, as its display form, sure
<dustyweb>but wtf
<dustyweb>so my proposed syntax, let's say we were defining a hashtable, would be
<dustyweb>(define new-hash
<dustyweb> #hash(('a 1) ('b 2)))
<dustyweb>and you could always quote it like
<dustyweb>(define new-hash
<dustyweb> '#hash((a 1) (b 2)))
<dustyweb>that seems more sensible to me
<dustyweb>there's no need to introduce cons notation for this
<dustyweb>and
<RhodiumToad>hm, wouldn't that be inconsistent with #(...) tho?
<dustyweb>good to use quoting patterns that more closely resemble normal scheme
<dustyweb>RhodiumToad: Racket also has #(...) for vectors
<dustyweb>observe that it's #(
<dustyweb>so
<dustyweb>#hash
<dustyweb>is easily distinguishable
<dustyweb>right?
<RhodiumToad>(symbol? (vector-ref #(a) 0)) ;; #t
<dustyweb>RhodiumToad: yes, but
<dustyweb>oh wait
<dustyweb>RhodiumToad: you're talking about the quasiquote syntasx
<RhodiumToad>no
<dustyweb>rather than #hash
<dustyweb>?
<dustyweb>ah
<dustyweb>#hash(a) is a syntax error in guile
<dustyweb>In procedure scm_lreadr: #<unknown port>:3857:3: Unknown # object: #\h
<dustyweb>but
<dustyweb>I think guile does have a pattern using #
<dustyweb>for other things
<dustyweb>so maybe some other syntax is necessary
<dustyweb>I'm not sure what
<RhodiumToad>what I'm saying is that for #hash(...) to evaluate its args would be inconsistent with #(...) which does not
<dustyweb>RhodiumToad: fair
<dustyweb>yes that's true
<dustyweb>so maybe #hash should not evaluate its args.
<dsmith-work>There is read-hash-extend, but I think that's for single chars.
<dustyweb>another option is to go the closure route but it would be incompattible with the curly infix syntax
<dustyweb>or, modified closure:
<dustyweb>{[a 1] [b 2]} ;; or {(a 1) (b 2)}, [] is just convention
<dustyweb>I don't like {key1 val1 key2 val2}, easy to get lost... closure also flattens let, which is gross
<dsmith-work>Ya, seems to be a single char.
<dustyweb>but {} for dictionaries matches a lot of the world
<dustyweb>so the real thing is that I think you'd want a syntax that the repl, by default, would also print and pretty print with, and that it's syntactically common to do that
<dustyweb>and whatever that's for should be for the immutable hashtables, obviously
<dustyweb>but since it's a late addition, I'm not sure what kind of character choice would be commonly available
<dustyweb>~? ;)
<lloda>dsmith re: guile-cairo, I guess I'm technically a maintainer, but I only stepped in b/c i needed a couple bugs fixed at the time. I couldn't get the doc gen system to work and I did try :-/ help would be very much appreciated.
<RhodiumToad>why do you want read syntax for it, rather than for example having a form which takes an alist and makes a hash table from it?
<dustyweb>RhodiumToad: that's technically "fine" in a sense, but my argument is
<dustyweb>it changes how users tend to "choose" datastructures
<dustyweb>since lispy users like stuff that (pretty) prints at the repl a lot
<dustyweb>so having something as common as a (functional) hashtable have such representation by default, I'd argue, impacts that choice... right now I think a lot of people choose alists where inappropriate in guile
<dustyweb>including me
<dustyweb>I'm guilty of that
<dsmith-work>So. Could the writer for a hash also include alist->hash (or whatever) ?
<dustyweb>dsmith-work: you mean actually print out alist->hash?
***rekado_ is now known as rekado
<dsmith-work>Ya.
<rekado>I guess nobody likes SRFI-10, but we can do #,(hash ((a 1) (b 2)))
<rekado>(import (srfi srfi-10)) (define-reader-ctor 'hash (lambda (alist) `(alist->hash-table ',alist)))
<dustyweb>dsmith-work: that doesn't really work given the way that people copy-pasta around such things, insert them into quoted datastructures
<dsmith-work>Yeah, something, like that
<dustyweb>keep in mind that when the repl prints things out it's usually implicitly quoted
<dustyweb>scheme@(guile-user)> (list 1 2 3)
<dustyweb>$45 = (1 2 3)(list
<dustyweb>er
<dustyweb>scheme@(guile-user)> (list 1 2 3)
<dustyweb>$45 = (1 2 3)
<dustyweb>rather than
<dustyweb>scheme@(guile-user)> (list 1 2 3)
<dustyweb>$45 = (list 1 2 3)
<dsmith-work>TRue
<dustyweb>or
<dustyweb>scheme@(guile-user)> (list 1 2 3)
<dustyweb>$45 = '(1 2 3)
<RhodiumToad>rekado: even the documentation page for srfi-10 doesn't like srfi-10
<dsmith-work>heh
<rekado>it even talks about this very use case
<dustyweb>I hope I'm not being annoying coming in and being like, "Guile, we need to change everything and do all these things because I've been hanging out in Racket land too long, nya-nya!"
<dustyweb>I'm hoping to do productive cross-pollination rather than being invoking pollination allergies :)
<daviid>dustyweb: nice to hear that you're 'really' back! :) fwiw someone worked on fash, here is they repo https://hg.sr.ht/~bjoli/guile-fash
<dustyweb>daviid: yes we talked on the list... sadly I can't clone that url!
<RhodiumToad>no, the annoying thing is when you use lots of short lines, please make less use of the return key
<dustyweb>I said that in an email just this morning so I guess we'll see what they say
<dustyweb>RhodiumToad: are you sure me having every message be really long, but having the same amount of words, wouldn't be worse? :)
<RhodiumToad>it would not be worse
<daviid>dustyweb: porting mediagblin to guile, that might well become our killing app (considering guix 'more then an app' :))
<dustyweb>daviid: well, it would be porting spritely to guile at this point :)
<dustyweb>mediagoblin is still happening and just put out a release but I'm not the primary maintainer anymore... I'm working on some next-generation federated social web things
<dustyweb>basically "now that activitypub is well adopted, what is it that we're not doing well yet?"
<dustyweb>so that's basically
<dustyweb> - better security
<str1ngs>killer goblins!
<dustyweb> - content-addressed storage
<dustyweb> - bridge federated social networks with "p2p" networks
<dustyweb> - distributed social web as a distributed social game ;)
<dustyweb>most of that work has been me working on an ocap'y actor model implementation in Racket, and the storage layer
<dustyweb>the next step is to get two actor model systems to talk to each other
<dustyweb>for distributed programming
<dustyweb>so I plan to get my racket actor system talking to a guile one
<daviid>is that 8sync
<daviid>you ported 8sync to racket
<daviid>?
<dustyweb>daviid: sort of... it's 8sync after I learned a lot more about ocap security
<dustyweb>and the actor model fundamentals
<dustyweb>and got review from people who actually know what they're doing :)
<dustyweb>I have debated whether or not to simply reuse the name/branding of 8sync
<dustyweb>or to call it Goblins in Guile too
<dustyweb>as I port it back
<dsmith-work>lloda: That's because it uses some scripts and code that only exist in the Guile source tree. (Is not installed)
<dsmith-work>lloda: Try adding your (built?) guile source tree to your $PATH
<dsmith-work>It's been decades now
<dsmith-work>I'm thinking that code is not changing much. Might be ok to install it? (the C doc snarfing machinery)
<lloda>from what i remember, i needed to install guile-gnome and that needed g-wrap etc.
<lloda>in the end it did run but it choked on the new format of the cairo doc
<lloda>but, it's been a while
***amiloradovsky1 is now known as amiloradovsky
<daviid>I think there is 'bug', or maybe i should say an improvement that needs to be done on our texinfo modules so it handle 'new' 'gtk/cairo like' docs
<daviid>guile-gnome doc can't build either, that's ben a while now ...
<justin_smith>dustyweb: I recently came back to guile for a personal project after years of using clojure professionally
<justin_smith>dustyweb: one of the first things I did was implement a non-quoted round-trip #h(#:a 0 #:b 1) read / write syntax for immutable vhash hash-tables
<justin_smith>I discovered that I would have to do a lot more work for the h to be more than one char
<justin_smith>(or it seemed so)
<justin_smith>I was suprised how concise a working reader was:
<justin_smith>(read-hash-extend #\h (lambda (chr port) (let ((data (read port))) `(ht ,@data))))
<justin_smith>but that's very non-scheme because I wanted it maximally clojure flavored - so it doesn't quote the body and there's no internal structure to the input, just a flat list that gets partitioned into pairs by the ht function
<janneke>(and=> (pair? (call-something)) car) ... it /could/ work
<janneke>why #t, though
*janneke spends another let
<justin_smith>also, fash looks very useful, I hope a fork called antifa comes out
<cyclopsian>could someone post that d-bus binding here again? I think I saw it here a few days ago but lost the link
<str1ngs>cyclopsian: I think it was called ac-dc-bus
<arpunk>cyclopsian: https://gitlab.com/weinholt/ac-d-bus
<cyclopsian>thank you
<cyclopsian>lloda: i happened to be looking at the guile-cairo docs a few days ago, I think the problem was the call to "guile-snarf-docs-texi"
<cyclopsian>that doesn't exist anymore
<cyclopsian>it was replaced with "guild snarf-check-and-output-texi"
<dsmith-work>Ah
<cyclopsian>in upstream guile
<civodul>justin_smith: re #h, i'd recommend a good old macro like https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/linux-initrd.scm#n253
<civodul>it's about as convenient and doesn't have the drawbacks of reader extensions
<civodul>namely the fact that reader extensions can collide (it's a global name space)
<civodul>and plain 'read' doesn't work on them
<justin_smith>yeah, I was explicitly doing this for my own vanity / convenience, but using a proper macro makes sense
***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
<wingo>moo
<civodul>hey!
*civodul has yet to play with the new compiler
<civodul>i set out to fix a bad bug in Guix but i keep procrastinating
<ft>new as in post-3.0 new?
<rekado>ft: yes, a new, less optimized compiler without a CPS step
<rekado>intended for much faster compilation with somewhat slower resulting code.
<ft>rekado: I see. Begs the question why?
<ft>ah
<rekado>this could be great for Guix which has lots of modules with thousands of variables that probably don’t benefit all *that* much from optimizations
<dsmith-work>wingo: So do you have a idea how much the new compiler will shorten bootstrapping builds?
<wingo>dsmith-work: somewhere between 2x and 20x i think, not quite sure tho
<dsmith-work>wingo: I'm amazed at how fast using the bootstrapped .go files is. Like 6 minutes or so. (on an 8 core box)