***roptat is now known as Guest2228
***Guest2228 is now known as roptat_
***roptat_ is now known as roptat
***roptat is now known as help
<Zelphir>When using SRFI-64 for unit tests, I usually write a `(test-begin suite-name [count])` and then a `(test-group suite-name decl-or-expr ...)` which contains the actual tests. I just tried putting another test-begin and test-group inside of a test-group. That seems to run as well. But what is the way one should nest groups of tests? Having test-group _and_ test-begin for every level of nesting seems redundant. Maybe one is supposed to only next <Zelphir>test-group and not write another test-begin and test-end around each group? ***Colere is now known as Sauvin
***justVain is now known as justache
<spk121>Is it possible to check if a .go file compiled by one version of Guile is functionally equivalent to a .go compiled by another Guile, presuming same bits/endianness? <spk121>I'm thinking between same version of guile on two different operating systems. <antipode>spk121: There is some theorem that states that (in the general case), such a thing is undecidable. <antipode>However, what do you mean with 'another version of Guile'? <antipode>If you mean, distributed by another distro, but same version number (and hence, same compiler, same optimiser), you can do a bit-for-bit comparison? <spk121>antipode: right now, Guile on MinGW 64-bit fails to build from source because the Scheme files that make up the compiler in stage 0, once compiled, fail to properly compile stage 1. <spk121> On the same machine, I have a Cygwin build of Guile that does work. <spk121>If I could understand the difference between Guile / MinGW compilation and Guile / Cygwin compilation, I might be able to fix Guile / MinGW <antipode>spk121: I don't know of any automated method, but you can do a "guild disassemble" on both .go & compare them <antipode>Also, have you checked that the .go are, in fact, different? <antipode>I mean, the problem could perhaps lie in the C code instead. <spk121>antipode: the problem is almost assuredly that, for MinGW, for each 'long' in the C, one needs to decide if it should be long or really uintptr_t. <spk121>There are various versions of that patch in various trees. <spk121>In MinGW 64 long is 4 bytes and void * is 8 bytes, which does bad things to the compiler <antipode>spk121: Have any of the patches been merged yet? <antipode>‘Replace 'long' by uintptr_t because its an integer representation of a pointer’ sounds to me like something that could be reviewed & applied, even if things don't work yet as a whole on MinGW <spk121>antipode: no. There's one in the wip-mingw branch, but, it seems to have gone stale. janneke has another one. That's what I'm trying to do today <janneke>spk121: i believe that wip-mingw is my lastest branch, it was rebased half a year ago or so <janneke>i haven't gotten the jit to work, though