<OrangeShark>if you are using guix, it should be included with guile <OrangeShark>but other distros would usually require you to install guile-2.0-dev or something <mark_weaver>sapientech: that indicates that guile-2.0-dev or equivalent was not installed when you ran: autoreconf -vfi <sapientech>when i do: which guile, it shows the one in guix <sapientech>but where autoconf shows /usr/bin ..., would that make autoconf use the guile in /bin ? <mark_weaver>or that ACLOCAL_PATH was not set properly to find guile.m4 <OrangeShark>ya, if it installed from guix, you will need to have the paths set for autoconf to be able to find it <sapientech>OrangeShark: ./configure: line 2354: syntax error near unexpected token `2.0' <sapientech>you guys are saying that error is due to not having dev files? <OrangeShark>sapientech: when I get home I will try and see what is wrong. Give me a bit, there is some traffic :p <daviid>sapientech: this is a very common and recurrent problem, for which I personally recommend you to 'mkdir m4' and copy the guile.m4 latest version from 2.0.12 or master [it's been patched recently]: the reason is you want to check the user has guile, and nicely report if yes or no... but if you rely on the fact he/she has guile installed, it will fail with an autool error, not good! I also recommend to use AC_CONFIG_AUX_DIR([build-aux]), <daviid>sapientech: then you need to adapt your pre-inst-env.in and Makefile.am to use @GUILE_SITE@ instead of ... <daviid>have to go afk for a while now, talk later <zv>is there any guile procedure for breaking a string upon another string? <zv>e.g string.split("substring") <sapientech>zv: so for example if string= "asubstringsundaysplit" you want ("a" "sundaysplit")? <zv>yeah, i'm tryin to make something that replaces nicks in weechat (for users of gateways) <zv>that is my existing code, and it works, but it would be cool to do it the "right" way <mark_weaver>zv: use 'make-regexp' to compile a regexp, so it won't have to compiled every time 'string-match' is called <mark_weaver>e.g. do (define *r2tg-msg-regex* (make-regexp ":(r2tg)!~.*?@\\\\S* PRIVMSG #radare :(<(.*?)>) .*")) <mark_weaver>use 'string-append' or 'string-concatenate' instead of 'string-join' with empty string joiner <zv>mark_weaver: what about structural stuff? i'm 4/5ths of the way through and i really like it but not much structural advice <mark_weaver>check out the 'regexp-substitute' procedure. might be a better way to do this. <zv>ok cool, thanks a bnch mark_weaver <zv>is stuff like "macros for the non-mentally ill" (or whatever its called) still up to date? <mark_weaver>fwiw, at some point we'll import a more modern regexp library, probably irregex or SRFI-115 <mark_weaver>I guess you're talking about Al Petrosky's "An Advanced Syntax-Rules Primer for the Mildly Insane" <mark_weaver>the macros described therein are the same syntax-rules macros available in Guile, although we also have more powerful 'syntax-case' procedural macros. <mark_weaver>also, at least some of the shortcomings described in the document have been remedied in Guile, e.g. the issue with ellipsis in macros that expand into macro definitions. <mark_weaver>Guile supports SRFI-46, which addresses that issue for syntax-rules. <mark_weaver>for 'syntax-case' macros we address the ellipsis issue with the guile-specific 'with-ellipsis' form, described in the manual. <mark_weaver>btw, although 'syntax-case' macros are more powerful and sometimes needed, I would recommend using 'syntax-rules' macros when they are sufficient. <zv>mark_weaver: any good tips or documents describing the 'better' guile macros? <mark_weaver>Chapter 12 of the R6RS-lib document is a good description of the 'syntax-case' system. <mark_weaver>note that the 'syntax-case' builds on the 'syntax-rules' system, particularly w.r.t. the pattern and template syntaxes, so I would recommend learning the 'syntax-rules' system first. <mark_weaver>note that R7RS did not adopt the 'syntax-case' system <mark_weaver>but nonetheless it is quite popular and widely supported <paroneayea>turns out monads are a lot easier for me to understand when I implement them with generic methods (!) <paroneayea>ACTION thinks of doing a blogpost building up and explaining a monad system <wilfredh>so, I've found a small typo in a code sample in the guile manual <wilfredh>is it worth me filing a bug? What's the best thing to do here? <mark_weaver>wilfredh: please email bug-guile@gnu.org about it. a proposed patch would be ideal, but it would also be fine to just point out the issue. <wilfredh>it's quite possible I'm wrong, but thought I'd mention it <wilfredh>is there a convention for docstrings in guile? I can't find any obvious examples ***mario-go` is now known as mario-goulart
<sapientech>daviid: got configure working, but a little confused where to put @GUILE_SITE@ <wingo>so what is the right way for guile to use atomic operations <wingo>how to expose them to scheme is another question of course <wingo>we could use c11, but we still need a fallback in case __STDC_NO_ATOMICS__ is defined <sapientech>mark_weaver: btw, why the choice to have two lets in your string-split example, vs using let* , just to show that only matches needs the let*? <sapientech>also, is it standard to have len and matches expressions line up? if so is there a nice little emacs module for that? <wingo>i think i will propose to have our external interface be c99 and to compile guile internally with c11 <wingo>that way we can portably use atomics internally, and we get the c99 features too <wingo>hah, it turns out we have been compiling in gnu11 mode all the time <jmd>How do I represent the newline character in guile? <jmd>alezost: Thanks. And how about an arbitrary unicode character? <alezost>jmd: I don't know, I think #\\foo should work; like (display #\\µ) <jmd>But if I cannot type it. I only know its codepoint. <alezost>jmd: there is also 'integer->char' procedure <jmd>standard input:41:10: Value out of range 0 to 255: 955 <jmd>I typed "(display (integer->char #x3bb))" and hit the return key. <alezost>I think it's a problem on your side, it should work, what about: (begin (display (integer->char 955)) (newline)) <jmd> 57: 0* (begin (display (integer->char {955})) (newline)) <jmd> 57: 1* [display ... <jmd> 57: 2* [integer->char {955}] <jmd>standard input:57:17: In procedure integer->char in expression (integer->char 955): <jmd>standard input:57:17: Value out of range 0 to 255: 955 <jmd>ABORT: (out-of-range) <wingo>jmd: i think you are on guile 1.8 <wingo>guile 1.8 does not do unicode <jmd>How would I do it if I was on 2.x ? <lloda>1st time I use git-send-email, hope it works :-O <jmd>I expected this (or #f 0) to give me an error. Why doesn't it? <jmd>Because 0 is not a boolean <lloda>in Scheme #f is false, everything else works as #t <jmd>lloda: In that case, the above expression should hae evaluated to #t <lloda>works as #t to determine if it's true or false, but it's still 0. So or checks 0 and it's 'true' and the arg list ends and it returns the last thing it had. <lloda>wrong, too, it would be the first... anyway, it's 0 here. <wingo>really agonizing over ports, threads, and state still <wingo>the core port impl itself is safe regarding racing writes and closes <wingo>but port implementations probably are not. <wingo>it's possible to have multiple concurrent writes, or writes concurrent to closes, or writes after closes <lloda>I have one FAIL: suspendable-ports.test: 8.2.13 in last master... <wingo>ah damn i pushed paroneay`'s patches by mistake <wingo>i had applied them locally and meant to review them <wingo>lloda: regarding c11 i was thinking some atomic refcounting strategy on the port could work, but i'm not sure <wingo>paroneay`: that fixes the test failures, it was a bug in some recent port hacking <paroneay`>wingo: yay, glad that it was easy to fix, and that it caught a bug! <wingo>lloda: with your patch, are inline functions still accessible via dlsym? <wingo>i am thinking they are not, and for that reason the patch is not a good idea <paroneayea>wingo: btw, I have a few patched things to guile's http lib locally I guess I should probably get upstream to guile: <paroneayea>a) Allowing the "Authorization" header to work with the ever-popular OAuth 2.0 "Bearer" token type <paroneayea>c) Location, in a revised HTTP RFC, allows relative URIs, not just absolute URIs <paroneayea>I guess those are all good patches for guile master? <wingo>i think (c) is already fixed afaiu <wingo>yeah do check if that's the case. but certainly (a) and (b) are welcome on both branches <paroneayea>wingo: should I patch against stable-2.0 so it can easily be merged into both? <wingo>i prefer to patch master then backport <wingo>that way i don't forget to apply something to the dev branch <brendyn>wingo: Everytime I load guile it tells me there are zillions of .go files with newer source files. Can I make guile stop doing that? <wingo>brendyn: there is an outstanding patch for that... the Right Way is to run guile within a GUILE_LOAD_PATH that only includes .go files that you can load. otherwise it's a stat party every time you run guile. <wingo>the warnings are terrible but do have the one marginally positive thing that they let you know that your environment variables are not great <wingo>GUILE_LOAD_COMPILED_PATH rather <wingo>so that's the real fix. can be tricky in cases like guix <wingo>where maybe you have guile 2.0 things in your load path <wingo>so it sees those env vars, fails to load the files, and carps while moving on <brendyn>Yeah well I have guix now with a sort of frankenstein system <wingo>yeah. there are patches under discussion to kill the warnings <brendyn>Well, I'll leave it to the professionals <wingo>however one possibility would be to uninstall guile from your guix profile (horrors) <wingo>then run it only within specific profiles -- so that you don't have a guile 2.0 while you are trying to run 2.2 or something <wingo>dunno. working on it, but somewhat slowly... <wingo>i don't have these problems in practice and i'm not sure why :) <wingo>maybe you have guile-next and guile installed in the same environment? that would probably do it <brendyn>When I open weechat, which uses guile for plugins, the text interface gets all borked with those messages <brendyn>Maybe I should just install GuixSD already <wingo>heh guixsd is great but probably there is a different solution :) <brendyn>I have 3 versions of guile installed <brendyn>But that's only because I uninstalled one earlier <brendyn>Maybe *that* the issue, and I need the fourth one back again, the -git version <lloda>wingo: shouldn't 'extern inline' ensure that? nm libguile-2.2.so says 't' but it should be 'T'. I don't really understand why. <lloda>everything I've read says that 'extern inline' exports a global symbol :-/ <wingo>yeah i don't know. i understood this once ;) <wingo>what we do right now is manually ensuring that what we want is the cas <wingo>i.e. an inline definition that anyone with the .h can use <wingo>and we reify a non-inline exported definition into one translation unit <wingo>using extern inline duplicates the definition into all translation units and relies on the linker to deduplicate <wingo>and i am not sure if the linker will do that <lloda>the way I understood it is that extern inline is only on the .c so there's no duplication. <lloda>it's just that the symbol (say scm_car) isn't exported globally, but that should happen with static inline not with extern inline :-/ <lloda>actually static inline shouldn't emit any symbols, but w/e <wingo>ah so you declare it extern inline in just one file? <wingo>that sounds promising anyway :) <lloda>static inline works, those don't appear in nm output at all <lloda>how can I check the gcc flags? I don't see any std= flags in make -n <wingo>what AC_PROG_CC_C99 does is just make sure that your compiler can do c99 <wingo>so if it detects a compiler that does c99 *or compatible* it won't add a -std=... <wingo>so we've been c11 (gnu11 actually) all along, with a recent enough gcc :P <wingo>(clarification: if your compiler needs -std= or something to do c99, it will add it. but it won't add args if they are not needed.) <lloda>ah, I see, so the inline semantics should still be the c99 ones :-/ <wingo>right now i think we use __attribute__((gnu_inline)) or somethign right? <lloda>well yes, I meant after my patch where I removed all that <lloda>I wonder if it's still in effect <wingo>yay i think i have a fix for the threadsafety stuffs <wingo>we should implement xorshift+ in scheme and see if guile 2.2 can unbox it entirely <dsmith-work>wingo: Is it possible to decompile 2.[12] .go files back to scheme? Or something like scheme? <wingo>i mean, yes but it's not very related to the original code <wingo>and the decompiler isn't written <wingo>unboxing not as effective as one would like <wingo>we are missing a ulogxor operation <wingo>can be fixed, it's the lack of ulogxor that's the prob <davexunit>ACTION has a fuzzy memory from when was exploring that code <wingo>(logand u64 (logxor u64 u64)) -> (ulogxor u64 u64) <lloda>you can do 1'000'000'000 now in C++14, emacs goes crazy <dsmith-work>Isn't there some language (Ada? Fortran?) that has "thousands" separators for hex or other numbers? <wingo>ok! fixed all my port-related handwringings <enderby>hi, i'm having some trouble building guile from source. I don't have sudo privileges at work, and I've had to install libunistring to a /home/User/opt/ directory. I've tried a lot of ./configure paths for --with-libunistring-prefix and I always get the same error: "configure: error: GNU libunistring is required, please install it. " <enderby>thanks, looking into it. So far I'm just seeing that it can't find libunistring after looking in the right directories ***dsmith is now known as dsmith-work
<amz3`>I see they are new guilers around :) <amz3`>200K and I have the full dump of hackernews, hopefully it will work <amz3`>the thing is that it was killed in the middle of the dump, I restarted it but without changing the path of the output <paroneayea>amz3`: for your wiredtiger powered search engine? <amz3`>so maybe in the middle of the scm file there is some broken scm <amz3`>hopefully I will there is no issue, or I can work around it, tomorrow we will knwo <amz3`>and that is only the content of news.ycombinator.com I will also need to fetch the stories' urls <amz3`>I got an issue with my VPS, I payed for several month just before they upgraded the offer, so I'm stuff with 4G or RAM and 4 procs instead of the double <paroneayea>davexunit: wingo: others: how do you hook up your guile web application to apache / nginx / etc? <lfam>amz3`: You should ask them if they will upgrade you to the new offer. Many businesses will do this for their customers <amz3`>lfam: exactly I did not think about it <wingo>i have an example config in the tekuti git repo <wingo>ACTION seeing what he can do about xorshift128+ :) <wingo>turns out i need some more flow analysis to solve that problem <wingo>the type and range inference pass is a forward flow analysis to determine the range of possible values <wingo>but i need to take that and flow it backwards to see the range of values that can contribute to the result <wingo>though, i don't know if it's only useful in combination with invocations of logand, and if that's the case maybe i can do something simpler... dunno ***zv is now known as zv-test
***zv-test is now known as zv
<civodul>paroneayea: speaking of which, we should consolidate our bindings into a canonical guile-libgcrypt someday :-) <paroneayea>civodul: would it be difficult for guix to depend on a separate guile-libgcrypt package? <paroneayea>the binary installer can probably bundle that too, right <paroneayea>ACTION never looked at how the guix binary install method handles its dependencies <paroneayea>civodul: it should be easy to consolidate since most of pubstrate's libgcrypt bootstrapping was done by a big snarf of guix code :) <civodul>it would introduce a slight difficutly for people building from source on distros that lack guile-libgcrypt <civodul>but long term it sounds like the right thing <paroneayea>civodul: but on the upside it would incentivize packaging more guile libraries for other distros? :) <paroneayea>civodul: would you like to stick with GPLv3+ or switch to LGPLv3+? <paroneayea>I'm actually a-ok with GPLv3+, but since libgcrypt is LGPL <civodul>i prefer GPLv3+, but we can always talk ;-)