Hello all!
Can some brush me up about the R7RS libraries effort in Gambit?
I stumbled upon https://github.com/udem-dlteam/libs/ but:
A) There is no tests
B) There is no doc
C) The layout of the repository is as far as I can tell:
libs/srfi/1/1.sld
That would me that srfi 1 is importable with:
(import (srfi 1 1))
which looks odd. Maybe I misunderstood something.
D) There is not (scheme fu) libraries
E) Can someone add a dummy test for a dummy library so that I can see how to run recent gambit with R7RS? Here is an example of such thing: https://github.com/amirouche/arew-scheme/blob/master/src/tests-tests.scm
F) While I am at it, does gambit new module system support introspection or reflection?
Thanks in advance!
Afficher les réponses par date
I stumbled upon https://github.com/udem-dlteam/libs/ but:
Great. I didn't know it was public :) It's mostly (but not exclusively) SRFIs for now.
A) There is no tests
Work in progress :)
A lot of SRFIs don't have many tests. It might be nice to gather a big, up-to-date test suite for all SRFIs. Or keep up-to-date tests in each SRFI's repo with the sample implementation.
B) There is no doc
All except one of the current ones are SRFI implementations, so the SRFI is the documentation.
C) The layout of the repository is as far as I can tell:
libs/srfi/1/1.sld
That would me that srfi 1 is importable with:
(import (srfi 1 1))
which looks odd. Maybe I misunderstood something.
Gambit's lookup rules allow either foo.sld or foo/foo.sld to be imported with (import (foo)). This may be unusual among R7RS Schemes.
D) There is not (scheme fu) libraries
They are in the lib/scheme directory Gambit's main repo: https://github.com/gambit/gambit/tree/master/lib/scheme
It also has a lib/srfi directory: https://github.com/gambit/gambit/tree/master/lib/srfi
Most of the SRFI implementations from udem-dlteam/libs will probably be merged into Gambit's main repo once they have been tested enough; libs is mostly for work-in-progress stuff.
E) Can someone add a dummy test for a dummy library so that I can see how to run recent gambit with R7RS? Here is an example of such thing: https://github.com/amirouche/arew-scheme/blob/master/src/tests-tests.scm
Gambit has a build-in test framework but I haven't used it yet. We also plan to implement SRFI 64 (A Scheme API for test suites) using the built-in framework.
F) While I am at it, does gambit new module system support introspection or reflection?
I don't know about this one, but it's at least possible to find all the symbols accessible in the current environment: https://misc.lassi.io/2019/gambit-apropos.scm
F) While I am at it, does gambit new module system support introspection or reflection?
I don't know about this one, but it's at least possible to find all the symbols accessible in the current environment: https://misc.lassi.io/2019/gambit-apropos.scm
Gambit's R7RS library support is built on top of its native "namespaces" mechanism, so anything that can be done to namespaces should be possible to do to libraries.
The slides from the Modules talk at Gambit@30 are a good intro: https://github.com/gambit/gambit-at-30/blob/master/talks/Gambit30-Modules.pdf. Marc is also updating the module/namespace parts of Gambit's manual in the near future.
Here are the slides for the presentation about Gambit's upcoming Geiser (Emacs) support which relies on reflection a lot: https://github.com/gambit/gambit-at-30/tree/master/talks/gambitWithGeiser
Le sam. 2 nov. 2019 à 09:43, Lassi Kortela lassi@lassi.io a écrit :
I stumbled upon https://github.com/udem-dlteam/libs/ but:
Great. I didn't know it was public :) It's mostly (but not exclusively) SRFIs for now.
A) There is no tests
Work in progress :)
A lot of SRFIs don't have many tests. It might be nice to gather a big, up-to-date test suite for all SRFIs.
Or keep up-to-date tests in each SRFI's repo with the sample implementation.
That will be nice.
B) There is no doc
All except one of the current ones are SRFI implementations, so the SRFI is the documentation.
We already discussed that matter in SRFI schemedoc mailing list. We disagree. In my opinion, SRFI documents are not user documentation. Simply refering gambit user to the SRFI document is not good enough. A proper implementation documentation will need examples uses, a useable comment system. And also systematic documentation of all forms. Unlike some SRFI document like (scheme mapping) aka. SRFI-146 that bolt together (scheme mapping) and (scheme mapping hash) together (see https://srfi.schemers.org/srfi-146/)
C) The layout of the repository is as far as I can tell:
libs/srfi/1/1.sld
That would me that srfi 1 is importable with:
(import (srfi 1 1))
which looks odd. Maybe I misunderstood something.
Gambit's lookup rules allow either foo.sld or foo/foo.sld to be imported with (import (foo)). This may be unusual among R7RS Schemes.
It is different from what I have already seen, but I see it as an improvement as all files can be in the same directory which will ease navigation.
D) There is not (scheme fu) libraries
They are in the lib/scheme directory Gambit's main repo: https://github.com/gambit/gambit/tree/master/lib/scheme
It also has a lib/srfi directory: https://github.com/gambit/gambit/tree/master/lib/srfi
Most of the SRFI implementations from udem-dlteam/libs will probably be merged into Gambit's main repo once they have been tested enough; libs is mostly for work-in-progress stuff.
It will be easier if that was a draft pull-request against gambit repository. It will help with discovery and it will also take advantage of gambit repository Continuous Integration.
E) Can someone add a dummy test for a dummy library so that I can see how to run recent gambit with R7RS? Here is an example of such thing: https://github.com/amirouche/arew-scheme/blob/master/src/tests-tests.scm
Gambit has a build-in test framework but I haven't used it yet. We also plan to implement SRFI 64 (A Scheme API for test suites) using the built-in framework.
I don't like SRFI 64. It is impossible to run a single test with SRFI-64. I am looking forward an introspection or reflection library system (something like guile or chez does) so that it is possible to run a single test where a test are procedures.
See `library-exports` at https://github.com/amirouche/arew-scheme/blob/master/make-check.scm#L22
I already tried to use SRFI-64, at the very minimum it requires to wrap `test-fu` forms inside a procedure like chibi scheme does.
A lot of SRFIs don't have many tests. It might be nice to gather a big, up-to-date test suite for all SRFIs.
Or keep up-to-date tests in each SRFI's repo with the sample implementation.
That will be nice.
The problem with updating test in SRFI sample implementations is that we would probably need permission from each SRFI's author, and we probably can't reach most of them to approve new code. Some popular SRFIs are almost 20 years old.
It might be good for Scheme implementors to create a common test repo on GitHub or GitLab and gather tests for lots of different SRFIs there. It would also be an opportunity to use the same testing framework for all of them. I'll start a thread about this on srfi-dicsuss.
the SRFI is the documentation.
We already discussed that matter in SRFI schemedoc mailing list. We disagree. In my opinion, SRFI documents are not user documentation. Simply refering gambit user to the SRFI document is not good enough. A proper implementation documentation will need examples uses, a useable comment system. And also systematic documentation of all forms. Unlike some SRFI document like (scheme mapping) aka. SRFI-146 that bolt together (scheme mapping) and (scheme mapping hash) together (see https://srfi.schemers.org/srfi-146/)
Those are good points. Perhaps it would be better to rely on a Scheme-wide documentation site for this stuff instead of Gambit (and every other Scheme) having its own detailed documentation for each SRFI. It would take a lot of effort and pressure off Scheme implementors.
The https://clojuredocs.org/ and https://www.php.net/ facility where users can post comments to supplement the official documentation is nice. Perhaps a Wiki would be even better. The https://srfi-email.schemers.org/schemedoc/ list is probably the best place to discuss this.
Most of the SRFI implementations from udem-dlteam/libs will probably be merged into Gambit's main repo once they have been tested enough; libs is mostly for work-in-progress stuff.
It will be easier if that was a draft pull-request against gambit repository. It will help with discovery and it will also take advantage of gambit repository Continuous Integration.
They're in a separate repo instead of a PR so we can do:
gsi -:whitelist=github.com/udem-dlteam/libs
A GitHub pull request corresponds to a Git branch in someone's fork of the Gambit repo. In principle, the module system ought to be able to download that branch instead of the master branch. I don't know whether anyone has tried this.
Gambit's CI builds all of Gambit (gsc and gsi) which does quite a bit more work than just building some SRFI implementations. Eventually, once the SRFI implementations are optimized for Gambit, it makes sense to build them with Gambit and rely on the CI.
I don't like SRFI 64. It is impossible to run a single test with SRFI-64. I am looking forward an introspection or reflection library system (something like guile or chez does) so that it is possible to run a single test where a test are procedures.
That probably doesn't require reflection; just a command-line flag for the test runner to specify which tests to run or which to skip.
Reflection would probably help with running tests in a running gsi from Emacs using Geiser.
SRFI 64 is popular so we should to have it. That doesn't mean we can't have other APIs as well. For example, (chibi test) is also popular so it would be good to have. It's best if all these different test APIs can be implemented using Gambit's native API.
See `library-exports` at https://github.com/amirouche/arew-scheme/blob/master/make-check.scm#L22
I already tried to use SRFI-64, at the very minimum it requires to wrap `test-fu` forms inside a procedure like chibi scheme does.
Not sure what to do about this.
Trying with tab completion in gsi, Gambit already has things like:
##procedure? ##procedure-friendly-name
as well as the ##symbol-table used in the apropos. You might be able to put something together using the primitives that are already there.
how to run recent gambit with R7RS?
Here's a hello world: https://github.com/gambit/hello
It can be run with:
gsi -:r7rs github.com/gambit/hello
That command will download the module into ~/.gambit_userlib/ (if it isn't there already) and then run it.
There's also a graphical demo that relies on Xlib and pkg-config:
gsi -:r7rs github.com/gambit/xlib/demo
The -:r7rs flag puts Gambit in R7RS mode (instead of the native Gambit mode). It's not required for the above examples; the native mode works too. Try `gsi -:help` (and separately, `gsi -help` and `gsc -help`) for more about the available options.
On Nov 2, 2019, at 3:39 AM, Amirouche Boubekki amirouche.boubekki@gmail.com wrote:
Hello all!
Can some brush me up about the R7RS libraries effort in Gambit?
I stumbled upon https://github.com/udem-dlteam/libs/ but:
That repo hosts the WIP for creating libraries to be added to the libraries in the Gambit system. At the moment it is mainly for porting existing SRFIs. You are welcome to contribute!
A) There is no tests
It is important for any module to have tests, and the current absence of tests is something to fix. Gambit now has a testing module called _test that is convenient for such tests. Each module “foo” should have a submodule “test” that contains the tests. This is only a convention… there’s nothing specific about that structure that the Gambit system knows about. But it makes for easy testing by adding “/test” at the end of a module reference.
Here’s an example for the github.com/gambit/hello library:
% gsi github.com/gambit/hello/test@2.1 % echo $? 0 % cat ~/.gambit_userlib/github.com/gambit/hello/@2.1/test.scm (define-library (github.com/gambit/hello test)
(import (.. hello)) ;; relative import (preserves the version) (import (_test)) ;; for check-equal? and check-tail-exn (import (gambit)) ;; for lambda, with-output-to-string, and ;; wrong-number-of-arguments-exception?
(begin
(check-equal? (with-output-to-string (lambda () (hi "you"))) "hello you!\n")
(check-equal? (with-output-to-string (lambda () (salut "hi"))) "bonjour hi!\n")
(check-tail-exn wrong-number-of-arguments-exception? (lambda () (hi)))
(check-tail-exn wrong-number-of-arguments-exception? (lambda () (hi "foo" "bar")))))
B) There is no doc
I’m open to suggestions…
C) The layout of the repository is as far as I can tell:
libs/srfi/1/1.sld
That would me that srfi 1 is importable with:
(import (srfi 1 1))
which looks odd. Maybe I misunderstood something.
There are two possible mappings from a module reference to a file system path. The module search algorithm will take the module reference “foo/bar” and look for the following files in the module search order (the list of directories searched by default are ~~lib and ~~userlib):
foo/bar/bar.sld (or .scm or .six) foo/bar.sld (or .scm or .six)
This allows using a nested layout (with a specific directory for module foo/bar) and a flat layout (where foo directly contains the files foo.sld, bar.sld and possibly other submodules of foo).
Sometimes a nested layout is good, but sometimes it is overkill (many directories containing a single file so the flat layout can be used if the programmer thinks this is appropriate).
D) There is not (scheme fu) libraries
These are part of Gambit now. Try:
% gsi -e '(let () (namespace ("void#") ("" import)) (display "hello!\n"))' *** ERROR IN (string)@1.44 -- Unbound variable: void#display % gsi -e '(let () (namespace ("void#") ("" import)) (import (scheme write)) (display "hello!\n"))' hello! % cat lib/scheme/write/write.sld (define-library (scheme write)
(namespace "")
(export
display write write-shared write-simple
))
E) Can someone add a dummy test for a dummy library so that I can see how to run recent gambit with R7RS? Here is an example of such thing: https://github.com/amirouche/arew-scheme/blob/master/src/tests-tests.scm
See the github.com/gambit/hello example.
F) While I am at it, does gambit new module system support introspection or reflection?
Depends what you mean… Gambit has hooks for… *everything*.
Marc
Thanks in advance!
-- Amirouche ~ https://hyper.dev
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list
Le sam. 2 nov. 2019 à 15:20, Marc Feeley feeley@iro.umontreal.ca a écrit :
On Nov 2, 2019, at 3:39 AM, Amirouche Boubekki amirouche.boubekki@gmail.com wrote:
Hello all!
Can some brush me up about the R7RS libraries effort in Gambit?
I stumbled upon https://github.com/udem-dlteam/libs/ but:
That repo hosts the WIP for creating libraries to be added to the libraries in the Gambit system. At the moment it is mainly for porting existing SRFIs.
It is not clear how yet-another-repository will help.
You are welcome to contribute!
I plan to do so.
A) There is no tests
It is important for any module to have tests, and the current absence of tests is something to fix. Gambit now has a testing module called _test that is convenient for such tests. Each module “foo” should have a submodule “test” that contains the tests. This is only a convention… there’s nothing specific about that structure that the Gambit system knows about. But it makes for easy testing by adding “/test” at the end of a module reference.
Here’s an example for the github.com/gambit/hello library:
% gsi github.com/gambit/hello/test@2.1 % echo $? 0 % cat ~/.gambit_userlib/github.com/gambit/hello/@2.1/test.scm (define-library (github.com/gambit/hello test)
(import (.. hello)) ;; relative import (preserves the version) (import (_test)) ;; for check-equal? and check-tail-exn (import (gambit)) ;; for lambda, with-output-to-string, and ;; wrong-number-of-arguments-exception?
(begin
(check-equal? (with-output-to-string (lambda () (hi "you"))) "hello you!\n") (check-equal? (with-output-to-string (lambda () (salut "hi"))) "bonjour hi!\n") (check-tail-exn wrong-number-of-arguments-exception? (lambda () (hi))) (check-tail-exn wrong-number-of-arguments-exception? (lambda () (hi "foo" "bar")))))
Thanks!
B) There is no doc
I’m open to suggestions…
I have an idea. I will raise the issue later on schemedoc. What we could do, is have a common documentation that can be "translated" into each implementation using gettext.
C) The layout of the repository is as far as I can tell:
libs/srfi/1/1.sld
That would me that srfi 1 is importable with:
(import (srfi 1 1))
which looks odd. Maybe I misunderstood something.
There are two possible mappings from a module reference to a file system path. The module search algorithm will take the module reference “foo/bar” and look for the following files in the module search order (the list of directories searched by default are ~~lib and ~~userlib):
foo/bar/bar.sld (or .scm or .six) foo/bar.sld (or .scm or .six)
This allows using a nested layout (with a specific directory for module foo/bar) and a flat layout (where foo directly contains the files foo.sld, bar.sld and possibly other submodules of foo).
Sometimes a nested layout is good, but sometimes it is overkill (many directories containing a single file so the flat layout can be used if the programmer thinks this is appropriate).
D) There is not (scheme fu) libraries
These are part of Gambit now. Try:
% gsi -e '(let () (namespace ("void#") ("" import)) (display "hello!\n"))' *** ERROR IN (string)@1.44 -- Unbound variable: void#display % gsi -e '(let () (namespace ("void#") ("" import)) (import (scheme write)) (display "hello!\n"))' hello! % cat lib/scheme/write/write.sld (define-library (scheme write)
(namespace "")
(export
display write write-shared write-simple
))
E) Can someone add a dummy test for a dummy library so that I can see how to run recent gambit with R7RS? Here is an example of such thing: https://github.com/amirouche/arew-scheme/blob/master/src/tests-tests.scm
See the github.com/gambit/hello example.
Thanks!
F) While I am at it, does gambit new module system support introspection or reflection?
Depends what you mean… Gambit has hooks for… *everything*.
I will do with what I know for the time being.
On Nov 3, 2019, at 10:28 AM, Amirouche Boubekki amirouche.boubekki@gmail.com wrote:
Le sam. 2 nov. 2019 à 15:20, Marc Feeley feeley@iro.umontreal.ca a écrit :
On Nov 2, 2019, at 3:39 AM, Amirouche Boubekki amirouche.boubekki@gmail.com wrote:
Hello all!
Can some brush me up about the R7RS libraries effort in Gambit?
I stumbled upon https://github.com/udem-dlteam/libs/ but:
That repo hosts the WIP for creating libraries to be added to the libraries in the Gambit system. At the moment it is mainly for porting existing SRFIs.
It is not clear how yet-another-repository will help.
It would be possible to work with pull-requests to directly add modules to the lib directory of the Gambit repo. However this does not help people collaborate on writing “work-in-progress” modules.
The Gambit repo has a limited number of people with write access, and I’d like to keep it that way so that users of Gambit are more comfortable trusting the software’s quality.
I had considered hosting the libs repo under github.com/gambit (with a wider set of collaborators with write-access for that repo) but that is a problem because github.com/gambit is in Gambit's whitelist, so any module on github.com/gambit will be installed without asking the user for confirmation (because those modules are trusted). That would be a security hole.
By putting the WIP modules in github.com/udem-dlteam/libs it is possible to easily test WIP code like this:
gsi -:whitelist=github.com/udem-dlteam/libs -e "(import (github.com/udem-dlteam/libs gambit optionals)) (let-optionals* (list 1) ((a 0) (b 9)) (pp (+ a b)))"
An alternative approach would be to use a repo in github.com/gambit with a repo name containing a “.”. Module names can’t contain “.” so there is no risk that they would be automatically installed by Gambit. Unfortunately, they can’t be explicitly installed either, so it would make development tedious (it would require manual invocations of git to explicitly pull the code).
Does using a separate repo for module development cause you problems?
Marc
Le dim. 3 nov. 2019 à 17:13, Marc Feeley feeley@iro.umontreal.ca a écrit :
On Nov 3, 2019, at 10:28 AM, Amirouche Boubekki amirouche.boubekki@gmail.com wrote:
Le sam. 2 nov. 2019 à 15:20, Marc Feeley feeley@iro.umontreal.ca a écrit :
On Nov 2, 2019, at 3:39 AM, Amirouche Boubekki amirouche.boubekki@gmail.com wrote:
Hello all!
Can some brush me up about the R7RS libraries effort in Gambit?
I stumbled upon https://github.com/udem-dlteam/libs/ but:
That repo hosts the WIP for creating libraries to be added to the libraries in the Gambit system. At the moment it is mainly for porting existing SRFIs.
It is not clear how yet-another-repository will help.
It would be possible to work with pull-requests to directly add modules to the lib directory of the Gambit repo. However this does not help people collaborate on writing “work-in-progress” modules.
The Gambit repo has a limited number of people with write access, and I’d like to keep it that way so that users of Gambit are more comfortable trusting the software’s quality.
[...]
Does using a separate repo for module development cause you problems?
Nevermind, I can work it out.