IRC channel logs


back to list of logs

<davexunit>I have an accessor procedure 'brush-blend-mode' and a setter 'set-brush-blend-mode!'. a monadic version of the latter may be defined as (define (please-name-me blend-mode) (lambda (brush) (set-brush-blend-mode! brush blend-mode)))
<davexunit>but what is a good name? simply 'blend-mode' looks like a constructor function for a blend mode object.
<davexunit>'brush-blend' or 'blend-brush' may work
<davexunit>Guix sometimes uses past-tense verbs for monadic functions, so maybe 'brush-blended' but that doesn't sound great to me either.
<daviid>davexunit: fyi, brush_get_blend_mode and brush_set_blend_mode is how gobject based libraries would name these 2. then in guile, we would [automatically] define 1 function for each, a goops <brush> class with, among others, 1 blend-mode slot with its accessor [which can be used with set!] so we'd have: brush-get-blend-mode, brush-set-blend-mode, blend-mode [(set! (blend-mode my-brush) a-blend-mode)] not sure it helps, but ... and i
<daviid>know you don't use goops but ... voilà :)
<davexunit>racket's pict3d is so cool
<paroneayea>I refactored a bunch of code for clarity
<paroneayea>and fixed a bunch of bugs I was struggling with in the process
<paroneayea>without even meaning to
<paroneayea>such a good feeling
<davexunit>sounds like a good hack time
<davexunit>I'm a bit in the weeds atm
<paroneayea>I'm reaching the point where I need a valid https resolver
<paroneayea>I promised to submit that to guile upstream refactored from guix
<paroneayea>now is the time I guess
<davexunit>that would be a most awesome addition to guile
<adhoc>paroneayea: what do you mean by "https resolver" ?
<adhoc>something that terminates SSL HTTP sessions?
<paroneayea>adhoc: something that can open https connections
<paroneayea>adhoc: by default, guile does not have this ability, though code exists for it in guix
<adhoc>so it needs to be a standard library ?
<adhoc>or in guile run time ?
<nalaginrut>morning guilers~
<paroneayea>adhoc: yes that's what I said I'd do, refactor for guile upstream
<paroneayea>I will try to in the next week or two
<adhoc>paroneayea: nice =)
<civodul>Hello Guilers!
<saper>not (yet) a Guiler, but hello :)
<wleslie>hello (:
<artyom-poptsov>Hello everybody
<artyom-poptsov>saper: Join us, we have recursive cookies.
<saper>frankly I am afraid I might start to cons one day.
<nalaginrut>is there any explain for vm_cont in vm.h? there's no any comments for the fields
<nalaginrut>civodul: vm continuations
<nalaginrut>maybe I should ask in ML
<holomorph>davexunit: what is the type returned by read-json? i guess i don't know what (@ ...) means
<davexunit>holomorph: there are many types, but for an object it's a list tagged with the symbol '@
<davexunit>like '(@ ("foo" 1) ("bar" 2))
<davexunit>er, '(@ ("foo" . 1) ("bar" . 2))
<taylanub>ACTION dreams that one day that will instead be #hash(string ("foo" . 1) ("bar" . 2))
<holomorph>davexunit: how can i get things out of (a la assoc) a tagged list? it's not really an alist, right?
<taylanub>holomorph: (cdr tagged-list) :-)
<taylanub>that'll drop the @ in front, leaving you a bare alist
<davexunit>yes ^
<davexunit>taylanub: that #hash would have to be a persistent structure
<davexunit>otherwise it's not fit for this.
<taylanub>davexunit: what does "persistent" mean in this context?
<davexunit>something lik e(hash-set table "foo" 1) should return a *new* hash
<davexunit>and not alter the old one
<taylanub>oh... why is that?
<davexunit>much like how (cons "foo" tail) doesn't alter tail
<davexunit>taylanub: because without persistence, manipulating json structures would have to be done imperatively rather than functionally.
<davexunit>the thing that makes the current representation good is that you can write pure functions that produce json
<davexunit>and you can use quasiquote to template the json
<holomorph>taylanub: oh ._.
<taylanub>well, I'd think that's an orthogonal issue to the JSON API. I can also imperatively work with the alists it returns after all, no?
<davexunit>but that's the *only* option with standard hash tables.
<davexunit>you could no longer write pure functions that manipulate json objects.
<taylanub>well, right. purely functional could be badly jolted on top at best.
<taylanub>purely functional operations*
<davexunit>it's an important property to keep.
<davexunit>it's one of the big flaws with guile-json
<davexunit>guile-json uses hash tables to represent objects
<holomorph>well my code is now simpler with ice-9 json :D
***Guest71381 is now known as berndj
<taylanub>it might be a good idea to offer a parameter object that determines whether JSON objects become alists, hash tables, or property lists. the Elisp JSON lib offers that and I find it pretty neat.
<taylanub>might also be a good idea to offer choice between tagged and untagged alists, and choice between representing arrays as lists and vectors. and then there's "null" which has no natural mapping to Scheme (except maybe #nil :P). json.el makes that all configurable which I find pretty nice.
<davexunit>holomorph: I'm glad to hear it!
<davexunit>that means I did something right ;)
<paroneayea>oh is ice-9 json merged yet?
<davexunit>I mentioned guile and web programming and json on #emacs and holomorph asked for details
<davexunit>so here we are :)
<paroneayea>ahh :)
<paroneayea>I hope it gets merged soon!
<paroneayea>I've merged (ice-9 json) into activitystuff as (activitystuff contrib json) for now
<davexunit>and I sent him a link to that to snarf ;)
<davexunit>er, I actually don't the gender of holomorph. sorry!
<davexunit>don't know*
<holomorph>davexunit: well you got it right anyways :P
<csed>So the GNU Guile book says that redefining a variable is done using (set! ...)
<csed>But I just tried it with (define ...) and it worked. I'm guessing there's a reason for the set!, but don't really know what.
<davexunit>define is special at the top-level
<davexunit>it's conducive to working at the REPL
<csed>davexunit: Hm, weird. So yeah, I ran two defines on the same var via Geiser and the value didn't change. But it did via set!
<csed>I mean, weird. I'm guessing it's how it's supposed to work, I'm just not sure why it works like that.
<davexunit>what do you mean?
<davexunit>(define foo 1)
<davexunit>(define foo 2)
<davexunit>would return 2
<csed>davexunit: If it were in a REPL, yeah.
<csed>davexunit: But why have set!, then?
<taylanub>csed: because that only works in a REPL
<csed>taylanub: Yeah. But why?
<davexunit>because that behavior of define is special at the top-level, you wouldn't be able to mutate variables elsewhere
<davexunit>(define foo 1)
<davexunit>(let ((bar 2)) (define foo bar))
<taylanub>it's allowed only for convenience in a REPL. in a program, it doesn't make sense to define the same thing twice.
<davexunit>that (define foo bar) form does *not* mutate the top-level foo
<davexunit>it instead defines a new variable 'foo' in the local environment of that 'let' form.
<davexunit>(let ((bar 2)) (set! foo bar))
<davexunit>this would mutate the top-level foo
<csed>davexunit: Ah, I see.
<csed>Hm, alright.
<csed>davexunit, taylanub: Cheers. Makes more sense, now.
<taylanub>csed: note also
<taylanub>(when I said "it doesn't make sense to define the same thing twice," I meant within a single scope. shadowing it with a different definition in a nested scope is OK of course, as davexunit explained.)
<csed>taylanub: I still find it interesting that that doesn't work. Not wrong, or whatever. Guess I need more background knowledge on what happens via define in order to figure it out.
<taylanub>csed: yeah, define is surprisingly complicated. in programs (instead of REPL), sequences of 'define' can usually be turned into an equivalent 'letrec*' expression; e.g. my example above is 100% equivalent to:
<taylanub>that makes its semantics pretty clear. (if you know letrec*, of course. you can look into it.)
<taylanub>another thing is that these "internal definitions" *must* be an uninterrupted sequence at the beginning of a "body" (the body of a lambda, let, etc.). at the top-level they can be mixed with non-definition things
<csed>taylanub: Huh. That last example is really good to know. I can already see myself mixing the entire thing and going "why god why" for who knows how long. But yeah, interesting. Cheers.
<taylanub>hmm, I find myself explaining this to people again and again. I should probably write a summary on it that I can link people to.
<csed>taylanub: Go for it. Drop it in the topic.
<csed>Like, #guile FAQ.
<csed>Sort of like what the #bash people did. 90% of the time when someone asks a question they just drop a link to the FAQ.
<taylanub>well, this is a very specialized topic. maybe it could be integrated into the Guile manual somehow
***rlb` is now known as rlb
<kristofer>I'm trying to figure out why this ("Referer" . "") returns an error that it is not a pair
<holomorph>perhaps the headers are supposed to be an alist
<paroneayea>ACTION is sad that some of wingo's libraries no longer have an official git home
<paroneayea>ACTION wants to submit a patch to guile-charting
<paroneayea>maybe I should ping him next time he's on
<kristofer>holomorph, thanks.
<davexunit>kristofer: because that's a single header, not a list of headers
<taktoa>I'm using the (read) function to normalize some scheme code (e.g.: convert #b101011 to 43, things like that; I just want it to be easier to parse the resultant output from (write)).
<taktoa>I was looking in the arguments to (read-enable) etc. and I noticed one called "position", which claims to preserve source locations from the given port in the resultant s-expression.
<davexunit>kristofer: you want '(("Referer" . "http://example"))
<taktoa>However, I can't seem to find any information on introspection of said source locations.
<taktoa>anyone know how to get at that info?
<davexunit>hmm not off the top of my head
<davexunit>but we do use the source info for objects in gnu guix
<taktoa>oh it's called source-properties
<taktoa>figured it out
<davexunit>ACTION sketches a blog post about web programming in guile
<davexunit>I don't intend for it to be a tutorial, but I might build a very small application to tie it all together.
<taktoa>by the way, who would be interested in reviving the guildhall package manager with a not-tiny repository of packages?
<taktoa>like, interested in the result, not necessarily volunteering or anything
<davexunit>I'm not particularly interested in yet another language package manager.
<taktoa>I can see where you're coming from (I am a Nix user)
<davexunit>I already use and work on Guix, which is a general-purpose package manager written in Guile
<davexunit>so I don't have motivation to work on the guildhall, but I think it has a niche if only there were some people that wanted to maintain and improve it.
<paroneayea>the main thing that is interesting to me maybe
<paroneayea>since yeah, I also use guix for packaging
<paroneayea>would be to have a package format which is "easy" and schemey for most people writing libraries to use
<paroneayea>that would be pretty great
<taktoa>I think the advantage of having a non-guix guile package manager is that it represents an upstream from which nix, guix, and other linux distros could generate packages.
<taktoa>I like guix, but I really don't see e.g. arch generating guile packages from guix specifications.
<paroneayea>taktoa: probably, and if we make it easy for guix to import from, it'll be probably sane/easy enough to do for all other distros too.
<paroneayea>davexunit said "use autotools" to me yesterday(?) on the same subject, and I have an autotools recipe I snarfed from sly/guix but
<taktoa>oh yeah that's also a good point, it should be as easy to use autotools with guile as it is to use cabal with haskell
<davexunit>all the pieces are there
<davexunit>guile ships with
<paroneayea>a) the autotools recipe is not really well documented, I don't know what's going on with it and b) secondarily, it would be nice if the default recipe would be LGPL or more lax so that at least packages have an easy direction towards guile inclusion if they like (though that could be done with an autotools)
<davexunit>that provides autotools macros
<paroneayea>davexunit: hm
<paroneayea>davexunit: maybe clear writeup of "structure your application like this" using that would be fine enough then
<davexunit>the 'guild' tool could possibly be used to setup boilerplate for new guile projects
<paroneayea>davexunit: that would be nice
<taktoa>yeah, that's what I was suggesting
<taktoa>something equivalent to cabal init
<paroneayea>yes, or npm init
<davexunit>the whole package metadata guildhall thing is different
<davexunit>but for setting up the build system it would be fine
<paroneayea>davexunit: guildhall does expand the "guild" tool with more commands so
<davexunit>yeah, it's extendable.
<paroneayea>I wonder if an external package to guile could provide this in the meanwhile
<davexunit>yes, it could.
<paroneayea>or so on
<davexunit>if someone wants to write a boilerplate generator, that would be cool
<davexunit>there's many autotools using guile projects out there to base the config off of
<taktoa>well yes but there's fairly significant heterogeneity there
<taktoa>so it's unclear what the "right" way to do things is
<davexunit>that's where you seek feedback from guile-user :)
<davexunit>but for someone to just write the tool that does this would be a big step.
<davexunit>after that, getting the right(tm) config is just a matter of discussion
<taktoa>I would be willing to do it, I just need to time to work on school + other projects
<davexunit>hehe yes we all have a million other things to be doing
<paroneayea>taktoa: if you can write it
<paroneayea>taktoa: I can make a guix package :)
<paroneayea>and be a test user!
<taktoa>fwiw I nabbed
<davexunit>simple and distilled guile autotools stuff
<davexunit>just missing test and doc stuff right now
<davexunit>I actually have a pretty good idea of what the skeleton files should be
<taktoa>that reminds me: what's the preferred unit test framework for guile? guile-lib (unit-test) or that one srfi (can't remember the number offhand)
<davexunit>taktoa: SRFI-64
<davexunit>comes with guile 2.0.11
<taktoa>I figured given the state of guile-lib
<daviid>paroneayea: wrt guile-charting, I'm interested as well how about sending an email to guile-user with patch attached? so guile-charting users can follow and locally apply if they wish to, wdyt?
<taktoa>also if anyone here is a Nix/NixOS user, look forward to (in the near future) a vast improvement in the breadth, organization, and maintenance of Guile packages in nixpkgs
<taktoa>I have a bunch of fixed-up packages that I've been too lazy to send upstream
<davexunit>taktoa: cool :)
<davexunit>we're pretty much all Guix users here for obvious reasons ;)
<taktoa>yeah I figured, just thought I'd mention it
<davexunit>we definitely appreciate good Guile representation in any package manager, though.
<davexunit>so thanks for doing that work!
<davexunit>ACTION wrote to guile-user with ideas for 'guild init'
<paroneayea>davexunit: \\o/
<paroneayea>thank you
<paroneayea>daviid: I could do that
<paroneayea>might be a good idea
<paroneayea>daviid: basically wingo left a (pk) in there and it's annoying me :)
<daviid>paroneayea: ok, but do it yes, not only will it ping him :), but users see things are alive, used, taken care of ... which is god
<kristofer>I need to get every <strong> node from an html document. I'm having trouble figuring out the best approach. Can someone point me to a good document?