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
Marc Feeley
@feeley
_r0 = return address, _r1 = return value (and parameter #1), _r2 = parameter #2, ...
Drew Crampsie
@drewc
Ok, that makes sense. So when setting _r0 to null (for the browser) that says to the VM that we are not trying to return a value or something similar so that on loading the JS object file it does not get confused, then setting it back to where is was, while setting the return to the vector we actually want to return and jumping on the trampoline, reinstates that aspect and picks up where we left off?
Which must now be to run the init function of the _module_latest_registered which is why it is returned that way? ... must go look at the code again!
Drew Crampsie
@drewc
Awesome, that makes things clear. Yay Gambit!
drewc @drewc does another happy dance
salotz
@salotz:matrix.org
[m]

all highly evolved living things need a heatbeat...

I will not take this anti-vegetable slander lying down!!

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.