<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 16 Oct 2015, at 14:06, Robert Withers <<a href="mailto:robert.w.withers@gmail.com" class="">robert.w.withers@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">On 10/16/2015 07:58 AM, Esteban Lorenzano wrote:</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class="">On 16 Oct 2015, at 13:53, Esteban Lorenzano <<a href="mailto:estebanlm@gmail.com" class="">estebanlm@gmail.com</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 16 Oct 2015, at 13:22, Robert Withers <<a href="mailto:robert.w.withers@gmail.com" class="">robert.w.withers@gmail.com</a>> wrote:<br class=""><br class="">Bonjour Stef,<br class=""><br class="">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:<br class=""></blockquote><br class="">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.<br class=""><br class=""><blockquote type="cite" class="">- will existing NB syntax require change with the introduction of a MTVM?<br class=""></blockquote><br class="">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.<br class=""><br class="">now we have:<br class=""><br class="">nbCall:module:<br class=""><br class="">to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep old notation some versions to provide backward compatibility)<br class=""><br class="">So I can imagine an API like this:<br class=""><br class="">ffiAsyncCall:callback:module:<br class=""><br class="">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) :)<br class=""></blockquote><br class="">Actually I just remembered that current prototype works attaching external call with an internal Process (with some special id inside).<br class="">But still, I do not expect call syntax will change at all.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Are you saying all FFI callouts would become threaded or would there be an unthreaded callout and a threaded callout? I was assuming the second scenario.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>I’m saying *the syntax* will not change. That means, if you want to call memcpy, syntax will still be: #(void *memcpy ( void* dest, void *src))</div><div><br class=""></div><div>what can (and will) change is the method invoking it… ffiCall:module: vs. ffiAsyncCall:callback:module: </div><div><br class=""></div><div>Esteban</div><br class=""><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Robert</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">Esteban<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">- to what degree will NB syntax need to be extended to support threaded callouts.<br class=""></blockquote><br class="">as described, I suppose. No exact idea until we implement.<br class=""><br class=""><blockquote type="cite" class="">- what NB syntax changes are needed for callbacks.<br class=""></blockquote><br class="">NB used some magic there. Shadow classes and etc. We do not need/want that anymore.<br class=""><br class="">now you have a new FFICallback api, where you can do:<br class=""><br class="">FFICallback<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>signature: #(int (int handle, int *pitch, int x, int y, int w, int h))<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>block: [ :handle :pitch :x :y :w :h |<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>pitch signedLongAt: 1 put: (self get_stride: handle).<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>self get_data: handle ]<br class=""><br class="">(I extracted that example from my ongoing port of Athens)<br class=""><br class=""><blockquote type="cite" class="">- timing: when is MTVM expected and can we operate on the leading edge?<br class=""></blockquote><br class="">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).<br class=""><br class="">So… my plan is:<br class=""><br class="">- NB to FFI port (should be ready soon)<br class="">- spur32 bits (should be ready soon, we are just waiting the NB to FFI)<br class="">- spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo)<br class="">- 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...<br class="">- FFI MT<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">hope this helps<br class=""><br class="">Esteban<br class=""><br class=""><blockquote type="cite" class=""><br class="">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.<br class=""><br class="">Regards,<br class="">Robert<br class=""><br class="">On 10/16/2015 06:59 AM, stepharo wrote:<br class=""><blockquote type="cite" class=""><br class="">In pharodays presentations we explictly mentioned our strategy:<br class=""> - we keep NB syntax<br class=""> - we change the assembly generation to be able to get Spur.<br class=""><br class="">Stef<br class=""><br class="">I can tell you that if I could get a lua kind of jit now I would sign<br class="">immediately and also for having pharo as a dll.<br class="">Now it takes time to do soemthing.<br class=""><br class="">Le 15/10/15 17:35, Robert Withers a écrit :<br class=""><blockquote type="cite" class=""><br class="">I am reticent to invest in learning FFI that is changing without an idea<br class="">of the direction of the change. So</blockquote></blockquote></blockquote></blockquote></blockquote></div></blockquote></div><br class=""></body></html>