IRC channel logs

<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!

IRC channel logs

2018-07-16.log