IRC channel logs


back to list of logs

***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?
<Zelphir>For example: Is this the correct way?
***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>A consequence of Rice's theorem, I think:
<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.
<antipode>(compare them with e.g. 'diff' )
<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
<stis>Hello guilers!
<Zelphir>Hey Stis
<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