Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 00:41
    Negdayen opened #704
  • Jun 16 18:45
    Windows-mingw build of CI run 943876964 failed
  • Jun 16 18:25

    feeley on master

    Read the form [1 2 3] as (|[...… (compare)

  • Jun 16 03:52
    Windows-mingw build of CI run 941489732 failed
  • Jun 16 03:39
    feeley commented #703
  • Jun 16 03:27

    feeley on master

    Implement SRFI 2: and-let* Compile SRFI 2 & SRFI 26 expand… Merge pull request #703 from Ne… (compare)

  • Jun 16 03:27
    feeley closed #703
  • Jun 16 02:47
    Negdayen synchronize #703
  • Jun 16 02:43
    Negdayen synchronize #703
  • Jun 13 13:31
    Negdayen opened #703
  • Jun 12 17:16
    CI run 931553101 passed
  • Jun 12 16:37
    feeley commented #700
  • Jun 12 16:37

    feeley on master

    Implement SRFI 26: Notation for… Merge branch 'master' into srfi Merge pull request #700 from Ne… (compare)

  • Jun 12 16:37
    feeley closed #700
  • Jun 12 07:29
    lassik commented on 1502a21
  • Jun 12 06:18
    lassik opened #702
  • Jun 12 01:02
    gambiteer commented on 1502a21
  • Jun 12 01:00
    gambiteer commented on 1502a21
  • Jun 11 22:28
    Windows-mingw build of CI run 929941762 failed
  • Jun 11 22:00

    feeley on master

    Explain ## identifiers in manual Fix according to review Add big table of type specifiers and 2 more (compare)

adam-7
@adam-7
Note that the atomic mutator primitive would not only have a memory barrier kind of function (as in expand to (##mbarrier) (set! x y)), BUT also have the effect on Gambit's compiler, to prohibit compiler optimizations to reorder loads and stores in such a way that they would switch side of the |atomic-set!|
adam-7
@adam-7
@gcartier just curious ##wr-set! does what?
Marc Feeley
@feeley
@gcartier it sets ##wr to the procedure that is called by write, display, etc
Marc Feeley
@feeley

@adam-7 The atomicity of reading/writing Scheme variables is not yet clear. However there are atomic operations on vectors: vector-inc! (increment an element) and vector-cas! (compare and swap):

> (define v (vector 5))
> (vector-inc! v 0)     
5
> (vector-inc! v 0)
6
> v
#(7)
> (vector-cas! v 0 'foo 42) 
7
> v
#(7)
> (vector-cas! v 0 'foo 7) 
7
> v
#(foo)

The first two parameters of these procedures are the vector and the index of the element. vector-inc! increments the element (which must be a fixnum) and returns the value before incrementation. vector-cas! will compare the element with the fourth parameter and will set it to the third parameter if they are eq?. The previous content of the element is returned. So you can use (vector-cas! v i #f #f) as an atomic (vector-ref v i).

Guillaume Cartier
@gcartier
@adam-7 I use ##wr to custom print some define-type
Marc Feeley
@feeley
@gcartier sorry I should have mentionned @adam-7...
Guillaume Cartier
@gcartier
@feeley hey! No worries
drewc @drewc <3's _os_load_object_file, that is exactly the logic he needed to see for _r0 and _r1 and he pretends he now knows what they register :P
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)