IRC channel logs


back to list of logs

***sneek_ is now known as sneek
<civodul>hey there!
<civodul>how are you, wingo?
<wingo>how you? :)
<civodul>i'm fine :-)
<wingo>v little free time these days :P perhaps that will get a little better
<xelxebar>Looking for a way to detect avx/avx2. Is there a standard procedure for this? Or should I just be platform-specific and grovel around in /proc/cpuinfo?
<wingo>you have to do it at run-time; either you emit assembler that calls cpuid and reads the appropriate flags (see lightening's x86.c), or you grovel in /proc/cpuinfo
<dsmith-work>{appropriate time} Greetings, Guilers
<pancak3>How do you guys access documentation? I did ,describe copy-file in a repl and it helpfully returned '#f'
<str1ngs>pancak3: (help copy-file) is useful and (apropos "copy-file")
<str1ngs>actually (apropos "copy") is more helpful
<pancak3>help and apropos aren't bound. What module should I import?
<str1ngs>strange what version of guile are you using?
<str1ngs>does ,d copy-file work?
<str1ngs>also ,a "copy"
<pancak3>,a copy works but ,d copy-file returns #f
<str1ngs>use ,d "copy-file" but apropos works better when you give it a lest broader search so ,d "copy" for example
<dsmith-work>pancak3: Usualy read the guile manual as info from within emacs.
<dsmith-work>pancak3: But also often use (help ...) at the repl.
<pancak3>dsmith-work: but help is unbound :'(
<pancak3>str1ngs: ,d "copy-file" is also #f
<pancak3>,a help doesn't show the help function. should it?
<dsmith-work>pancak3: Hmm. Well, shows how much I've been using it lately.
<str1ngs>pancak3: does ,h a return anything?
<str1ngs>pancak3: also ,h should list meta commands.
<pancak3>maybe you guys could help me with my specific problem. I want to do (copy-file "file-*" "file") where * is a wildcard.
<str1ngs>pancak3: guile does not support wild cards.
<pancak3>ok not like a proper wild card. I have a thing that's like blah-28.0.0 and I want it to be blah
<pancak3>,h seems to work
<str1ngs>you would have to do something like (system* "cp" "file-*" "file") which is not ideal I know. I have not tested this just in theory.
<RhodiumToad>maybe scandir is what you're after?
<RhodiumToad>see ice-9 ftw
<str1ngs>can scandir support regex?
<RhodiumToad>it supports an arbitrary predicate
<str1ngs>good to know thanks.
<dsmith-work>pancak3: Are using the wildcard to select lots of file, or just because to lazy to type the full name?
<str1ngs>that would be more ideal then my system* example pancak3
<pancak3>dsmith-work: not lazy, just flexible. There will always be one file to one file copy, but the version will change over time
<dsmith-work>Yeah, that's what I meant by "lazy". ;^}
<str1ngs>I did create this witch used wordexp so it supports wildcards and word expansion.
<str1ngs>but this assumes you have a really good use case :P
<RhodiumToad>wordexp is a horrible thing that forks a shell
<dsmith-work>From within guile, your are prob just going to have to read/scan the directory and find the match(es) you want.
<str1ngs>so does system whats your point?
<RhodiumToad>see also file-system-fold in ice-9 ftw for another method
<pancak3>OH ,d scandir works!
<RhodiumToad>I find that ,d isn't working on builtins but does work on functions brought in by use-module
<pancak3>so ,d scandir gives me way to little info. How can I get more?
<pancak3>oh, actually it seems to give all the info except the arguments. I kinda want it to give me the arguments though :P
<RhodiumToad>just type scandir
<RhodiumToad>$3 = #<procedure scandir (name #:optional select? entry<?)>
<pancak3>ok ya, but shouldn't it also give me that when I do ,d scandir?
<pancak3>also I'm realizing it didn't actually give me all the info in the manual after all. It really doesn't seem that great.
<RhodiumToad>it gives you whatever is in the docstring of the function
<pancak3>ok, so this works but I want to make sure this is how I'm supposed to do it: (scandir "." (lambda (x) (string-match "emacs-" x)))
<RhodiumToad>that'll match *emacs-*
<pancak3>Thanks for pointing that out! I'll need a ^ at the beginning. I was kinda meaning the lambda thing though. That's how you do a predicate?
<RhodiumToad>string-prefix? might be of more use
<pancak3>thanks so much! You guys are very helpful :D
<pancak3>oh ya string-prefix? is helpful!
<RhodiumToad>srfi-26 lets you do (cut string-prefix? "emacs-" <>) in place of (lambda ...)
<pancak3>actually I'm going to go with (string-match "^emacs-[0-9.]*$" x) to make sure it has a version number
<pancak3>oh that cut thing is really cool. I do hesitate to add to many dependencies to stuff though. is srfi-26 pretty standard?
<RhodiumToad>haven't tried it, but maybe (cute regexp-exec (make-regexp "^emacs-[0-9.]*$") <>) avoids compiling the regexp each time.
<pancak3>this line of code should only be hit once so I don't think that would make a difference? but your thing runs with no complaints
<RhodiumToad>with string-match, you'll be compiling the regexp for each file scanned
<pancak3>oh that makes sense.
<RhodiumToad>cute (unlike cut) evaluates the args once initially and returns a closure
<pancak3>Thank you so much for your wisdom! I'm much more confident in this snippet now :D
<RhodiumToad>like doing (let ((re (make-regexp ...))) (lambda (x) (regexp-exec re x)))
<pancak3>Ok, just one more related question. How would I go about finding a directory that's something like "/foo/[0-9.]*/bar". Obviously I could just shove a scandir in the middle, but I'm wondering if there is a better way
<RhodiumToad>hm. you could split off a prefix of as many directory components as don't have wildcards, and use file-system-fold for the rest
<pancak3>how do I match a literal .? \. is apparently an invalid character in escape sequence?
<pancak3>ah, the classic \\.
<pancak3>I should've known
<dsmith-work>Does guile have a "raw" string syntax? In an srfi?
<manumanumanu>civodul: hi ludo, there is a documentation bug I want to correct, but I just want some input on what would be the preferred way to do it: port-column, port-line and their setters are documented in (ice-9 textual-ports), but are defined in the default environment. There was a reddit question regarding it, and I helped the user hunt down the issue. Should we either 1. just re-export it from (ice-9 textual-ports)
<manumanumanu>and live with the wart of having it documented in a place where it is not really defined, OR 2. deprecate it in the default environment and move it into (ice-9 textual-ports)? Number 1 is easy. Number 2 means I am in very deep water WRT to making a patch.
<manumanumanu>civodul: btw, that user was struck by the very same thing that was mentioned in bug-guile today: that the r6rs library form only imports (rnrs), and does not show any bindings from (guile). I am not a native english speaker, and if I had had that issue I don't think I would have understood what the manual says about it.
<civodul>manumanumanu: hmm i don't see port-line in (ice-9 textual-ports), am i missing something?
<civodul>you mean (ice-9 ports)?
<dsmith-work>civodul: "port-column, port-line and their setters are *documented* in (ice-9 textual-ports)"
<dsmith-work>I guess that means in the Guile manual.
<dsmith-work>In in api-io.texi: @subsection Textual I/O
<civodul>dsmith-work: ooh, i see
<civodul>well in the manual it makes sense to have them under that section
<civodul>but indeed, they're in the global environment
<civodul>(the bindings)
<stis>hey guilers!
<str1ngs>hello stis!
<jlicht>Is there any way to copy all bytes (till EOF) from an input-port to an output-port? Blocking as required for either the reading and/or writing?
<jlicht>My current (read-char) -> (display) loop seems a bit suboptimal :-)