#srfi — Public Fediverse posts

There is a Scheme testing framework by Arthur A. Gleckler, which was developed before SRFI-64, but published only in 2020s.

https://srfi-email.schemers.org/srfi-discuss/msg/15037945/

1. It's very close to suitbl testing library and SRFI-269 in spirit.
2. It has a very neat property of saving resumable continuations on failure, so you can explore the problem in recursive REPL having all the local scope available.

#scheme #guile #srfi #testing

We published a new SRFI 269: Portable Test Definitions.

https://srfi.schemers.org/srfi-269/

We already got a very positive feedback from seasoned Scheme hackers, but we also looking forward to yours. We have a few more weeks to incorporate the changes.

P.S. 21 years have passed since SRFI-64.
P.P.S. There are links to demo video of the library usage at the end of the SRFI.

BTW, this huge work is possible thanks to @nlnet and funding they provide!

#srfi #guile #scheme #lisp #testing

We were working on SRFI for portable test definitions API for quite some time, and it finally ready.

Today I made a video quickly explaining the specification and showing an implementation and all cool consequences of the API design.

https://youtu.be/JI7Z6-tndaw

SRFI draft and testing library source code:
- https://trop.in/SRFI-268
- https://git.sr.ht/~abcdw/guile-ares-rs/tree/master/item/src/guile/ares/suitbl

#guile #scheme #srfi

I like #UnitTesting. The original #SUnit was wonderful, but it was ported to the land of needless complexity and became #JUnit which begat a whole lot of add on pieces. A simple idea buried under feature creep.

My favorite testing framework is #SRFI-78 https://srfi.schemers.org/srfi-78/srfi-78.html which provides a little reporting and summarization but it doesn't interfere with the tests. In C the MinUnit header file from Jera Design is beautiful. I use a beefier implementation, again to get simple reporting.

#Forth has ttester. It is terse to the point that I am tempted to add some reporting. So far I've resisted the temptation.

As in SRFI-78, you test a phrase and compare against expected results on the stack.

T{ 1 2 3 drop -> 1 2 }T passes
T{ 1 2 3 dup -> 1 2 3 }T fails

I'm writing tests for my library code and use them to test expressions in my AoC efforts.

I'm trying to decide if I should include the test in the library source (compiled conditionally) or in separate test-* files. #Programming

I like #UnitTesting. The original #SUnit was wonderful, but it was ported to the land of needless complexity and became #JUnit which begat a whole lot of add on pieces. A simple idea buried under feature creep.

My favorite testing framework is #SRFI-78 https://srfi.schemers.org/srfi-78/srfi-78.html which provides a little reporting and summarization but it doesn't interfere with the tests. In C the MinUnit header file from Jera Design is beautiful. I use a beefier implementation, again to get simple reporting.

#Forth has ttester. It is terse to the point that I am tempted to add some reporting. So far I've resisted the temptation.

As in SRFI-78, you test a phrase and compare against expected results on the stack.

T{ 1 2 3 drop -> 1 2 }T passes
T{ 1 2 3 dup -> 1 2 3 }T fails

I'm writing tests for my library code and use them to test expressions in my AoC efforts.

I'm trying to decide if I should include the test in the library source (compiled conditionally) or in separate test-* files. #Programming

I like #UnitTesting. The original #SUnit was wonderful, but it was ported to the land of needless complexity and became #JUnit which begat a whole lot of add on pieces. A simple idea buried under feature creep.

My favorite testing framework is #SRFI-78 https://srfi.schemers.org/srfi-78/srfi-78.html which provides a little reporting and summarization but it doesn't interfere with the tests. In C the MinUnit header file from Jera Design is beautiful. I use a beefier implementation, again to get simple reporting.

#Forth has ttester. It is terse to the point that I am tempted to add some reporting. So far I've resisted the temptation.

As in SRFI-78, you test a phrase and compare against expected results on the stack.

T{ 1 2 3 drop -> 1 2 }T passes
T{ 1 2 3 dup -> 1 2 3 }T fails

I'm writing tests for my library code and use them to test expressions in my AoC efforts.

