On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> The specification says the following regarding the test-assert:
>
>> Though the test-name is a string literal in the examples, it is an
>> expression. It is evaluated only
On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> The specification for test-end says:
>
>> Additionally, if the matching test-begin installed a new test-runner, then
>> the
>> test-end will uninstall it, after reporting
On 30.09.2024 20:50, Taylan Kammer wrote:
> On 30.07.2024 21:51, Tomas Volf wrote:
>> Hello,
>>
>> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>>
>> The specification says the following regarding the test-apply:
>>
>>> If one or more specifiers are listed then only tests
On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> The specification says the following regarding the test-apply:
>
>> If one or more specifiers are listed then only tests matching the specifiers
>> are executed.
> The spec
On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> The specification says that test-equal is equivalent to:
>
>> (test-assert [test-name] (equal? expected test-expr))
> Hence the test-assert's requirement to evaluate test-n
On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> The specification says that:
>
>> The test also fails if an exception is raised, assuming the implementation
>> has
>> a way to catch exceptions.
> Guile has a way to catc
On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> The specification says that test-eqv is equivalent to:
>
>> (test-assert [test-name] (eqv? expected test-expr))
> Hence the test-assert's requirement to evaluate test-name
On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> test-with-runner has following signature:
>
> (test-with-runner runner decl-or-expr ...)
>
> That, according to syntax-case rules (and how test-apply works with the sam
On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> The test-group is defined as equivalent to:
>
> (if (not (test-to-skip% suite-name))
> (dynamic-wind
> (lambda () (test-begin suite-name))
> (lamb
On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> When I try to remove a property from the result alist using this code:
>
> (use-modules (srfi srfi-64))
> (let ((r (test-runner-null)))
> (test-result-set! r
On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> The specification says that test-eq is equivalent to:
>
>> (test-assert [test-name] (eq? expected test-expr))
> Hence the test-assert's requirement to evaluate test-name on
Hello,
I believe I may have found a bug in the guile 3.0 build system.
When configuring and building on systems that have libgmp installed, the guile
build system will add '-I$LIBGMP_PREFIX' to the set of compiler flags reported
by 'pkg-config --cflags guile-3.0' (and hence also 'guile-config c
Hi,
Given the following C program:
--8<---cut here---start->8---
#include
#include
int main(void)
{
struct sigaction act;
sigaction(SIGINT, NULL, &act);
printf("%p %p %p\n", act.sa_handler, SIG_IGN, SIG_DFL);
}
--8<---cut
On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> The specification says the following regarding the test-result-kind:
>
>> If we've started on a new test, but don't have a result yet, then the result
>> kind is 'xfail if
On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> The specification says the following regarding the test-approximate:
>
>> This is equivalent to (except that each argument is only evaluated once):
>>
>>
>> (test-assert [t
On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> Test runner is specified as:
>
>> A test-runner is an object that runs a test-suite, and manages the state. The
>> test group path, and the sets skip and expected-fail spec
On 30.07.2024 21:52, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> Reading the specification for test-expect-fail I do not see a mandate to clear
> expect-fail list on test-end. test-skip does have such provision, but it is
> lacking in t
On 30.09.2024 16:04, Taylan Kammer wrote:
> I've also decided to remove the check on whether the begin-name is true,
> because as per spec it's not allowed to be false anyway, and IMO it should
> call the bad-end-name callback if the begin-name was explicitly passed as #f
> but the end-name is n
On 30.09.2024 16:42, Taylan Kammer wrote:
> On 30.07.2024 21:51, Tomas Volf wrote:
>> Hello,
>>
>> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>>
>> The specification says the following about the count argument to the
>> test-begin
>> form:
>>
>>> The optional count must
19 matches
Mail list logo
