On 16 Oct 2015, at 13:22, Robert Withers <[email protected]> wrote:
Bonjour Stef,
I believe the change everyone would be waiting for is a Multi-threaded VM, that
supports threaded callouts and callbacks. So I suppose the questions become:
multi thread ffi vm exists as a prototype, and according to its author (Eliot)
needs no less than 4 months of someone skilled working on it to finish it.
- will existing NB syntax require change with the introduction of a MTVM?
nothing will be equal… why? because you will need to provide callbacks. There
is no magic here, if you want something to happen while doing something else,
you need to provide a way to be called back when that thing finishes.
now we have:
nbCall:module:
to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep
old notation some versions to provide backward compatibility)
So I can imagine an API like this:
ffiAsyncCall:callback:module:
So yes… you need change. But that’s inevitable… Of course you can do a fwk
forking in image and starting a continuation, etc. But well, I will let you
guys to think on that (also you still will need the fork) :)
- to what degree will NB syntax need to be extended to support threaded
callouts.
as described, I suppose. No exact idea until we implement.
- what NB syntax changes are needed for callbacks.
NB used some magic there. Shadow classes and etc. We do not need/want that
anymore.
now you have a new FFICallback api, where you can do:
FFICallback
signature: #(int (int handle, int *pitch, int x, int y, int w,
int h))
block: [ :handle :pitch :x :y :w :h |
pitch signedLongAt: 1 put: (self get_stride: handle).
self get_data: handle ]
(I extracted that example from my ongoing port of Athens)
- timing: when is MTVM expected and can we operate on the leading edge?
we are lacking resources: Is just me (in the Pharo part, of course… Eliot and
some others work also in the exclusively VM part, but they have other agendas).
So… my plan is:
- NB to FFI port (should be ready soon)
- spur32 bits (should be ready soon, we are just waiting the NB to FFI)
- spur64 bits (Eliot is working on the JIT, I need to manage the migration of
Pharo)
- FFI 64bits (0% done here… just some stubs waiting for effort). But we want to
move Pharo to 64bits… we are losing a train here...
- FFI MT
So… not very hight priority. According as how I see things now, I *think* I can
have that some point of 2017… yes, as far as that. Also because I have a lot
other stuff to do, not just the lowlevel parts.
Of course this is not good and we have talked with some people to speed up
this. We talked with Igor about taking the MT stuff (yes, we also believe is
VERY important), but he fade in the blur… I didn’t hear from him since 3 months
(I’m still waiting for some feedback on OSWindow work he did, he)… yes I’m a
bit frustrated.
If *anyone* wants to collaborate in any part of this list (is a MASSIVE
effort), I would be very happy and willing to provide as much
assistance/guiding/peer programming as I can.
hope this helps
Esteban
Personally, in SqueakElib, I have my network and session layers working for
encrypted connections, so I just have the presentation layer to go. Once done,
I would be very interested in working in the VM with whomever is also
interested with an eye towards threading (MTVM). I am no expert here so it will
be a challenge I am looking forward to.
Regards,
Robert
On 10/16/2015 06:59 AM, stepharo wrote:
In pharodays presentations we explictly mentioned our strategy:
- we keep NB syntax
- we change the assembly generation to be able to get Spur.
Stef
I can tell you that if I could get a lua kind of jit now I would sign
immediately and also for having pharo as a dll.
Now it takes time to do soemthing.
Le 15/10/15 17:35, Robert Withers a écrit :
I am reticent to invest in learning FFI that is changing without an idea
of the direction of the change. So
