***sneek_ is now known as sneek
<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 <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? <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. <pancak3>dsmith-work: but help is unbound :'( <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: 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 <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. <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 <str1ngs>but this assumes you have a really good use case :P <dsmith-work>From within guile, your are prob just going to have to read/scan the directory and find the match(es) you want. <RhodiumToad>see also file-system-fold in ice-9 ftw for another method <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>$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))) <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? <pancak3>thanks so much! You guys are very helpful :D <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 <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? <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? <dsmith-work>civodul: "port-column, port-line and their setters are *documented* in (ice-9 textual-ports)" <civodul>well in the manual it makes sense to have them under that section <civodul>but indeed, they're in the global environment <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 :-)