***daviid` is now known as daviid
*daviid - testing my nick ***nikita is now known as Guest87463
***dsmith`` is now known as dsmith
<pinoaffe>d4ryus: aight, I was referring to srfi-19 dates which are indeed printed with #<...>, thanks for the info! <daviid>str1ngs: I just pushed a series of patches to support the (c -1 #f 0 utf8) and (c -1 #f 0 filename) array types. It is not yet sufficient to properly handle gtk-init, clutter-init ... becaue these are argc and argv 'inout arguments, and there is something missing in g-golf wrt to the 'inout args still. However, the g-application-run you are using, from GIO, argc and argv are 'in arguments, and that should work now: would like to try? <daviid>but i tried it without arguments, jst running './open.scm' in a termnal <str1ngs>sneek: later tell daviid great news and excellent timing. I will look at this ASAP. <str1ngs>sneek: later tell daviid looks good so far. just to clarify #:flags '(handles-open can-override-app-id) is known to not work right? also for the language binding does it make more sense to have drop argc? seems redundant for people to use and might be a source of gotcha for non C programmers. just a thought. also passing the wrong value to argc can cause a seg faults. WDTY? for now this signature is okay if it means to much work. <str1ngs>sneek: later tell daviid what I'm proposing is something like this. (g-application-run (command-line)) the length is implied. <str1ngs>sneek: later tell daviid (g-application-run app (command-line)) ** to be more precise. <str1ngs>ZombieChicken: there are still some C bits for the web extension which can't be helped. and a few functions for minor interoperability which will be replaced by g-golf as well. <str1ngs>ZombieChicken: about 98% is now guile scheme though. <str1ngs>this based on the feature-g-golf development branch. <str1ngs>guile and g-golf is fine. it's that the webkit process loads dynamic libraries for web extentions. not the same things as a browser plugin <str1ngs>this is used to communicate between the web process and the webview <str1ngs>it's currently not used. but it might be useful for some more advanced features like DOM introspcetion. <str1ngs>ZombieChicken: nomad is still alpha, but if you are looking to play around I suggeest the feature-g-golf or feature-window branch. <ZombieChicken>str1ngs: Actually I was looking for FFI bindings. I've been wanting to cobble together a browser myself. <ZombieChicken>from what I've seen, nomad is a bit heavier than I'm interested in <str1ngs>understandable. but I would use a guild extention over FFI or g-golf atleast. FFI would be tedious <ZombieChicken>Right now I'm looking at doing things backwards; embedding a scheme into surf <str1ngs>that kinda defeats the state machine aspect :) <ZombieChicken>because yeah, 150ish lines in in FFI bindings and I just don't want to touch it any more <ZombieChicken>str1ngs: I think nomad's goals are different than my own; I want something small and lightweight that can be extended. <str1ngs>but nomad started out the same way. I just wanted something I could extend with scheme. and I've been having a blast since. :) <ZombieChicken>yeah. It's a good time for another browser; imo, Firefox is getting to the point it's almost unusable <str1ngs>I have some longer term goal. but I'm still making sure the core api is solid. things like gnunet and ipfs support etc. <ZombieChicken>yeah, I have a nearly different goal; something as minimal as possible (give-or-take). A building block, if you will <str1ngs>surf is probably C knowing suckless? <str1ngs>you might need to hook into surfs signals glibs then. do you plan on using guile? <ZombieChicken>though I might change to Guile at some point. Honestly not sure atm <str1ngs>I"m not sure how to do this with chicken. but with guile you could use scm_boot_guile <str1ngs>you'd have to patch surf for sure. which is pretty normal for suckless anyways <ZombieChicken>Oh yeah. Only reason to use anything from suckless is to make something useful out of it <str1ngs>ZombieChicken: most of the g-import just improves load times. just boiler plate <wingo>yeah i was going to reply last night and had to go; i think i agree though it is an incompatible change, given that hashes leak to our ABI <wingo>but still, sure, makes sense, and we should check all other tc7's to see if similar things need to happen for other types <civodul>wingo: i wondered about the ABI breakage but thought the problem is bad enough that we'd rather fix it <civodul>i've sent a reply, and there's quite a few other tc7's not correctly handled, oops <wingo>civodul: yeah my thoughts were the same <wingo>3.0.0 is very fresh and maybe people will understand <wingo>"interface stability is an artifact of culture" and all that ;) <rlb>wingo, civodul: hmm, I hadn't thought about the possibility of the specific hash *values* as being part of the ABI. Or at least I suppose I might have thought we could plausibly claim that the A*P*I promise is that hash values won't generally collide, and so this would be a bugfix... <rlb>wingo, civodul: and did you want me to just push that as is (to both branches -- or maybe we want to be more conservative with 2.2 given the ABI concern), or did you want me try to fix the other cases too, first? <sirgazil>Do you know if there is a procedure to remove a directory and its content? (something like "rm -rf") <civodul>rlb: i thought you could push as-is to master (and not stable-2.2) <civodul>sirgazil: there's delete-file-recursively in (guix build utils) <rlb>civodul: ok, though I'd really like properly hashable keywrds in 2.2 as well if that's remotely feasible, since it's terrible (I assume) for anything hash-table keyword key heavy. In any case, I'll push to 3.0 later (tonight, likely), and thanks. <civodul>rlb: yep; for 2.2, let's see what wingo thinks