I'm trying to decide if I should include the test in the library source (compiled conditionally) or in separate test-* files. #Programming

I like #UnitTesting. The original #SUnit was wonderful, but it was ported to the land of needless complexity and became #JUnit which begat a whole lot of add on pieces. A simple idea buried under feature creep.

My favorite testing framework is #SRFI-78 https://srfi.schemers.org/srfi-78/srfi-78.html which provides a little reporting and summarization but it doesn't interfere with the tests. In C the MinUnit header file from Jera Design is beautiful. I use a beefier implementation, again to get simple reporting.

#Forth has ttester. It is terse to the point that I am tempted to add some reporting. So far I've resisted the temptation.

As in SRFI-78, you test a phrase and compare against expected results on the stack.

T{ 1 2 3 drop -> 1 2 }T passes
T{ 1 2 3 dup -> 1 2 3 }T fails

I'm writing tests for my library code and use them to test expressions in my AoC efforts.

I'm trying to decide if I should include the test in the library source (compiled conditionally) or in separate test-* files. #Programming

I like #UnitTesting. The original #SUnit was wonderful, but it was ported to the land of needless complexity and became #JUnit which begat a whole lot of add on pieces. A simple idea buried under feature creep.

My favorite testing framework is #SRFI-78 https://srfi.schemers.org/srfi-78/srfi-78.html which provides a little reporting and summarization but it doesn't interfere with the tests. In C the MinUnit header file from Jera Design is beautiful. I use a beefier implementation, again to get simple reporting.

#Forth has ttester. It is terse to the point that I am tempted to add some reporting. So far I've resisted the temptation.

As in SRFI-78, you test a phrase and compare against expected results on the stack.

T{ 1 2 3 drop -> 1 2 }T passes
T{ 1 2 3 dup -> 1 2 3 }T fails

I'm writing tests for my library code and use them to test expressions in my AoC efforts.

I'm trying to decide if I should include the test in the library source (compiled conditionally) or in separate test-* files. #Programming

In GNU Guile, cond-expand knows of supported features that are not built into GNU Guile only once I have already imported the libraries in which the features are implemented, where cond-expand-provide is being used to define a cond-expand feature.

Why bother using cond-expand-provide if it will run only after you already have imported something?

It is the chicken and the egg problem, or something.

AH JUS DUN GAE ET.

#gnuguile #guile #guix #lisp #programming #scheme #srfi

Look at what is coming to Scheme ecosystem:

https://nlnet.nl/project/SchemeTestingFramework

#scheme #guile #lisp #srfi #srfi64

A new SRFI-64 implementation by @[email protected] is merged into Guile: https://git.savannah.gnu.org/cgit/guile.git/commit/?id=ad90f45a8c4fd00add44c214863850a425f787a0

#guile #scheme #lisp #srfi #srfi64

Hot take: in terms of the language specified treated independently of the social process of standardization itself, everyone's beloved #r5rs is actually the worst post-#r4rs scheme, and #r6rs is easily the best and most revolutionary, hence the controversy surrounding it.

#lisp #srfi

SRFIs are modules, which are portable across different scheme implementations, also there is a process for proposing them. BTW, guile contains only subset of it.

ice-9 are basically guile modules, which could be (guile ...), but they are (ice-9 ...).

https://srfi.schemers.org/srfi-process.html

https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00046.html

#guile #scheme #lisp #srfi #guix

Just had a (certainly unoriginal) idea for "named match", which extends the Shinn patter matcher to behave like named let. Quick and dirty prototype came together quickly with syntax-case.

#lisp #scheme #macros #r7rs #srfi #guix

#SRFI-165 (environment monad) is great because it allows you to do all the fun-yet-dirty stuff you can do with `eval` in a safe (interaction-environment) that you have precise control over

Do someone have a good test running setup for #guile?

#emacs, #geiser, #srfi-64, #repl

I hacked something like this, but there is a way more work to make it any satisfactory.

There is apparently an #OKVS based database #SRFI https://srfi.schemers.org/srfi-168/srfi-168.html

There is apparently an #OKVS based database #SRFI https://srfi.schemers.org/srfi-168/srfi-168.html