:)
more on this will be presented at the "Gambit at 30" meeting... for details see https://mailman.iro.umontreal.ca/pipermail/gambit-list/2019-July/009117.html
you can contact me if you are looking for presenters
I started working on the JavaScript backend, and keep updating the issue 404
The roadmap could be announced on the mailling list tho
That one mentions the missing syntax-rules, however I wouldn't necessarily go looking for that information inside the r7rs issue
there is one project but it is dated 2017
maybe we should go through the whole R7RS and create table and flag features that are done and those that are missing
even if the backend requires multi threads and gambit smp support is new
what I holding me back, was mostly the lack of R7RS library system
Does using wiredtiger mean you need smp?
I need that one "thread" doesn't block other threads, as concurrency issues are dealt with by wiredtiger.
@amirouche where is the blocking happening? if it is on a file descriptor then Gambit's green threads will be sufficient because the thread scheduler multiplexes the CPU so that Scheme threads waiting on a fd are put to sleep without blocking other threads. Scheme-level mutexes and condition variables also don't block other threads than the one blocking.
the main resource used is cpu
My first implementation was as Marc said to spawn an OS thread (a pthread in my case) and have the thread communicate “completion” by sending 1 byte down a named pipe. The named pipe is only read on the Gambit side where the Gambit thread will be blocked and only written on the C side. Later on, when porting to Windows where named pipes are a bit different and touchy to use, I tried replacing the named pipes by TCP sockets and tests showed performance to be identical as the OS clearly optimizes the special case of same machine (in this case even same process) communication. All this works very well for my needs and with it I can now play 80 movies at the same time on my mac (160 Gambit threads blocked on receiving codec data).
Hi Marc, I've noticed a few bugs in Not Emacs on iOS. Among others, there's no way to close the initial Help Window, you can't quit Scheme (pressing Ctrl-D several times doesn't work), and "yank from operating system" displays a window into which you can't paste text from other iOS applications. Furthermore, being able to open files from iCloud or DropBox would be a bonus. If I were a C/iOS programmer, I could probably fix those bugs myself, but I'm not. Can you help? Many thanks. Cheers, P
Hi, has anyone ever tried "spawn" on iOS? If so, was it stable?
@jazzscheme Yes there's a zlib implementation in pure Scheme in the bigloo source code. I used that to make a zlib snow ball many years ago. And now I've revived the code for the next release of Gambit. I also have a tar module.