IRC channel logs


back to list of logs

<paroneayea>civodul: got a sec for me to sanity check something based on your experiences?
<paroneayea>civodul: basically, I need a way in mudsync to support outputting to multiple connection types (plain old telnet terminals as well as a browser interface) and I was thinking of making a micro-"skribe" to do it
<paroneayea>it's ok if you don't have time :)
<civodul>paroneayea: so you want to support multiple "textual" output formats?
<civodul>perhaps stexi would work well for that
<civodul>it can do HTML and plain text
<paroneayea>civodul: hm yeah maybe
<paroneayea>and yeah I think multiple "textual" output formats is right
<civodul>you could do skribilo but that's kinda heavyweight for that :-)
<paroneayea>civodul: yeah I tried skribilo at one point :)
<paroneayea>it was a bit too slow for that many messages shooting around
<paroneayea>hence why I was thinking a "skribe lite"
<civodul>i would go for stexi (or plain Texinfo)
<civodul>ACTION -> zZz
<civodul>happy hacking!
<daviid>"... Chez Scheme associates a property list with each symbol, allowing multiple key-value pairs to be stored directly with the symbol..." I don't think we have that in guile do we?
<paroneayea>scheme@(guile-user)> (set-symbol-property! 'foo 'my-prop 'my-val)
<paroneayea>scheme@(guile-user)> (symbol-pref 'foo)
<paroneayea>$7 = ((my-prop . my-val))
<paroneayea>daviid: ^^
<paroneayea>seems we do
<daviid>paroneayea: ah, thanks!
<paroneayea>daviid: I'm not sure how useful it is
<paroneayea>but ther eyou go :)
<paroneayea>> Support for these extra slots may be removed in a future release, and it is probably better to avoid using them. For a more modern and Schemely approach to properties, see *note Object Properties::.
<paroneayea>daviid: ^^
<paroneayea>daviid: you'll probably like the Object Properties API
<paroneayea>it uses setters :)
<daviid>paroneayea: ah, maybe removed ...
<paroneayea>but Object Properties seems here to say
<daviid>paroneayea: it would be nice, imo, to have the chez scheme API
<paroneayea>daviid: note you can do properties on symbols with the object properties API
<paroneayea>since symbols are not GC'ed in guile
<paroneayea>I guess if symbols were GC'ed like they are allowed to be in MIT Scheme iiuc, you might not have such a promise
<daviid>paroneayea: good point! if symbols are not GC'ed in Guile, could they become GC'ed in the future...
<daviid>paroneayea: at this point I'm gathering info because I wanted to anser this email:
<paroneayea>daviid: ah!
<daviid>paroneayea: the Chez scheme approach/API (getprop, putprop, remprop and proterty-list) is almost identical to the CL one iirc
<daviid>paroneayea: did you read that symbols are not GC'ed in the manual?
<paroneayea>daviid: I think so, I remember reading it somewhere
<daviid>ok thanks
<daviid>paroneayea: if by any chance you have some time to read the above mentioned email and have an opinion let me know :)
<paroneayea>daviid: the property list module?
<paroneayea>daviid: I've wondered why we don't have one in guile
<daviid>paroneayea: yes
<paroneayea>since we have alists
<paroneayea>could be nice to have
<paroneayea>I've more or less rewritten those tools several times
<paroneayea>and sure, they're easy enough
<paroneayea>but would be nice to have one you could reference
<paroneayea>daviid: I haven't read the implementation though
<paroneayea>but I support the idea of having a plist module
<daviid>paroneayea: the code is very small/short, here
<daviid>I must say I much prefer the Chez scheme API
<paroneayea>daviid: it looks good to me
<daviid>but it implies to use symbol, where Alex's code 'only' deals with the plist itself ...
<paroneayea>daviid: alex's code is more general
<paroneayea>property lists are used by more than just symbols
<paroneayea>I use property lists for a number of things
<paroneayea>so, it would be good to keep that independent
<daviid>I do to actually :) we all have our plist api :)
<paroneayea>daviid: anyway! not hard to compose alex's module with the object/symbol propery list retrieval api
<paroneayea>so I'd say, looks good to me
<daviid>thanks for looking at this with me! the code looks good to me to
<daviid>paroneayea: any API comment? (copared to your own solution(s) to this plist module)
<paroneayea>daviid: would be nice to have an optional dflt on plist-get
<paroneayea>daviid: I also wonder if plist-ref and plist-set/cons might be better names, just to be consistent with the rest of guile, but
<paroneayea>I'm wine with -get and -put
<paroneayea>er fine
<paroneayea>it's good naming, just maybe doesn't match everything else
<paroneayea>I think it does match elisp though
<paroneayea>so if those are traditional plist names, sounds good to me
<paroneayea>daviid: those are my only api-level comments
<daviid>paroneayea: right, thanks
<daviid>I agree with your comment wrt plist-get, will suggest a default optional arg
<daviid>paroneayea: good point wrt names, I also prefer plist-ref, plist-set
<daviid>put has a fifo conotation (at least in my poor mind :))
<daviid>paroneayea: I'm not sure I'd keep plist-new
<paroneayea>daviid: plist-new should be named plist-append
<paroneayea>it could actually be done with just append, right?
<daviid>paroneayea: I think it shuld not be part of the 'official' module, but a user add-on
<paroneayea>(append '(#:foo bar) '(#:baz basil))
<daviid>paroneayea: yes
<paroneayea>a more useful thing would be to have one that appends and de-duplicates I guess.
<paroneayea>but anyway
<paroneayea>yeah plist-new, probably not needed.
<daviid>paroneayea: ok, plist-ref, -set, -add, -delete, -fold. then i have a quizz wrt duplicates
<daviid>paroneayea: do you think plist-add should bother? i see in his code plist-delete will delete all (if any) ...
<daviid>paroneayea: in his code, plist-set (plist-put) calls plist-delete, which would delete all if more then one, then add
<daviid>paroneayea: i fell an inconssitency here: plist-add does not check, plist-ref always retruns the first it finds (so the last 'puched'), plist-delete (and by transitivity plist-set) deletes all
<daviid>* feel
<daviid>paroneayea: I would be i favor to allow one and only one key as in eq?
<daviid>paroneayea: I think plist-add should return an error if the property already exist, wdyt?
<daviid>paroneayea: last :), plist-add is redondant, since plist-set "Return new plist by changing or adding PROPERTY/VALUE pair in PLIST."
<amz3`>is there an example snippet using the new guile https snippet to download a json file from the internet?
<amz3`>is there an example snippet using the new guile https to download a json file from the internet?
<daviid>paroneayea: so, in summary, I'm in favor of keeping this API: plist-ref, -set, -delete, -fold
***profan_ is now known as profan
<paroneayea>daviid: sounds good
<daviid>paroneayea: it's been nice and useful to review this with you, thanks!
<paroneayea>daviid: happy to!
<paroneayea>daviid: I guess re: duplicates,
<paroneayea>the current code doesn't do checking and it's fine
<paroneayea>it's closer to like alists that way
<daviid>paroneayea: but if we remove plist-add, it becomes impossible to duplicate, which I'm in fvor
<daviid>* in favor
<paroneayea>daviid: maybe better to name plist-add as plist-cons
<paroneayea>similar to alist-cons
<paroneayea>which is more clear that it's just adding without de-duping
<daviid>paroneayea: I think I prefer to remove it from the module, and let users do that if they wish to
<daviid>i really see the property key as a primary key here (db analogy)
<paroneayea>daviid: hm, I'm not so sure! I think it's useful to have, just mention it in the docstring
<daviid>if users want alist they can use alists ...
<paroneayea>daviid: there's still advantages to plists in that they're slightly faster to access, and are used in things like lambda* keywords
<paroneayea>so having an append-only set operation is good I think
<daviid>paroneayea: what does not sound right to me is plist-set does (plist-add (plist-delete plist property)
<daviid> property value))
<daviid>paroneayea: I mean that if plist-add is kept, plist-delete should dlete the first, not all
<daviid>(I think I prefer plist-add toplist-cons, but no big deal)
<daviid>and plist-set should set the first it finds, not delete all ...
<daviid>paroneayea: damned design is hard! like naming :
<daviid>* :)
<daviid>paroneayea: why would yu want/need more then one entry per key? especially if plist-ref returns one and the first value it finds, so the last that has been added? with this interface, you can't access others (except using -fold, but imo that is not the purpose of plist-fold
<daviid>paroneayea: I personally still see the property key as a db primary key: one and only one ...
<jmd>In this error message: "ERROR: Wrong type to apply: (lambda (x) (bold x))" which thing does it think is the wrong type?
<Wojciech_K>wingo: after pulling fibers repo (after 3 months or so) 'make' failed with 'ice-9/boot-9.scm:762:26: no code for module (fibers config)
<Wojciech_K>wingo: And I had to manually make fibers/config.scm
<Wojciech_K>Not sure why this didn't happen automatically, even after 'touch'ing fibers/
<Wojciech_K>Thanks for the library!
<wleslie>greetings, beguilers
<janneke>hey wleslie
<amz3`>héllo !
<wleslie>what's new?
<wleslie>I guess 2.1.6 is new and I should try it out...
<amz3`>I am looking for an example use of guile to download a json over https
<amz3`>catonano: héllo therre
<amz3`>catonano: did you read the small documentation I made?
<catonano>amz3`: yes I did
<amz3`>catonano: what do you think I should add?
<catonano>amz3`: good affternoon !
<amz3`>It's already the afternoon, I did no notice
<catonano>amz3`: I'd say it already adds to wat you wrote on your blog
<catonano>I would say
<amz3`>I am thinking about copying the doc in the blog into the documentation
<catonano>you could move the examples on the movies reccomendation inside the docs
<amz3`>ah ok
<catonano>ust give me a minute
<catonano>amz3`: is there a way to delete a vertex from the graph ?
<catonano>amz3`: overall I would say that you made a really good ob on documentation
<catonano>it is way better, now
<catonano>amz3`: ob ?
<catonano>what does that mean ?
<amz3`>catonano: you said I did a really good ob on documentation
<amz3`>good job ok :)
<catonano>amz3`: you did !
<amz3`>well there is no public API to delete a vertex
<catonano>Actually I don't need to delete vertices. I was asking just in case ;-)
<amz3`>It should be equivalent to call: (ukv-del! uid)
<amz3`>it's must be eqv to that
<catonano>exactly ;-)
<amz3`>ah ah
<amz3`>so you know the thing
<catonano>right :-)
<amz3`>wait no
<amz3`>it's not eqv because you need to delete edges
<amz3`>when you delete a vertex you must delete edge that point to it, one way or another
<amz3`>deleting an edge is a simple ukv-del!
<catonano>amz3`: right !
<amz3`>I am mostly procrastinating looking for something new to code
<catonano>you cold update the wiredtger package for guix. The current one os 2.8.0
<catonano>Also you could packkage guiile-wiredtiger for guix
<catonano>you could attemt some fancy demo based on relational programming
<catonano>I'd be curios of some original data science exploration based on that
<catonano>I'd be also curious of soe work on natural langages
<amz3`>Here is an example query using high level interface for ukv based on microkanren
<amz3`>(define (query:hashtag-message name)
<amz3`> (map car (query* uid? :where ((hashtag?? 'hashtag/name name)
<amz3`> (tagged?? 'tagged/hashtag-uid hashtag??)
<amz3`> (tagged?? 'tagged/message-uid uid?)))))
<amz3`>it's fetch all messages that have a given hashtag/name
<amz3`>I want to create something new that I've not done already
<amz3`>reworking my previous project to make them work on new wiredtiger seems boing
<catonano>doesn't it workk already on wiredtiger 2.9.0 ?
<amz3`>To Be Honest I did not try that query in particular
<amz3`>but it should work
<amz3`>I must a unit test with variable binding in the high level interface
<amz3`>in the above query* the tagged?? is translated into a microkanren 'fresh'
<amz3`>tthe thing is that using the high level interface, intermediate variable are spawn magically without any previous declaration
<amz3`>this looks odd
<amz3`>maybe that's what is called unhygenic
<amz3`>heja stis
<amz3`>how do you think your constraint extension to minikanren can be helpful to query something like
<catonano>amz3`: I didn't mean that particular query. I meant guile-wiredtiger. Doesn't it work on wiredtiger 2.9.0 already ?
<amz3`>catonano: yes it does
<catonano>so whhy you say that it would be boring to port it to the new wiredtiger ? It's ported already
<stis>donough, what's
<amz3`>stis: it's a database similar to wordnet
<amz3`>catonano: I meant to say that I find it boring to port nanoblog (a soft) that use ukv and minikanren to new wiredtiger
<catonano>amz3`: do you mean that nanoblog is based on the previous version of guile-wiredtiger ?
<catonano>I mean of ukv
<catonano>yes I get it
<catonano>guile-wiredtiger is new but not ukv
<catonano>ukv is not updated
<catonano>did I understand correctly ?
<amz3`>catonano: yes, nanoblog is based on the previous version of guile-wiredtiger
<catonano>ah I see
<catonano>is tha API changed ?
<amz3`>I just renamed ukv by tuplespace
<amz3`>and added a supported case in miniakren API
<amz3`>Previously it was not possible (for some reasons)
<amz3`>... it's too complicated to explain
<catonano>so it shouldn't be that hard to port it
<catonano>right ?
<amz3`>the thing is that there is artanis version and pure guile version
<amz3`>I want to drop the artanis versioni
<amz3`>I look if there is still the code without artanis in the repo
<amz3`>the artanis-free version is in
<amz3`>I want to build something useful
<amz3`>nanoblog is just goofing around
<catonano>amz3`: I see
<catonano>Look I'm a bit distracted now, I'll take my time to think abouut this stufff
<amz3`>don't hurt yourself ;)
***karswell` is now known as karswell
<catonano>paroneayea: ehy
<ft>Hm. ‘readdir’ expecting file names to adhere to any sort of encoding seems unfortunate. If you're in a UTF-8 locale and a file name contains bytes that have their high-bit set, you're screwed. Shouldn't all these return bytevectors?
<ft>If I do this: touch $'.a\\xf3f' (that's in zsh, but I think bash supports $'...' quoting as well), I don't see a way to "see" that file in Guile.