<anadon>Is there syntax associated with making hash tables so that when you define a variable to be a hash table that you also define some contents of that hash table rather than populating it later? <RhodiumToad>anadon: builtin hashtables ot srfi-69 or something else? <RhodiumToad>alextee[m]: your lambda is returning undefined if the (when) condition is not satisfied, I think? <RhodiumToad>alextee[m]: if you just don't want to add such cases to the list, then return the accumulator unchanged <alextee[m]>i did (if ...) and returned the accumulator in the else statement <RhodiumToad>anadon: actually I think both builtin and srfi-69 have an alist->hash_table function <alextee[m]>the previous car/cdr thing looked a lot cooler though <ArneBab>manumanumanu: a lessons-learned piece would be awesome! <ArneBab>I think that’s something we’re still lacking. <alextee[m]>how do you join paths with guile? searching doesn't bring up many useful results <alextee[m]>i see a file-name-separator but there's gotta be a (join-path ...) somewhere <ArneBab>It’s not obvious how much speen in Guile can be improved if you know how. <RhodiumToad>alextee[m]: I don't see a better way than using string-join <RhodiumToad>(define (join-path . args) (string-join args file-name-separator-string)) ;; or something like that <alextee[m]>im surprised there's no built in way though, there probably is <alextee[m]>where file-name-sep-char is defined as (string-ref file-name-separator-string 0) <RhodiumToad>there's (basename) and (dirname) in the posix lib, but I didn't see anything for constructing paths <RhodiumToad>which I guess is probably always going to be true, but still... <alextee[m]>i want it to remove any trailing <separator>s from each previous string when appending a <separator> and a new string <alextee[m]>so it still works if you join /usr/something/ with /something-else/ <alextee[m]>basically, it must always have 1 separator only when joining strings, so it should take care to remove any extra ones in-between the joining <alextee[m]>also, are there some helper functions for invoking commands or checking if a program exists, other than using (system) or (system*)? <alextee[m]>python has shutil.which() for example, but im not sure if that's exactly equivalent to (system* "which" <program>) <alextee[m]>(eq? (system* "which" <program>) 0) ;; like this maybe <RhodiumToad>hm. predicting whether a new copy of a string will be allocated is not simple <alextee[m]>RhodiumToad: there shouldn't be any, but if there are just skip them i guess ***jonsger1 is now known as jonsger
<RhodiumToad>(my version is based on the idea that it's better to consume a few pairs than to allocate multiple strings) <RhodiumToad>mine may still end up allocating intermediate strings depending on whether the input strings have mutable buffers or not <chrislck>alextee[m]: it's about minimising the number of internal string-copy loops... <rekado>alextee[m]: when using a fold you should not use set!; instead you can just return the new accumulator. <rekado>next I’d look into reducing the number of string-appends <rekado>(string-append "" x) is effectively just x <rekado>you seem to be doing two things here: 1) trimming off “/” from the individual file name components, and 2) joining them to one string <rekado>you can do these two things separately: 1) in a map, and 2) with string-join <rekado>you don’t need to trim the accumulator (the resulting string in progress) if you have previously trimmed the individual components. <rekado>your getenv-or-default calls getenv twice. You can use “or” to avoid this: (or (getenv name) default) <rekado>in “program-found?” you can use “zero?” instead of “eq? 0” <alextee[m]>working on interfacing my C structs to guile now, i managed to expose a couple of functions and to create a foreign object, but im not sure how to access its members once i have the object <rekado>I’m not very familiar with this, but I think you would use pointers <alextee[m]>pointers in guile? i'm trying to access things inside "mypos" for example <alextee[m]>str1ngs: the manual says they're gonna be deprecated <str1ngs>that makes sense. now that I think about it. <rekado>alextee[m]: also 6.21.5.4 Foreign Structs <alextee[m]>apparently it's a struct and a foreign object because (struct? mypos) returns true although i created a foreign object in C <alextee[m]>apparently what im looking for is (struct-ref ) but that gives me an error ***wxie1 is now known as wxie
<lampilelo>are the bindings in guile3.0-gnutls not thread-safe? when I switched from guile 2 to 3 it started throwing handshake errors on concurrent calls to http-get: (#<gnutls-error-enum Decryption has failed.> handshake) ***apteryx_ is now known as apteryx
<alextee[m]>running `C:\\tools\\msys64\\usr\\bin/guile.EXE C:/Users/travis/build/zrythm/zrythm/scripts/meson_post_install.scm` makes guile prepend the local path for some reason <alextee[m]>In procedure stat: No such file or directory: "/c/Users/travis/build/zrythm/zrythm/build/C:/Users/travis/build/zrythm/zrythm/scripts/meson_post_install.scm" <manumanumanu>ArneBab: The difference there is because andy does no copying of strings, and builds a string using with-output-to-string. That will lead to exponentially better performance the longer the string and the more matches you find <manumanumanu>ArneBab: I am doing some tests to see if a KMP string search in guile is faster than the naive search in string-contains. <manumanumanu>I believe SRFI-13 has a KMP search with access to restart vectors and such. if so, the procedure you linked to can be made even faster <manumanumanu>SRFI-13 is MIT-licensed, and if the kmp search is actually useful, it could be included in string-fun. I doubt it will be even close for shorter strings, but maybe for longer ones with many patterns. <manumanumanu>for the "replace substrings (plural)" one could just re-use the restart vector, which is what makes re-use of kmp-enabled string-contains expensive. <manumanumanu>it is about as fast for 7kb of text the pattern "krigsmetaforer" which occurs towards the end of the text. This is comparing C code (for guile native string-contains) and scheme code (srfi-13 string-contains). <RhodiumToad>rekado: your ideas about alextee[m]'s question look similar to mine? did you look at my version of join-path? *spk121 ponders how to connect guile-cairo to guile-gi *janneke sadly hasn't played with guile-gi and guimax for almost a year... <manumanumanu>So: I have just spent 25 minutes testing out KMP string searching and naive string searching and the KMP string search fails to beat even a naive scheme string search. Has modern processors made KMP obsolete? I used a pattern that wasn't even close to bad for KMP, and it still lost to a scheme string-contains (that wasn't even noticeably slower than the built-in guile one!) <manumanumanu>Chicken went with a naive search by commenting out the KMP one in srfi-13, and using Olin's naive one. Racket has a kmp-based search. <manumanumanu>the racket one is trivial to port. Will try that one next :D <jcowan>manumanumanu: I recommend SRFI 135,which adaptively uses naive, BMH, or Rabin-Karp <jcowan>the only issue is that texts are not strings, but if you just want containment, a global search and replace should deal with that *jcowan should update SRFI 152 to use that instead of KMP <jcowan>Texts are really lovely: high performance, O(1) reference, modern algorithms <jcowan>The only problem with texts is that they aren't strings (though the text API accepts strings), thos <rekado>RhodiumToad: yes, I just wanted to show how to get there ***wxie1 is now known as wxie
<janneke>/gnu/store/ng1ibixsaggc7swvbfg6v3084xqw509i-guile-3.0.1/bin/guile -c '(display (uname))' <janneke>#(GNU debian 0.9 GNU-Mach 1.8+git20191117-486/Hurd-0.9 i686-AT386) <janneke>finally, got guile-3 built on the hurd <janneke>the test suite is still hangs at several tests, so more work todo <spk121>janneke: neat. (I wonder if I still have a hurd VM someplace) <janneke>it looks nice: janneke@debian:~/src/guix$ /gnu/store/ng1ibixsaggc7swvbfg6v3084xqw509i-guile-3.0.1/bin/guile -c '(display %host-type)' *janneke hopes while unknown, it's still a friendly gnu <janneke>still need ~10 pretty hack'y patches in guix, but oh well, that's just some work <civodul>hacky package portability patches are OK IMO <janneke>okay -- i had a patch that comments-out three tests for guile-2, now disabled them all; i'd like to be a bit more specific i think <janneke>anyway, now just keep taking small steps <str1ngs>spk121: regards getting guile-cairo to work. <str1ngs>spk121: you can use the draw event with a GtkDrawingArea to test. <str1ngs>spk121: if that works for you, i'll email the patch to guile-users. maybe wingo can review it. <jcowan>A workaround is to parse the answer out of what program-arguments-alist returns. <jcowan>I don't know if this bug persists in Guile 3 ***hugh_marera_ is now known as hugh_marera
<mwette>jcowan: program-arities not defined after loading (system vm program) in 3.0.2 <alextee[m]>Wrong type (expecting position): #<position 7f4f6e6058d0> <alextee[m]>that is an object returned by C using: scm_make_foreign_object_1() <alextee[m]>and it fails when i pass it to another function i exposed when I do: scm_assert_foreign_object_type() <alextee[m]>oh it worked now nvm, apparently you're only supposed to use 1 object type created wtih scm_make_foreign_object_type() and keep it around <rlb>Not sure it would be advisable to add it, but today I could have used a scm_take_size_t_vector() (just an alias to the appropriate u32, etc. version). <manumanumanu>civodul: regarding my patch to fix sxml handling of CDATA: oleg just applied that patch, but it will take him some time to migrate the old SourceForge account from CVS. He posted the updated versions on his webpage. I'll check whether there are any other changes except what I did and make a new patch if that is the case <alextee[m]>when i want to return a bunch of items, i should be returning a list and not an array/vector, right? i don't really understand the use-case of arrays/vectors when you have lists <rlb>alextee[m]: it depends? i.e. i.e. if the callers need better memory efficiency, and constant time lookups, then a vector would be preferable, and if all the items are the "same" a srfi-4 homogeneous vector better still. <rlb>But of course in some contexts, the callers would be wanting/expecting a list (to past too map, or fold, or...). <seepel>rlb: How would you decide when to use values vs returning a structure? <rlb>seepel: you mean values as in multiple values, i.e. (values ...)? <rlb>I suppose some of it's an aesthetic judgement, though there are also efficiency arguments in the limiting cases? I think guile might be able to avoid allocation for small numbers of (values ...) in some cases... <rlb>But unless you're in a performance critical region, that's likely not the key concern. <alextee[m]>rlb: thanks. i'm just exposing some of my program internals for easy scripting for non-programming users so i guess i'll use lists then, they seem to be the simplest. memory is not a problem at all, i expect my program to hog lots of memory anyway (it's music production software) :D <seepel>rlb: Thanks, so in the general case (values ...) would be performance-wise about the same as returning a list in guile? <rlb>Can also use alists for smallish cases where you might otherwise use a hash table (or nested hash tables). fwiw, I tend to use hash-tables (maps) a lot (and it's very idomatic there) working in clojure. <rlb>Though there there are a lot more convenience facilities (destructuring, etc.) for maps that tend to shove you that direction. <rlb>seepel: well I think (values ...) may be roughly "no cost" as opposed to "some cost" for building and then rummaging around in the list, but in the common case it likely won't matter at all. <rlb>alextee[m]: alists are also nice in that they read/write trivially. <manumanumanu>i suspect the case is that when the caller and callee is known, (values ...) will always be faster <jcowan>I'm trying to put together a package to use alists as fake hash tables, with update by pushing on the alist and delete not allowed. <jcowan>What should an a-list walker like map or filter do when it hits a duplicate key? <rlb>(for config-ish data -- that or just plain lists of lists -- you can use assoc/ref etc without using dotted forms if you prefer the "nicer" output for a config file, you'll just need an extra car to get the values, etc.), e.g. (car (assoc-ref '((some thing) (another other)) 'some)) <jcowan>To detect dups requires O(n) time, which feels awful.\ <jcowan>So my inclination is to have it carry on regardless <jcowan>and just eat the fact that you may get the same key more than once. <manumanumanu>I can't remember. The whole process ended up with me discovering HAMTs <alextee[m]>btw, is there some form of documentation generator from the stuff exposed through C? <rlb>alextee[m]: not sure I understand the question. <alextee[m]>let's say i expose a few modules like (zrythm audio position) (zrythm audio track) etc.. and some functions like (make-position ...) (print-position ...) <alextee[m]>i want to create documentation about all of these exposed symbols automatically <rlb>And you can see a lot of other examples in guile's libguile/*.c files, i.e. strings.c, etc. <manumanumanu>jcowan: The textual searching actually manages to be faster than guile's naive search! The scheme is beating C :D <rlb>One thing that page doesn't mention is that if you're using automake, you'll also need to add a "BUILT_SOURCES = .../foo.x" for all the .x files to avoid a circular dependency. <alextee[m]>eh, i don't suppose anyone used this with meson yet.... i'll need to figure it out <rlb>The tricky bit there is just that the .c file #includes the .x file but the .x file is generated from the .c file, so "someone has to go first". <rlb>So you just need to run the snarfer the first time unconditionally. <rlb>likely won't be hard from meson, and it's not hard from automake once you actually remember that's what BUILT_SOURCES is for (I didn't for a bit...). <alextee[m]>yeah doesn't sound that hard. i'll do it now actually <jcowan>Which of the 3 kernels did you use? <manumanumanu>jcowan: I just ported the search algorithm to use guile-native strings <manumanumanu>But I wonder if the rabin-karp algorithm is ever worth it <manumanumanu>I might just factor out the boyer-moore-horspool algorithm and change the API a little (ie: allow for a pre-computed table) <manumanumanu>yup, but I can't get it to be faster than guile's naive search even when trying :D <manumanumanu>but I can't really say I can really wrap my head around that. I suspect will has a better idea about these things than I :D For most of the time I couldn't even maake the rabin-karp case trigger... <jcowan>Try 100 MB of text or somethiung' <rlb>manumanumanu: happen to know offhand how srfi-135 makes textual-ref O(1) in general, say for the "utf-8" example kernel? <rlb>hah, ok. Sleep well. <civodul>manumanumanu: sure, please send a link when Oleg has uploaded something <civodul>or a patch that just incorporates that into our copy <manumanumanu>rlb: so, that would be "o(1) ish" if most of the text is us-ascii. <rlb>Ahh, ok -- that makes sense. When they said O(1) I'd imagined at worst a parallel "index array", but of course chunking makes it a lot more memory efficient without too much extra computational cost... <manumanumanu>rlb: but check out what pypy does. It has some kind of index structure for utf8 strings <rlb>(parallel index array of all indexes) <jcowan>rlb: The utf8 kernel is only meant to be used in interpreters when using the built-in string-ref is faster than writing similar code in Scheme <jcowan>oh, sorry, that's kernel0 I'm talking about. <jcowan>Yes, "O(1)" does not mean constant, and SRFI 135 exploits that