<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>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à :) <paroneayea>and fixed a bunch of bugs I was struggling with in the process <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 <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 ? <paroneayea>adhoc: yes that's what I said I'd do, refactor for guile upstream <saper>not (yet) a Guiler, but hello :) <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 <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 '@ <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>that'll drop the @ in front, leaving you a bare alist <davexunit>taylanub: that #hash would have to be a persistent structure <taylanub>davexunit: what does "persistent" mean in this context? <davexunit>something lik e(hash-set table "foo" 1) should return a *new* hash <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 <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. <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>I mentioned guile and web programming and json on #emacs and holomorph asked for details <paroneayea>I've merged (ice-9 json) into activitystuff as (activitystuff contrib json) for now <davexunit>er, I actually don't the gender of holomorph. sorry! <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. <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. <csed>davexunit: If it were in a REPL, yeah. <csed>davexunit: But why have set!, then? <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 <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. <csed>davexunit, taylanub: Cheers. Makes more sense, now. <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: http://sprunge.us/cCUS <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>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
<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 <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. <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>but we do use the source info for objects in gnu guix <taktoa>oh it's called source-properties <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>would be to have a package format which is "easy" and schemey for most people writing libraries to use <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 <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) <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 <taktoa>yeah, that's what I was suggesting <taktoa>something equivalent to cabal 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 <paroneayea>I wonder if an external package to guile could provide this in the meanwhile <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 <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) <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>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>ACTION wrote to guile-user with ideas for 'guild init' <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?