Re: SRFI-64: test exception symbol
On 30.04.2020 17:55, Vladimir Zhbanov wrote: On Thu, Apr 30, 2020 at 06:06:21PM +0300, Vladimir Zhbanov wrote: Hi, In SRFI-64, is there a way to test what exception raised using test-error() or anything else? I know about looking into test logs (if 'test-error' is used), though that's not what I need. I need a way to be sure a test raises the exception it should raise. The test-error form takes two optional operands before the test expression. It's defined as: (test-error [[test-name] error-type] test-expr) Evaluating test-expr is expected to signal an error. The kind of error is indicated by error-type. If the error-type is left out, or it is #t, it means "some kind of unspecified error should be signaled". For example: (test-error #t (vector-ref '#(1 2) 9)) This specification leaves it implementation-defined (or for a future specification) what form test-error may take, though all implementations must allow #t. Some implementations may support SRFI-35's conditions, but these are only standardized for SRFI-36's I/O conditions, which are seldom useful in test suites. An implementation may also allow implementation-specific "exception types". For example Java-based implementations may allow the names of Java exception classes: ;; Kawa-specific example (test-error (vector-ref '#(1 2) 9)) An implementation that cannot catch exceptions should skip test-error forms. My SRFI-64 implementation allows the error-type operand to be a predicate (one-argument procedure that returns a Boolean) to allow maximum flexibility. It's found here: https://github.com/TaylanUB/scheme-srfis - Taylan
Re: database library, siilar to guile-dbi, for Guile 3 ?
On Thu, Apr 30, 2020 at 2:45 PM Jeronimo Pellegrini via General Guile related discussions wrote: > > Hello, > > I am looking for a database library that would abstract away the underlying > db engine. I see that guile-dbi is listed as "Guile 2.2" only on the list of > libraries on the Guile website, I suspect the website is out of date. >and the link is broken anyway. > Is there something similar to Guile 3? > > Thanks a lot! > Jeronimo > https://github.com/opencog/guile-dbi/ try and see if it works
Re: SRFI-64: test exception symbol
Hi Taylan, On Fri, May 01, 2020 at 11:58:41AM +0200, Taylan Kammer wrote: > On 30.04.2020 17:55, Vladimir Zhbanov wrote: > > On Thu, Apr 30, 2020 at 06:06:21PM +0300, Vladimir Zhbanov wrote: > > > Hi, > > > > > > In SRFI-64, is there a way to test what exception raised using > > > test-error() or anything else? I know about looking into test > > > logs (if 'test-error' is used), though that's not what I need. I > > > need a way to be sure a test raises the exception it should raise. > > The test-error form takes two optional operands before the test expression. > It's defined as: > > > > (test-error [[test-name] error-type] test-expr) > > Evaluating test-expr is expected to signal an error. The kind of error is > indicated by error-type. > > If the error-type is left out, or it is #t, it means "some kind of > unspecified error should be signaled". For example: > > (test-error #t (vector-ref '#(1 2) 9)) > > This specification leaves it implementation-defined (or for a future > specification) what form test-error may take, though all implementations > must allow #t. Some implementations may support SRFI-35's conditions, but > these are only standardized for SRFI-36's I/O conditions, which are seldom > useful in test suites. An implementation may also allow > implementation-specific "exception types". For example Java-based > implementations may allow the names of Java exception classes: > > ;; Kawa-specific example > (test-error (vector-ref '#(1 2) 9)) > > An implementation that cannot catch exceptions should skip test-error forms. > > Well, I'm aware of this, thank you :-) > My SRFI-64 implementation allows the error-type operand to be a predicate > (one-argument procedure that returns a Boolean) to allow maximum > flexibility. It's found here: > > https://github.com/TaylanUB/scheme-srfis Thank you, I'd really like to try your implementation together with my code. Though I don't know how :-( The issue with this solution is how I would use the code and integrate it into our project. The first question: supposed that I already have guile installed (together with its own srfi's) and have downloaded your repository, how can I use your modules in my own code then? The second one: how to make your code available for our code in the spread of distributions our project builds on? Probably, there is a way to uniformly integrate some parts of it (e.g. srfi-64) to our project? Or should I require distribution packagers working on packaging of our project to package your code as a some new package, too? Not sure, how to achieve this and if this is possible at all. Any hints? -- Vladimir (λ)επτόν EDA — https://github.com/lepton-eda
Loading multiple versions of a Module
Guile currently doesn't allow loading multiple versions of a Module. For example this will not work. --- start.scm (import (a) (b (2))) (helloA) (helloB) --- a/a.scm (library (a) (export helloA) (import (rnrs) (b (1))) (define helloA (lambda () (display "hello from A1\n") (helloB --- b1/b.scm (library (b (1)) (export helloB) (import (rnrs))) (define helloB (lambda () (display "hello from B1\n"))) --- b2/b.scm (library (b (2)) (export helloB) (import (rnrs)) (define helloB (lambda () (display "hello from B2\n" Is there are away to get around this? What is the reason for this behavior? Is it part of r6rs or something? Thanks!, -Martin
