IRC channel logs

2018-07-16.log

back to list of logs

<stis>hej guilers!
<wleslie>hey stis!
<daviid>happy monday guilers!
<civodul>hey!
<OrangeShark>happy monday
<grumbel>How do I convert a real to integer?
<grumbel>(floor 5.5) seems to work
<civodul>grumbel: note that 'foor' gives you an "inexact integer"
<civodul>whereas sometimes you want an "exact integer"--i.e., 0 and not 0.0
<civodul>to that end there's inexact->exact
<grumbel>(inexact->exact 5.5) will result in a rational: 11/2
<grumbel>So (inexact->exact (floor 5.5))?
<grumbel>seems a little verbose for such a common operation
<civodul>i agree
<daviid>grumbel: you can write your own, float->int ...
<jlicht>does guile have something like Clojure's EDN to facilitate storing/sending/reading data?
<brendyn>Is it normal that an expression that runs fine in the repl will crash when run with ,strace ?
<wingo>brendyn: ,trace i guess? crashes there sound like a bug in guile's debugging foo to me
<wingo>jlicht: only s-expressions
<wingo>sneek: later tell dsmith-work i fixed that segfault on master i think
<sneek>Will do.
<brendyn>I made it crash when I was generating long lists
<wingo>weird
<brendyn>1 sec ill try reproduce it
<brendyn>wingo: https://paste.debian.net/1033924/
<brendyn>,trace (queens 1) and ,trace (queens 2) work
<brendyn>,trace (queens 3) ends with In procedure =: Wrong type: #<unspecified>
<brendyn>,trace (queens 4) => In procedure map: Not a list: #<unspecified>
<brendyn>,trace (queens 7) => In procedure list-ref: Wrong type argument in position 1: #<unspecified>
<brendyn>It's a little different depending on the number
<brendyn>but they all produce answers without ,trace
<jlicht>wingo: thanks!
<civodul>jlicht: what's EDN?
<jlicht>civodul: https://github.com/edn-format/edn, basically an application of s-expressions with some things a bit more specified to use it as a data-exchange format (among other things)
<civodul>jlicht: i see, thanks
<civodul>not very schemey, but interesting ;-)
<jralls>Had no response on this yesterday so I'll ask again: GnuCash has a localization problem on MSWindows in the Vietnamese locale: scm_c_eval_string("(any-form-at-all)"); asserts in utf8_to_codepoint(). A representative stack trace may be found at https://bugs.gnucash.org/show_bug.cgi?id=796728#c19. Converting the string to an SCM beforehand and using scm_eval_string() doesn't help. Is there a work-around?
<daviid>jralls: you should try to produce a snipet, that does not depend on gnucash, a tiny C program that reproduce what you are trying to solve, then email it to guile ML. now, why aren't you tryingt port to 2.2.4 instead of 2.0.14, they handle encoding in a diff way, and all this work you are doing wil have to be done agina ... not to mention that you'll have a hard time to receive support for 2.0.14 ...
<daviid>jralls: in 2.0.14, you must set port encoding 'manually', all ports
<daviid>jralls: you might want to look at how lilypond does this, and they ae working on a port as well (2.0.14 as well), nd they have japanese, chinese ... it might help you
<jralls>daviid: AFAICT there's no way to control the port generated by scm_eval_string.
<daviid>not really my domain, so I can't really help more then these two suggestion, sorry and good luck!
<jralls>daviid: As for 2.2.x, we've recently gotten that working in Linux but haven't yet tried to build it in MSYS2.
<jralls>daviid: Thanks for trying.
<daviid>jralls: it really is a loss of time to work on 2.0.14, imo. I think there are succeffull attempt of 2.2.x on win, hope someone here can confirm ...
<daviid>without thread though
<daviid>if i understood correctly, but i never ever used win in my life :), lucky me
<daviid>jralls: 2.2.x has been overhalled wrt port, it really is a lot better
<daviid>jralls: look at the NEWS, and port, soft port, textual ports in 2.2.x, you'd be convinced to use it istead of 2.0.14 ... :)
<daviid>jralls: not to mention that it is an order of mag faster ... and 2.0.14 will desapear from distro real soon ...
<jralls>daviid: For now we need to support both because not all distros provide 2.2 yet. Believe it or not, not everyone uses Debian Unstable in production. As for disappearing, I used to preach that about Gtk2. 10 years later it's still everywhere.
<daviid>2.2 is in buster as well, fwiw
<jralls>Yeah, so? Normal users aren't, they're on stretch. And Ubuntu LTS 14 and 16.
<daviid>jralls: yes, in buster i can confirm, ubunto i don't know
<jralls>None of which applies to Windows, where we have to build for distribution. So I'll try that and see if it fixes the UTF8 string problems.
<jralls>daviid: Thanks agains.
<daviid>jralls: np
<stencilv>Hi-- I'm having trouble installing haunt (https://dthompson.us/projects/haunt.html) - e.g. haunt-0.2.2. My system is debian stretch, but for guile I have installed: guile-2.2, guile-2.2-dev, guile-2.2-doc, guile-2.2-libs:amd64 -- all 2.2.3+1-3. When I “./configure” to try to build haunt, it reports: “...checking for guile-2.2... /usr/bin/guile-2.2; checking for Guile version >= 2.2... 2.2.3; checking for guild-2.2... no...” while
<stencilv>e.g. from a command line “guild -v” reports “guild (GNU Guile) 2.2.3”. (Doing "make" after "./configure" results in errors). I'm assuming I need to tweak something in configure.ac, maybe?? Thanks in advance for any advice...
<OrangeShark>stencilv: I think that has to do with how debian installs guile, it probably has a symlink of guile-2.2 to guile, but not for guild
<OrangeShark>stencilv: I believe if you do "./configure GUILE=/usr/bin/guile" it should find guild
<stencilv>OrangeShark: ah; will give that a try. Thanks!
<stencilv>OrangeShark: indeed, that seems to have worked!
<OrangeShark>stencilv: great :)
<amz3>nice!