<ruffni>how can i extend a list with all the elements of another list? (list 'a 'b) (list 'c 'd) -> (list 'a 'b 'c 'd) ? <rlb>Oh, no, typo here, append it is. <mwette>abcd: When I worked to get guile2.2 (?) to compile under FreeBSD the builtin make would not work. <ruffni>why is guile scripting not supported by my gdb? GDB 8.3.1 <rlb>ruffni: why do you think it's not? Could it just be that your build didn't enable it? <rlb>Guile scripting is not supported in this copy of GDB. <ruffni>it's totally possible. i got it from debian testing repos. do i have to build it myself? <rlb>I don't see a debian " <rlb>gdb-guile" package, so maybe? <rlb>(like we have wrt make-guile...) <seepel2>oni-on-ion: I am not but would love to try it out! It crashes on start for me and I haven't yet had the time to dig in more <rlb>ruffni: looks like you might be able to "apt-get source gdb" then (as root) "apt build-dep gdb" and then edit debian/rules in the gdb dir to change --without-guile to --with-guile, and then "fakeroot debian/rules binary" to make your own packages. Of course you'll also have to install a guile-X.Y-dev that gdb recognizes (not sure which, likely 2.2, at least). <ruffni>so your goto debugger isn't gdb? or am i mixing things up here..? <seepel>oni-on-ion: I've been using i3, but would love to use guile for scripting instead <brendyyn>sway is in C. maybe extend it with guile? <brendyyn>i realised yesterday you can move tiled with me mouse *brendyyn can't english while tired. *oni-on-ion has no mouse atm ***jao is now known as Guest98886
***jao- is now known as jao
<tohoyn>daviid: it seems that many GValue-related procedures get overloaded. I have to use @@ to access the correct versions in (g-golf gobject). <tohoyn>daviid: I'm trying to implement GValue argument support in hl-api/function.scm <tohoyn>daviid: if I use the default GValue procedures there I get infinite loop <daviid>I don't understand this way of expressing things, 'overloaded', I am sorry but <daviid>you should not even have to use any of those procedures, their for developers <daviid>function uses giarguments, not gvalues <tohoyn>daviid: I'm implementing the case where a function needs a GValue argument <tohoyn>daviid: I actually convert Scheme types to GValues <tohoyn>daviid: this is needed e.g. in gtk-list-store-set-value <tohoyn>daviid: it does not work in the current release of G-Golf <daviid>ok, i'm pleased to improve the situation of course, but i'd like you to send me a snipset that i can use to spot and reproduce the problem, then i can fix it ... <daviid>as i said, there are many things to do stll <daviid>i don't want a patch, i need to think about how i want to fix this 'problem' you spot first ... <daviid>and that module needs another fix, which i am thinking still how to best address the problem ... <tohoyn>daviid: ok. I'll send you an example program. <tohoyn>daviid: I also fixed the case where a procedure needs an Gtk Interface argument <tohoyn>daviid: and implemented GType array as an argument <daviid>the smalest possible code snipset that allows to see the 'missing ' ... <daviid>that was supposed to be fixed already <daviid>actually fixed in the context of closures and signals, i was going to iplement the 'similar' fix for gi-arguments <daviid>tohoyn: it looks like i cn use the example to spot 'problems' and think about how i want to improve the situation, tx. but riht now, i'am on somethig else, so please be a little patient .. and rmember, thought it's getting better everydy, g-golf is still experimental <daviid>but here is what i can say just loking at the example: (-) it would be nice to only import what the example requires, if you manage to do that, paste it here, i'm using an old computer, and importing gtk takes a couple of secnds here .. <daviid>we shold be able to call gtk-list-store-new passing th list of fundmental types <daviid>we should be able to pass the list of fundmental type symbols, you shoudl'nt have to call symbol->g-type 'yourself', i gess you did that because something is missing in g-golf, i'll look into this of course <daviid>you should never (have to) call g-value-set!/ref yourself, which sounds like also something was missig for you to work 'properly <tohoyn>daviid: I suspect that the g-value-related procedure in subdirectory gobject get redefined somewhere <tohoyn>daviid: and the new procedures don't work correctly <tohoyn>daviid: I'll fix the example for imports <daviid>tohoyn: probably, it's another important thing i need to fix, not to let g-golf import things that are manally defined - it's a bootstrap problem, in order to write a GI binding, we need a minimal set of glib, gobject 'things' to be defined, then it tries to reimport those but it shouldn't ... <tohoyn>daviid: the gvalue struct is defined to have field types unsigned-long, double, and double. I think that having type double here is not good when these kind of structs are parsed or created in bytevector level. <tohoyn>daviid: I think that double should be replaced by some integer type. <weinholt>rotty, a workaround might be to close the port after writing to it (assuming the interaction is a single write followed by a read). to fix it properly, i would look at how the close-port procedure flushes the output (assuming that it isn't buggy as well) <rotty>weinholt: that workaround is not an option for dorodango; looking at `close-port` more closely (heh!) is a good idea -- thanks <daviid>tohoyn: you shouldn't even try to set! nor ref a g-value 'yourself, less try to parse its struct content, why are you ding this <tohoyn>daviid: parsing the structs didn't work for GValue <daviid>tohoyn: but you shouldn't do that <daviid>tohoyn: anyway, i see this 're-importing already defined gobject -things-, gvalue and its methods, must be blocked before we can even go further <brendyyn>I ran file-system-tree on a directory with symlinked directories., but it does not show the contents of them. the wiki says the default enter? will traverse everything <heisenberg-25>does the scheme pattern matcher ignore whitespaces or newlines? <manumanumanu>heisenberg-25: yes. Not the literal char #\newline, though :D <heisenberg-25>is there a way to make the pattern matcher not match whitespace? <manumanumanu>it does not? Show me an example of what you would like it to do. ***jonsger1 is now known as jonsger
***ng0 is now known as nikita`
***jonsger1 is now known as jonsger
<manumanumanu>heisenberg-25: then you will have to match on the result of the procedure ListLink <heisenberg-25>it is a scheme binding for an underlying c++ class that holds objects. <heisenberg-25>actually my question should have been how would I pass a quoted input to this function when it is called from another function? <manumanumanu>heisenberg-25: wrap it in a srfi-9 record and you can match against that. <ArneBab>I tried to find a replacement for hashmap that plays well with fold. Vhashes sound good, but I can’t get only the newest values. Is there a set-datastructure with O(1) membership test that I missed? <RhodiumToad>you want fast membership tests and iteration in reverse order of insertion? <ArneBab>the latter would be ideal, yes. But only the newest values. <ArneBab>or rather: What I want is a way to aggregate on keys <civodul>ArneBab: what do you mean by "newest values"? <civodul>(vhash-assoc 'a (vhash-cons 'a 2 (vhash-cons 'a 1 vlist-null))) <ArneBab>what I need is folding over all vhash keys. <ArneBab>here’s my code: (fold (λ (element table) (vhash-cons (second element) (+ (third element) (cdr (or (vhash-assoc (second element) table) '(#f . 0)))) table)) (alist->vhash '()) flattened)) <civodul>yeah in this case you would see 'a twice <ArneBab>I then save as simple file: (map (λ(x) (format #t "~a ~a\n" (car x) (cdr x))) (vlist->list sum-by-date)) <ArneBab>but I only want to see each key once <ArneBab>RhodiumToad: (not having reverse order is OK, though reverse order would be optimal) <jcowan>λ is never out of place on these channels! <RhodiumToad>it looks like emacs is messing up on greek fonts :-( <jcowan>I thought Emacs finally had a good Unicode story now (I don't use it, so I don't know) <RhodiumToad>it's not unicode as such that's the problem, it's somehow selecting a bad font for output in some cases <jcowan>Ah. Perhaps switching to a monowidth full-Unicode font would help. <RhodiumToad>yeah, changing almost anything about the font choices makes it work, it's just the default one that's coming out wrong <RhodiumToad>ok. blacklisting the offending font in fontconfig seemed to be the best solution. <ArneBab>I have an inelegant way: just create a hash-map and check for membership. But … its just not nice. <civodul>ArneBab: yeah, or convert to an alist, but that's about it <civodul>note that there's vhash-fold* if you wish to iterate over all the values associated with a key <civodul>not quite what you're asking for though <manumanumanu>I don't really understand what you are trying to do, but can't you just vhash-cons into one vhash and fold over another? with fashes you can fold over one add to a transient copy of the same one. <manumanumanu>no duplicate values, and in-place updates of the new fash <manumanumanu>sourcehut does no automagically made readme.md (lowercase) the project start <manumanumanu>I am adapting andy's fectors to use rrb-trees, btw. That way we get very fast appends, splits and inserts, at the cost of an extra vector-length per tree height. <manumanumanu>one could make it a bit less space efficient, but provide amortized o(1) prepends as well (or maybe make a prepended rrb-fector a special case where the first 32 elements are in reverse order to get amortized o(1) prepend at the cost of some computation) <manumanumanu>I wish I could understand the fashes though. They are very fast, but currently lacks the ability to properly remove elements. I tried, but never managed to add it <rlb>I may propose fash-update and fash-delete at some point. I have the former, but haven't attempted the latter yet. <rlb>i.e. (fash-update fash key f . args) where it calls (apply f prev-val args) to compute the new value. <jcowan>Henry Baker has an interesting implementation of functional vectors on top of ordinary vectors plus mutable pairs. The nice thing is that if you are consistently accessing a particular state of the vector, you get O(1) ref and set, and only work hard which you switch to accessing another state. <manumanumanu>anyway, anything unless you provide split, append and insert like rrb-trees, I am pretty sure I don't want it :D :D <jcowan>Another approach would be HAMTs whose keys happen to be numeric, in which case you can insert elements between 2 and 3 by calling them #e2.1, #e2.2, etc. <rlb>Hah, oh -- well if it's close, then I probably wish I'd knew about that before I did all that work :) <rlb>"if it's even close" <jcowan>IMO a vector without fast random access doesn't count as a vector, but I certainly don't demand fast insert and delete too. <jcowan>A Dijkstra array, which is kind of the dual of a circular buffer, does have O(1) everything, which is nice, at the expense of havimng to copy it when the underlying vector gets full. <rlb>Hmm, I suppose my "ref" might be faster, depending on what wingo did -- I use a duff's device to find the right leaf in one quick fallthrough :) <jcowan>(A circular buffer of size k has two indices, i to the first cell in use and j to the last cell in use (or just past that), so the area between i and j is the content and everything below i and above j is garbage. <rlb>And _builtin_clz() to find the tree "depth" for the index. *rlb bets Andy does similar tricks -- will look later. <jcowan>In a Dijkstra array, everything below i is part of the array and everything above j is too, and between i and j is garbage. <jcowan>and there is a third index telling you where the zeroth element is. <jcowan>So ref, set, push, pop are all O(1) until the buffer is full <jcowan>also shift is O(1) because of the third index <rlb>wait, that's not the right thing. <rlb>(...and obviously not a duff's device) <ArneBab>manumanumanu, rlb: there are so many cool datastructures, but I look for something that’s included in Guile. It would be cool to have these datastructures as default part of Guile. <rlb>Agreed -- I've written my clj vectors to try to at least leave open that possibility if it ends up being of interest, but if Andy's behave even close to as well (or better) and are pure scheme, that's very likely preferable if including them is otherwise acceptable. <rlb>In the end, I'd just love to have a few more "core" persistent data structures in guile proper, e.g. perhaps at least vector, map, and set. <ArneBab>same for me — it surprised me today for the second time that we actually have serious missing pieces there <rlb>I wrote a chunk of a simple (I *think* maybe mostly standards compliant) JSON parser last night :) If I get a chance to finish it up, clean it up and add tests, I thought I might propose it for inclusion. Seems like it'd be nice if it's not much code to have at least something basic there in the core... <ArneBab>an efficient data-sharing set-implementation (thread safety would also be nice), efficient trees. Currently we mostly have list, alist, and vlist. <ArneBab>rlb: sounds good — do you know guile-json? <rlb>But whatever it is, I think it might be good to have something "built in", even if you need an external library for more sophisticated or higher performance cases. <rlb>i.e. I'm not proposing implementing/adding anything like cheshire/jackson :) <manumanumanu>jcowan: rrb-trees are a strict superset of the vectors used in clojure <civodul>rlb: davexunit (David Thompson) posted an (ice-9 json) patch to guile-devel maybe... 2 years ago? <civodul>IIRC, it was almost ready for inclusion <civodul>so perhaps we could start from there <manumanumanu>the penalty for splitting and inserting is only paid after an insert. <manumanumanu>jcowan: seriously, there are very few-reasons to use clojure's tries over rrb-trees. The only difference is that the rrb-trees contain a lookup table, but only after a split or insert has taken place. In practice, this means a vector-length check (32 = no splits, 33 = lookup table). The lookup table can be branch local, so the cost is really really low. <jcowan>I believe you. But how do they compare with the Baker and Dijkstra approaches for fixed-length vectors? <manumanumanu>I suspect indice-based access will be slower, but iterating through it from start to end (or reversed) will be only slightly slower. <manumanumanu>civodul: the json srfi is amirouches. I think the interface is actually quite good. <civodul>what have the maintainers been doin' :-) <dsmith-work>Wasting time playing with compilers and packaging... <dsmith-work>civodul: Just curious: what's the 3.0.2 timeframe looking like? <civodul>dsmith-work: i'd like to release it soonish, but i'd like to know what wingo thinks too <civodul>there are a few more bugs we could fix <civodul>on current master, JIT works on all supported platforms