Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 22 22:54
    Negdayen closed #635
  • Jun 22 14:05
    Windows-mingw build of CI run 960844950 failed
  • Jun 22 13:40
    feeley commented #708
  • Jun 22 13:40

    feeley on master

    Fix gai_code_to_string type err… Add missing .gitignore paths Merge pull request #708 from Ne… (compare)

  • Jun 22 13:40
    feeley closed #708
  • Jun 20 03:14
    Negdayen synchronize #708
  • Jun 20 03:09
    Negdayen synchronize #708
  • Jun 20 03:07
    Negdayen synchronize #708
  • Jun 20 01:11
    Negdayen synchronize #708
  • Jun 19 20:13
    Negdayen opened #708
  • Jun 19 06:19
    lassik commented #707
  • Jun 19 06:13
    lassik opened #707
  • Jun 18 20:59
    gambiteer commented #706
  • Jun 18 14:27
    lassik commented #706
  • Jun 18 14:23
    Negdayen opened #706
  • Jun 18 10:51
    Windows-mingw build of CI run 949544601 failed
  • Jun 18 10:30

    feeley on master

    Fix documentation for index-ran… Merge pull request #702 from la… (compare)

  • Jun 18 10:30
    feeley closed #702
  • Jun 18 10:05
    lassik synchronize #705
  • Jun 18 09:45
    lassik opened #705
Drew Crampsie
@drewc
They breathe, but are heartless ... I think I know some vegetables personally! Cellular respiration does not require a heart, just a sunny day.
Drew Crampsie
@drewc
drewc@nyx:~/me/src/gxjs/packages/gambit-scheme]$ node
Welcome to Node.js v12.18.4.
Type ".help" for more information.
> const VM = require('gambit-scheme');
undefined
> let foo = () => { console.log ('host function runs here!') }, bar = _host2scm(foo)
undefined
> _g['run-me-now!'] = bar ; VM.runProcedure = 'run-me-now!'
'run-me-now!'
> host function runs here!
> baz = _scm2host(_g['run-me-now!']); baz();
host function runs here!
Promise { undefined }
>
drewc @drewc has threads working well and thanks you for it :)
drewc @drewc also has minimization working wonderfully:
Drew Crampsie
@drewc
[drewc@nyx:~/me/src/gxjs/packages/gambit-scheme]$ ./bin/gsi.js 
Gambit v4.9.3

> (time (fib 20))
(time (fib 20))
    0.014000 secs real time
    0.014000 secs cpu time (0.014000 user, 0.000000 system)
    no collections
    no bytes allocated
    no minor faults
    no major faults
6765
> ,q

[drewc@nyx:~/me/src/gxjs/packages/gambit-scheme]$ du ./bin/gsi.js 
3100    ./bin/gsi.js
13 replies
 gzip -9 bin/gsi.js 

[drewc@nyx:~/me/src/gxjs/packages/gambit-scheme]$ du ./bin/gsi.js.gz 
664     ./bin/gsi.js.gz
not quite 640k, but close enough :)
Jaime Fournier
@ober
wow
amirouche
@amirouche
Re JavaScript target: How can I disable the behavior that will resolve JavaScript promises implicitly? I want that because I want to run concurrently several fetch? Maybe there is another way to do that with threads?
Marc Feeley
@feeley
@amirouche just wrap the result in foreign(…promise-value…) and this will disable the automatic conversion… on the Scheme side you will get a Gambit foreign object, and when you pass that back to JS the automatic conversion will give the original promise value (you can think of the JS foreign function as a boxing operation)
amirouche
@amirouche
Thanks a lot!
Jürgen Geßwein
@jgesswein
How to debug loading of libraries? I’m loading a number of libraries (using define-library) and loading those libraries takes about two minutes. gsi has 100% CPU. It opens file «.» a lot before actually opening the library files.
Marc Feeley
@feeley
@jgesswein try:
gsi -e "(##debug-modules?-set! #t)" srfi/132/test
Jürgen Geßwein
@jgesswein
An excerpt of the output is below (too big to paste…). It seems that it tries to open a number of files multiple times. This slows down loading of libraries. I’ll try to do the same with my case but this will probably yield something enormous…
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.six")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.six")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.six")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.six")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.six")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.six")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.sld")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.scm")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/_test/test-expand/test-expand.six")
Jürgen Geßwein
@jgesswein

The following sequence occurs for each and every module. Why is library (gambit) resolved more than once? This seems to be the case for my modules as well. If two libraries depend on the same library it is checked (also loaded?) twice.

(try-opening-source-file "/Users/juergen/Documents/project/./gambit/gambit.sld")
(try-opening-source-file "/Users/juergen/Documents/project/./gambit/gambit.scm")
(try-opening-source-file "/Users/juergen/Documents/project/./gambit/gambit.six")
(try-opening-source-file "/Users/juergen/Documents/project/./gambit.sld")
(try-opening-source-file "/Users/juergen/Documents/project/./gambit.scm")
(try-opening-source-file "/Users/juergen/Documents/project/./gambit.six")
(try-opening-source-file "/usr/local/Gambit/v4.9.3/lib/gambit/gambit.sld")

The output in my case is 36MB.

