IRC channel logs


back to list of logs

<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
<sapientech>OrangeShark: yeah i am, so i do hav eit
<sapientech>have it*
<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
<sapientech>*which autoconf
<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
<sapientech>OrangeShark: i hope youre not driving!!
<OrangeShark>Nah lol
<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>but that is sort of taste... all together your would be
<daviid>sapientech: then you need to adapt your and to use @GUILE_SITE@ instead of ...
<daviid>have to go afk for a while now, talk later
<OrangeShark>did go down?
<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")?
<mark_weaver>zv, sapientech: here's one way to do it:
<zv>oh nice mark
<zv>yeah, i'm tryin to make something that replaces nicks in weechat (for users of gateways)
<zv>mark_weaver: can you give me any quick pointers on doing this sort of thing better?
<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
<zv>right on!
<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>*Al Petrofsky
<mark_weaver>btw, although 'syntax-case' macros are more powerful and sometimes needed, I would recommend using 'syntax-rules' macros when they are sufficient.
<sapientech>mark_weaver: nice ^
<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>hi folks
<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 about it. a proposed patch would be ideal, but it would also be fine to just point out the issue.
<mark_weaver>thanks :)
<wilfredh>sent, thanks
<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
<catonano>paroneayea: I'd love reading your post
***mario-go` is now known as mario-goulart
<sapientech>daviid: got configure working, but a little confused where to put @GUILE_SITE@
<amz3>héllllloooooo #guile
<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?
<alezost>jmd: #\\newline
<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
<alezost>(display (integer->char #x3bb))
<jmd>standard input:41:10: Value out of range 0 to 255: 955
<alezost>I can only say: works for me :-)
<alezost>jmd: how do you get that error?
<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>In standard input:
<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
<jmd>Could be.
<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?
<wingo>why would 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
<jmd>I get #f
<jmd>Correction: I get 0
<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>will C11 help with that?
<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>tx for the headsup lloda
<wingo>lloda: regarding c11 i was thinking some atomic refcounting strategy on the port could work, but i'm not sure
<wingo>it's very tricky :)
<wingo>lloda: fixed i think
<wingo>paroneay`: that fixes the test failures, it was a bug in some recent port hacking
<wingo>tx for those tests!
<paroneay`>catonano: good to know, maybe I'll write it
<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>b) the Cookie / Set-Cookie http headers
<dsmith-work>Wednesday Greetings, Guilers
<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
<paroneayea>wingo: ah!
<wingo>yeah do check if that's the case. but certainly (a) and (b) are welcome on both branches
<wingo>send a mail :)
<paroneayea>wingo: cool will do :)
<wingo>or two mails rather :)
<paroneayea>oh yup
<paroneayea>wingo: you're right
<paroneayea>c) is fixed in master
<paroneayea>wingo: should I patch against stable-2.0 so it can easily be merged into both?
<wingo>paroneayea: either way
<paroneayea>ok :)
<wingo>i prefer to patch master then backport
<paroneayea>wingo: good to know. thx!
<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>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>but you are running 2.2
<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 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
<wingo>ACTION dunno
<lloda>the way I understood it is that extern inline is only on the .c so there's no duplication.
<lloda>linker doesn't complain
<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>yeah there is no change
<wingo>what AC_PROG_CC_C99 does is just make sure that your compiler can do c99
<wingo>it doesn't force a std=
<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>you mean right now?
<wingo>right now i think we use __attribute__((gnu_inline)) or somethign right?
<wingo>see __scm.h
<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>not really
<wingo>i mean, yes but it's not very related to the original code
<wingo>and the decompiler isn't written
<wingo>^ xorshift128+
<wingo>unboxing not as effective as one would like
<wingo>we are missing a ulogxor operation
<davexunit>hmm yeah still a good amount of boxing.
<wingo>can be fixed, it's the lack of ulogxor that's the prob
<davexunit>another VM op needed?
<davexunit>ACTION has a fuzzy memory from when was exploring that code
<wingo>(logand u64 (logxor u64 u64)) -> (ulogxor u64 u64)
<dsmith-work>wingo: Heh #xffffFFFFffffFFFF Nice trick
<davexunit>hey that's a nice readability hack
<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?
<dsmith-work>Istr seeing
<dsmith-work>'_' used like that somewhere.
<dsmith-work>Reading 64 bit hex numbers is hard.
<wingo>1_000_000 or so
<dsmith-work>wingo: Ahh. Thanks.
<wingo>ok! fixed all my port-related handwringings
<wingo>i think anyway
<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>any help would be much appreciated
<wingo>ACTION headed out, biab
<dsmith-work>enderby: I'd start looking through config.log
<dsmith-work>s/start /start by /
<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`> so what's up #guile?
<amz3`>I see they are new guilers around :)
<amz3`>or new old guilers...
<amz3`>ijp: *blink* *blink*
<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`>paroneayea: yes :)
<amz3`>hopefully I will there is no issue, or I can work around it, tomorrow we will knwo
<amz3`>the file is 8G uncompressed
<amz3`>and that is only the content of 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
<amz3`>for the same price
<paroneayea>davexunit: wingo: others: how do you hook up your guile web application to apache / nginx / etc?
<davexunit>paroneayea: reverse proxy
<paroneayea>davexunit: hm ok!
<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: thx!
<lfam>It's worth trying :)
<amz3`>lfam: exactly I did not think about it
<amz3`>ACTION mail sent
<wingo>paroneayea: reverse proxy
<wingo>like davexunit
<wingo>i have an example config in the tekuti git repo
<paroneayea>wingo: ah great!
<wingo>ACTION seeing what he can do about xorshift128+ :)
<dsmith-work>Sounds like a movie: "The Exorshift: 128+"
<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
<paroneayea>ACTION microblogs about Pubstrate progress
<civodul>paroneayea: speaking of which, we should consolidate our bindings into a canonical guile-libgcrypt someday :-)
<paroneayea>civodul: yes
<paroneayea>I was thinking about that
<paroneayea>civodul: would it be difficult for guix to depend on a separate guile-libgcrypt package?
<paroneayea>I guess not
<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>paroneayea: cool :-)
<civodul>Guix could depend on it, yes
<paroneayea>civodul: cool, good to know :)
<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+?
<civodul>ah ha!
<paroneayea>I'm actually a-ok with GPLv3+, but since libgcrypt is LGPL
<civodul>i prefer GPLv3+, but we can always talk ;-)
<paroneayea>let's stick with GPLv3+ then :)
<paroneayea>pubstrate is also GPLv3+ :)
<civodul>so we're fine here