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
adam-7
@adam-7

@feeley Dear Marc, just curious how are C/C++ atomics kind of functionality done in Scheme?

Say you want to |set!| a variable in Gambit processor A, in such a way that Gambit processor B when it sees that variable, is guaranteed to see all of its contents.

Do you have an |atomic-set!| or such variant of |set!| that will have that guarantee, a la C/C++ atomics?

(This in practice will only be of concern on weakly ordered architectures as in ARM64 and is it RISCV.)

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.