<sneek>I think I remember dsmith-work in #guile 53 minutes and 30 seconds ago, saying: Always another bug!. <ArneBab>dsmith-work: do you mean the one-page sxml template or in general the code with fewer parens? <roelj>dsmith-work: Yes that's it! I was using Guile 3.0.2, and with 3.0.4 it should the function names! Thanks once again! <dsmith>ArneBab: Just the lack of parens in general. <dsmith>When a function is long, it's hard for me to see what pieces line up with what based on indentation alone. <dsmith>ArneBab: Not saying it's bad or people shouldn't use it. Just not for me. <dadinn>is there something of a hash-set in guile? <dadinn>I cannot find anything like that, so I am thinking of using a hashtable... but then there is no method to get the list of keys :/ <dadinn>can I map car over it? that assumes the hashset can be taken as a sequences of key-value pairs... which I am worried will not be true :/ ***catonano_ is now known as catonano
<dadinn>daviid: yes, but that is not a Hash Set, I am particularily looking for unique values in a list <dadinn>also, with thy let typo fixed in my example, it is still a problem that `(hash-table->list car list)` doesn't work, because car doesn't seem like the right way to access the key :/ <dadinn>whatever, it is called hash-map->list <dadinn>I mean it should be better called unique... cuz it just returns a unique list as result <daviid>dadinn: why don't you just parse the content-list instead <dadinn>also, since it is a hash-table, it obviously can have a problem with collisions :/ <dadinn>daviid: I parse the content list <dadinn>daviid: what do you mean just parse the content-list? <daviid>dadinn: you are, it seems, thowing away the hash table, you may as well just call map and a hash function over content-list <dadinn>daviid: I don't understand the map and hash function part... can you give an example? <dadinn>daviid: that would mean i would get a list of hashes/integers, the same number as the content-list was (assuming hash-proc returns an integer) <daviid>yes, but you don't need to build and throw away a hash table to solve that problem ... if the set of key is what you want ... <dadinn>davidl: it is the set of keys is all I need, I should call the fuction unique, or uniq <dadinn>the problem is if there is hash collisions, I won't save the different values which clash hashes at the moment, so I would need to use a multi-map for that <dadinn>or is it a problem? I am not sure how hash-table is implemented :/ <dadinn>if the hash of two keys are equal, does the later key overwrite the earlier? <daviid>hash collisions occur if you have duplicates in your content-list, so you may either filter before, while building or after ... <dadinn>daviid: the problem with collision is that if two non-equal values have the same hash... two equal values should always have the same hash ***sneek_ is now known as sneek
<daviid>dadinn: all i was saying is in yur paste, yu throw away the hash table, and therfore you may as well not even build one, just call hash functions and filter forduplicates ... <dadinn>daviid: how do you filter for duplicates? is there a function for that? That's exactly the same I am trying to achieve with putting stuff into a hash-set-like thing <daviid>dadinn: in yu paste, you only return the keys right? <dadinn>daviid: and even if there is a function like that, how does it address the case when there are two non-equal values which happen to have the same hash? <dadinn>daviid: yes, I only return the keys, now I am trying to update it a bit so I will use a multi-map to protect against hash collisions, becaus I am not sure how hash-table works <dadinn>daviid: for example I don't know what hash function hash-table uses, and how to find to example non-equal keys which have collisions to test this <dadinn>if I do a naive list-input list-output based implentation where I put items from the input list to the output list, comparing the new input is not in the output list, that's an O(n^2) complexity... that's why I need a hash-table /hash-set <dadinn>daviid: naah, I can't get around the problem of hash collisions, or maybe I am misguided with the entire issue... drank too much beers tonight, going to bed! ;D <thchr>Quick question: sometimes I see the notation (+1 i) instead of (+ 1 i) - is there a difference? <mwette>1+ is a procedure: (define (1+ x) (+ 1 x)) <thchr>Hmm, I don't get it; if I type (1+ 2) at the guile repl, 3 is returned? I encountered the (1+ x) notation in a (do ..) loop construct? <mwette>just type 1+ at the guile prompt <mwette>Try to type (define (xx i) (1+ i)), then type (xx 2) and you get 3 <thchr>Ah, I get it now: nice! Thanks for explaining this! <daviid>ZombieChicken: if it exists, it's likely reported there ^ <leoprikler>dadinn: For the record, SRFI-1 has delete-duplicates and lset-* procedures so you can treat lists as sets <leoprikler>it doesn't come with the "hash" part, so asymptotically performance will be worse, but it should do the job ***sputny1 is now known as sputny
***rekado_ is now known as rekado
<chrislck>silly question: how do hash-set! and friends handle hash collisions? <dsmith-work>chrislck: Looks like (from hashtab.c) that a hash table is a vector of a-lists. The lists have (key . value) pairs. <dsmith-work>So I would imagine two keys that hash to the same value are on one of those a-lists. <thchr>Another question: trying to benchmark a method, I encountered a strange disparity between manually pasting code in the Guile REPL and `include`ing it. E.g., on 2.2, this code (https://gist.github.com/thchr/3e046aa33b5597756a99b3c772bb90b5). If I `include` the file (or run it as `guile filename.scm` from bash) performance is 5-10 times slower than <thchr>if I launch the REPL and then manually paste the contents of the file. What is happening here? <thchr>On 1.8, the difference seems to be about a factor of 2. <thchr>I guess I will then; I'm on an older Ubuntu though, so I have to compile from source then - I guess I should... <thchr>On my laptop, it's on the order of 2e-5 seconds on v2.2 <RhodiumToad>ah, the output here is wrong because you're not accounting for internal-time-units-per-second <RhodiumToad>so correcting for that, I get ~2.8e-5 s on 2.2.7, and ~1.7e-5 s on 3.0.4 <thchr>Ah, OK - didn't know that command <RhodiumToad>(you seem to be assuming that's 100, on my system it's 1e9) <thchr>(It was 1e9 on one of my systems as well, yeah) ***rgherdt_ is now known as rgherdt
***karlosz_ is now known as karlosz
***roptat_ is now known as roptat
<ATuin>how can i read the output of the pipe? <ATuin>that code seems to hang on the child process <ATuin>when using `open-output-pipe` I can see the output of `wc` in the console <ATuin>removing the format didn't help <ATuin>i guess i'm using the port wrongly but I can not see why o how <dsmith-work>(I always get confused on what is an "in" and and "out", depends on perspective) <dsmith-work>So if you want to write to it, you need an output-pipe. If you want to read from it, an input-pipe. <ATuin>then how do i use that function <ATuin>it opens the pipe in both modes according to the doc <ATuin>Care should be taken with OPEN_BOTH, a deadlock will occur if both parent and child are writing, and waiting until the write completes before doing any reading. <ATuin>they comment that in the doc <ATuin>maybe i'm reaching that case <ATuin>a funny fact is that when the child is rofi, stumpwm hangs completely until I kill the process :D <dsmith-work>So it may be that buffereing is involved. Maybe a flush after your display. <ATuin>I thought the same so I tried to flush the port and even remove the buffer but nothing <ATuin>yeah closing it makes the read to fail later <ATuin>I also think it's something related to buffering <ATuin>could it be that the child is waiting for more input so the read is hanging <ATuin>so maybe the problem is the write procedure <dsmith-work>Yes, that's why closing the pipe to "wc" would be good, but that also ends up closing the pipe FROM "wc" <dsmith-work>ATuin: istr something like this on the mailing lists a few months ago. <ATuin>mmm don't know i can check it <ATuin>i guess i can always fork manually and dup the fds but i'm curious why is not working because that procedure looks very conveniant <dsmith-work>Is there a way to make "wc" line buffered? I would think it must read it's total input until EOF before producing any output. <ATuin>yes, seems that's the problem <thchr>RhodiumToad Just to update on my previous conundrum: I found that the problem didn't exist on Guile 2.0 nor on Guile 3.0.4. Somewhat hilariously, I also found that the problem went away if I called guile-2.2 from sudo; somehow it seems auto-compilation wasn't happening, I think. <ATuin>this wc example was just to test it <ATuin>the original problem came from piping into `rofi` ***karlosz_ is now known as karlosz
<ATuin>ahh it's similar to call-with-values <dsmith-work>Basically just the example in the manual modified a bit. <dsmith-work>pipeline separates out the in and out pipes so you can close them independently. <ATuin>I will try with the original problem (rofi) <ATuin>yeah but in this case i wont read until the the other side is closed <dsmith-work>reading from the pipe, with the pipe blocked on a read, which you can never send. <ATuin>interesting I dont have that procedure in this version of guile <ATuin>yeah, it was introduced in 3.0.3 :D <manumanumanu>ATuin: open-input-pipe was changed in 3.0.3 to allow for the open-pipeline (????) procedure that opens a pipeline like a shell | pipe. I didn't read your discussion, but from what i glanced through it seems like a regression <ATuin>the problem is that only got 1 pipe and the child was waiting for more input so my read was blocking <manumanumanu>ATuin: oh, you could use (@@ (ice-9 popen) open-process) to get 2 separate ports. That way you could close the one you write to close stdin for the process <manumanumanu>I should really submit some kind of patch to put that stuff in the manual!