Thank you for your response, Ben. I'm here to help where I may be helpful, so let me know where. I have interest in the Pi and the ARM simulator was expressed as an area needing more resources. 64-bit is the strategic effort, so if I can help.
I'd hope we could agree that whether is goes 64-bit then MT (which is what's up) or MT then 64-bit (as I was so rashly suggesting) there will be an integration cost. As 64-bit is a Spur ObjectMemory effort and MT is a process/stack oriented facet, are they not orthogonal and fairly non-interfering, aside from a few touch points. If there is integration cost, why not proceed in parallel? Certainly the discussion about what exactly MT is seems alright.
I'm guessing the answer to that you have mentioned: resources. We need a bunch of hardcore CompSci students to catch the fire.
Please let me know where I can help best. Rapport is key to team, this I have experienced.
As well, thanks so much for those links! Those are gold and will be reread recursively.
Regards, Robert
On 10/18/2015 11:56 AM, Ben Coman wrote:
On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers robert.w.withers@gmail.com wrote:
Yes, exactly. I do realize I was consciously changing that effort synchronization order.
I see 64-bit being higher priority than multi-threaded for the wider community. Dealing with larger in-Image data opens the door to more corporate project/funding opportunities. Also simplifying the install on modern Linux platforms without requiring additional 386 libraries will help acceptance there.
It is my humble opinion, without really knowing, that 64-bit would have to be redone after the MTVM completes.
I would assume it was the other way around. Presuming that Eliot has sponsors influencing his priorities, it seems given that 64-bits will happen first. I would guess any MTVM development on the old vm would then need to be reworked.
I was doing so with the idea in mind that I and others might dig into working on the VM, for threading support, while Eliot maintains focus on 64-bits...a tall order, I know.
The usual downside of splitting resources applies. There are not that many "others" and maybe they would be drawn away from helping with the 64-bit vm. If the 64-bit vm goes slower for lack of resources then your footing for MTVM will shifting for a longer time. You may ultimately get where you want to go faster by helping with the 64-bit vm. The rapport built with other vm devs from working on 64-bit might could then be applied to MTVM. (Of course, its your free time, so you should pursue what interests you.)
I was barely familiar with the VM, slang, interpreter, it years ago... I'm totally unfamiliar with cog.
The experience you gain from working beside Esteban and Eliot on 64-bit Cog/Spur could then be applied to a MTVM.
btw, you may find these threads interesting...
- http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-April/108648...
- http://forum.world.st/Copy-on-write-for-a-multithreaded-VM-td4837905.html
cheers -ben
I believe another item on that list ought to be modernizing slang. So many big items!
Robert
On 10/16/2015 12:48 PM, Stephan Eggermont wrote:
On 16-10-15 14:05, Robert Withers wrote:
Because of that assumption I've made and without the responsibilities you have, Esteban, but recognizing modernizing NB to FFI, my desired list is:
I would expect the least total effort to be needed by keeping the work of Esteban and Eliot as much as possible aligned. That is what Esteban's list achieves.
Stephan