<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 <civodul>paroneayea: so you want to support multiple "textual" output formats? <civodul>perhaps stexi would work well for that <paroneayea>and yeah I think multiple "textual" output formats is right <civodul>you could do skribilo but that's kinda heavyweight for that :-) <paroneayea>it was a bit too slow for that many messages shooting around <civodul>i would go for stexi (or plain Texinfo) <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>> 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: you'll probably like the Object Properties API <daviid>paroneayea: ah, maybe removed ... <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>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: <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>paroneayea: if by any chance you have some time to read the above mentioned email and have an opinion let me know :) <paroneayea>daviid: I've wondered why we don't have one in guile <paroneayea>I've more or less rewritten those tools several times <paroneayea>but would be nice to have one you could reference <paroneayea>daviid: I haven't read the implementation though <daviid>I must say I much prefer the Chez scheme API <daviid>but it implies to use symbol, where Alex's code 'only' deals with the plist itself ... <paroneayea>property lists are used by more than just symbols <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 <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>it's good naming, just maybe doesn't match everything else <paroneayea>so if those are traditional plist names, sounds good to me <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>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>a more useful thing would be to have one that appends and de-duplicates I guess. <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>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
<daviid>paroneayea: it's been nice and useful to review this with you, thanks! <paroneayea>the current code doesn't do checking and it's fine <daviid>paroneayea: but if we remove plist-add, it becomes impossible to duplicate, which I'm in fvor <paroneayea>daviid: maybe better to name plist-add as plist-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>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>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/config.scm.in <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: did you read the small documentation I made? <amz3`>catonano: what do you think I should add? <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 <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 <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 <amz3`>catonano: you said I did a really good ob on documentation <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 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! <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`>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`>maybe that's what is called unhygenic <amz3`>how do you think your constraint extension to minikanren can be helpful to query something like conceptnet.io? <catonano>amz3`: I didn't mean that particular query. I meant guile-wiredtiger. Doesn't it work on wiredtiger 2.9.0 already ? <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 conceptnet.io? <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 ? <amz3`>catonano: yes, nanoblog is based on the previous version of guile-wiredtiger <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 <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`>I want to build something useful <amz3`>nanoblog is just goofing around <catonano>Look I'm a bit distracted now, I'll take my time to think abouut this stufff ***karswell` is now known as karswell
<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.