Marc Feeley
@feeley
there are several attempts because for an (import (gambit)) the system does not know if the module is in a .sld file or .scm … and if it is in a subdirectory of the same name or not, moreover all directories in the module search order need to be checked
also there is no library definition caching in the import implementation… that is due to the presence of macros which complicate things (a macro could be defined to have a behavior that depends on some state or previous calls to the macro). So caching library definitions could change the behavior of these macros.
Jürgen Geßwein
@jgesswein
Checking this is once is fine. But the system seems to resolve (gambit) for each library again. This is not needed, right? If the library is found, it is the same library for all libraries currently handled.
Marc Feeley
@feeley
no… the module search order could be changed by a macro (I’m not saying this is a good idea… just that caching will change this “feature”)
Jürgen Geßwein
@jgesswein
Ah. Can we get a switch that disables this behaviour? Similar to what we have for the bindings. I think in 99% of the cases there is no macro changing library stuff.
Marc Feeley
@feeley
another problem with caching is that the heap will fill up with module definitions that are possibly not needed in the future… if the module definition is read from the filesystem every time it is needed there is no space leak
Jürgen Geßwein
@jgesswein
All true. But two minutes waiting to load all module is also an argument…
Marc Feeley
@feeley
also… if you compile your program then all of the processing of the module definitions is done by the compiler, so you will not see a run time hit
yes I agree with you that there is a problem… I’m just saying there are issues with adding a cache
Jürgen Geßwein
@jgesswein
All the libraries are compiled. Each has its own dynamic library. Only the main application is not compiled as it is a script for now.
Marc Feeley
@feeley
please add an issue on the github repo… this is definitely something that will hinder using the module system
Jürgen Geßwein
@jgesswein
May be I do something wrong with compiling libraries? Current I build the libraries using «gsc . path/to/lib». This yields a dynamic library and a C file in a folder «path@gambit409003@C».
OK, I’ll add an issue.
Marc Feeley
@feeley
yes that is the correct way to compile a library… you can also install the library if you don’t want to specify . when you run the program (so that it can find the compiled libraries)
let me add that it might be useful to store the library definition in the compiled modules so that a program that is statically linked can do dynamic imports (as in (eval ‘(import …))) of the linked modules without having to go to the filesystem
Jürgen Geßwein
@jgesswein
Sounds good. I need some more advice on how to do that. Currently I am not building a statically linked application as compiling takes also quite some time… ;-)
Marc Feeley
@feeley

the multiple imports of _test are due to the way the macros are written… for example test-equal is defined like this :

(##define-syntax test-equal       (lambda (src)
                                    (##import _test/test-expand)
                                    (test-expand src 'test-equal)))

so every call to test-equal will cause a import to be processed

clearly a cache would help, but maybe a rewrite of the macros would be sufficient
I suspect you have a program with a large number of tests...
Jürgen Geßwein
@jgesswein
Is 676 a large number? I am currently not using library _test but some home-grown stuff for historial reasons.
Marc Feeley
@feeley
sorry my analysis is wrong… the import is just done once per macro definition (not every macro call)
can I see your test library?
Jürgen Geßwein
@jgesswein
I’ll take a look at the 36MB file and give you some number on how often the libraries are loaded. You can then decide with more confidence on a cache.
Sure, why not. I drop you an e-mail. Is your university address OK?
Marc Feeley
@feeley
yes
36MB/676 is about 50KB per test… (if each test is generating some imports)… 50KB would be a lot!
Jürgen Geßwein
@jgesswein
Well that file is just for loading the libraries. The tests did not yet run. I create function with tests and run those functions. This allows for a progress bar.
Marc Feeley
@feeley
I see… but still each macro call may be causing some imports… and these are processed at macro expansion time (before execution)
Jürgen Geßwein
@jgesswein
I think I do not do this. But you may have a look at the module.
amirouche
@amirouche

Here is an extract from an article I am writing:

I experimented with Gambit JavaScript target, looked at the
benchmarks (but I did
not run them myself, yet), read on the Termite library that is inspired from
Erlang, and the upcoming Scheme Infix eXpression (SIX) already
available in master branch: In the years to come, Gambit Scheme
will become the goto programming stack for industrial use
. Here is
why:

  • Gambit Scheme is a Scheme;

  • Termite is what you need to build an application distributed in a
    controlled environnement, without requiring a change of programming
    language (see Erlang);

  • Gambit can also target the web browser;

Otherwise stated: we will be able to build full-stack applications
that can scale painlessly thanks to Termite, with a single great
programming language, the same compiler, and interpreter backend-side
and frontend-side.

Anyway, even if I am bit scared, I will try to use Gambit.
Jürgen Geßwein
@jgesswein
Something that also makes using the module system hard is that Gambit does not complain if a library contains identifiers that it cannot resolve. At least a warning would be helpful. Especially if an identifier in export is not defined.
amirouche
@amirouche
that is a known (by me) problem, and fwiw not the only one, for instance the module system requires to explicitly export dependent forms of a macro. And they are some things that may be trivial, but very great such as a directory contains all the files that defines the library unlike the foo.sld that includes foo/body.scm. Also, the ability to specify a git repository is great, it alleviates the need for a package management tool.
AFAIU it is possible to layer on top of Gambit the project called unsyntax (or fork) it support all macro systems (I will give it try at some point).