- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Ben Coman

On Mon, Oct 19, 2015 at 7:55 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > 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. You may find these interesting... * http://forum.world.st/ARM-Cog-progress-td4827195.html * http://markmail.org/message/tfqa4lgriw6xchh3 * http://www.slideshare.net/esug/pharo-arm-status > 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. Agreed, but I guess the former shares that cost amongst more people. > 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? Naturally you'll get more support working in an area where the vm devs *need* more help, but I can't judge this. I'm not familiar with what the interference points might be. Maybe this helps... http://lists.squeakfoundation.org/pipermail/vm-dev/2014-October/016781.html > Certainly the discussion about what exactly MT is seems alright. Sure. MT has several meanings. Its good to scope a common understanding. > 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. I learn a lot listening in on [vm-dev], but I've still only dabbled around the fringe of the vm. The best reference is Eliot overall and Esteban from a Pharo perspective. btw, have you seen... * http://www.mirandabanda.org/cogblog/cog-projects/ cheers -ben > 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(a)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/10864… >> * >> 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

Oct. 19, 2015

Re: [Pharo-dev] Smalltalkhub projects not indexed?

by Levente Uzonyi

This is because for some unknown reason the creators of Smalltalkhub decided to use hashbang urls at a time when it was already considered bad practice to do so[1]. Crawlers can't crawl such pages, unless there are non-hashbang versions provided as well[2], but I strongly doubt Smalltalkhub has anything like that. Levente [1] http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs [2] https://developers.google.com/webmasters/ajax-crawling/docs/learn-more On Mon, 19 Oct 2015, Jan KurÅ¡ wrote: > Hi, > > I noticed that my projects on Smalltalkhub cannotÂ be googled :( I have project set up as a public, I actively develop and update the overview > page for several months, but even the query: smalltalkhub <myname> <nameOfMyProject> does not find anything. > > Is there a way to help this? > > Cheers, > Jan > >

Oct. 19, 2015

Smalltalkhub projects not indexed?

by Jan KurÅ¡

Hi, I noticed that my projects on Smalltalkhub cannot be googled :( I have project set up as a public, I actively develop and update the overview page for several months, but even the query: smalltalkhub <myname> <nameOfMyProject> does not find anything. Is there a way to help this? Cheers, Jan

Oct. 19, 2015

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Eliot Miranda

Hi Robert, _,,,^..^,,,_ (phone) > On Oct 19, 2015, at 5:03 AM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > Hi Esteban, > > >> On 10/19/2015 05:10 AM, Esteban Lorenzano wrote: >> >> Hi, >> >> just to be clear. >> When we talk about MTVM, we talk about a MT-FFI, *not* a MTVM in general. >> In general, a âcommonâ approach to MT cannot be applied in Pharo (or Smalltalk in general) and to get a VM *and* an image working properly is an effort that makes what I called massive some mails above like a small stone compared to a mountain. > > Could you please help me by talking further about the different models and scopes of what is meant by MT? > > a) MT-FFI I believe gives the developer a way to call and be invoked on callback, asynchronously. Is it so? It's a bit more than that. It is the sharing of the VM between different threads, but only allowing one thread to own the VM at any one time, changing ownership in call out or Smalltalk process switch time. This approach provides interleaved concurrency but not parallelism in your Smalltalk code and it means the Smalltalk class library doesn't have to be made thread-safe, which as Esteban said is a huge task. See http://lists.gforge.inria.fr/pipermail/pharo-project/2011-January/038943.ht… and google "eliot Miranda Simmons own thread" to find more messages. > b) General MTVM means other system services are threaded, like I/O events and scheduling and heartbeat. No; at least not in my opinion. In the standard single-threaded VM the heartbeat is ideally a thread (it can be an interval timer, but that's problematic; system calls get interrupted), and maybe an incremental global GC could be in its own thread. So I'm defining the MTVM to be the sharing of the VM between threads, and /not/ just the use of threads to implement non-Smalltalk sub tasks of the VM, and /not/ a full-blown multithreaded Smalltalk VM providing concurrent execution of Smalltalk processes in parallel. > I think that the right model (my stack/priQueue/pool intuition?) will change a Herculean task into a fairly straightfoward task and achievable. Change the problem, to get better answers. This has been well thought through and discussed. The definition above is very useful. It provides a system that can inter operate with concurrent code without having to implement a system that provides parallelism. It is used in David Simmons' VMs for S# etc and a similar (but less performant) scheme is available in Python VMs. Please, let's get this scheme working first. I'm not at all happy (read, extremely unhappy) that there is not much focus on working together to get our current VM to an excellent state and instead lots of work on other VMs that is speculative and a long way away from being production ready. We have a huge amount of work to do on Cog: - event-driven VM (that hence costs 0% processor time at idle) - 64-bits (x64 and ARM and...?) - Sista adaptive optimizer - FFI via dynamic generation of marshaling code, as required for efficient and correct call outs on x64 - MTVM as defined above - an incremental global mark-sweep GC for Spur - running on Xen/Unikernels/containers - providing a JavaScript plugin to proved rendering and events so we can run an efficient VM in a web browser - a port of the Interpreter/Context VM to Spur IMO, things that can /and should/ wait are - throwing away Slang and providing a true written-in-pure-Smalltalk VM that is self-bootstrapped a la Gerardo Richarte and Xavier Burroni - a truly parallel multi/threaded VM and things we shouldn't go anywhere near are - using libffi - targeting JavaScript, Java or any other dynamic language de jour that happens to run in a web browser but either provides abysmal performance or doesn't support full Smalltalk semantics - implementing the VM in other VM frameworks such as PyPy which simply strengthens that community and weakens our own Right now there are only a handful of people who make commits to the VM and three who are "full time", and we're all overloaded. But the VM is the base of the pillar and if we want to provide high-quality solutions that people will pay money to use we have to have a high-quality VM. In Spur we have a VM that is significantly faster that VW, and very reliable. In Sista we will have a system that is much faster and can be improved upon for years to come and a system that can migrate to future VMs (because it is mostly Smalltalk), and useful support for a high quality FFI. People like have stepped up and made significant contributions to give us what is a respectable VM that is on an arc to providing a really high-quality production Smalltalk VM written in Smalltalk produced by a very small community. But it is now 2015 and Cog started 7 years ago. All the work on other VMs, deployment platforms etc, IMO dilutes and delays in delivering to our community a truly world-class VM that we can compete with against Java HotSpot, node.js v8, lua luajit, factor, swift et al. Please get on board. We'd love the help and we can guarantee you'll have fun and you can guarantee you'll have an impact. > > I appreciate you and this MT discussion. > > >> Said that: >> >> - What is in plans is MT-FFI, and that will be available eventually. >> - There is an approach I want to re-work, that would allow us profit of multicores without going multithread: the âhydraâ experiment made some years ago by Igor creates a good basis to this. But is also a lot of of work (but a lot less than a complete MT), and not a real priority for nowâ¦ I hope to resume work on that area some dayâ¦ just not anytime soon. > > Yes, please. I recall those discussions. Hydra is cosmological. > > Regards, > Robert > >> >> Esteban >> >>> On 18 Oct 2015, at 17:56, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> >>> On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers >>> <robert.w.withers(a)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/10864… >>> * 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 >>

Oct. 19, 2015

Re: [Pharo-dev] [squeak-dev] The Trunk: System-mt.771.mcz

by Eliot Miranda

Hi Marcel, > On Oct 17, 2015, at 10:47 AM, commits(a)source.squeak.org wrote: > > Marcel Taeumel uploaded a new version of System to project The Trunk: > http://source.squeak.org/trunk/System-mt.771.mcz > > ==================== Summary ==================== > > Name: System-mt.771 > Author: mt > Time: 17 October 2015, 6:38:55.72 pm > UUID: 4aee8d76-cfcf-ad48-ae3e-6d971ce6fea9 > Ancestors: System-cmm.770 > > Log change stamps at the granularity of seconds not only minutes. > > Why? A minute is quite long and it is likely to have two method (versions) with the same timestamp. I think we should discuss this a bit further. This is all a soft touchy freely gut kind of thing for me: I don't like this change. I think the granularity for time stamps needs to differentiate versions in different package commits. Within an image versions can be distinguished by their order in the changes file (the previous source position, can't remember what that's called and I'm on my phone). So there's no real need for fine granularity. One could also say that a second is a long time if one is auto generating methods. I quite like being able to make several changes within the same minute because I can tell that they were related changes. With second granularity I have no chance. Do you have a programmatic reason for wanting second granularity? What to others think? Are there workflow implications to the granularity of time stamps? This is all very anal but, well, the changes file is all very anal anyway :-) I _,,,^..^,,,_ (phone)

Oct. 19, 2015

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Robert Withers

Hi Esteban, On 10/19/2015 05:10 AM, Esteban Lorenzano wrote: > > Hi, > > just to be clear. > When we talk about MTVM, we talk about a MT-FFI, *not* a MTVM in general. > In general, a âcommonâ approach to MT cannot be applied in Pharo (or Smalltalk in general) and to get a VM *and* an image working properly is an effort that makes what I called massive some mails above like a small stone compared to a mountain. Could you please help me by talking further about the different models and scopes of what is meant by MT? a) MT-FFI I believe gives the developer a way to call and be invoked on callback, asynchronously. Is it so? b) General MTVM means other system services are threaded, like I/O events and scheduling and heartbeat. I think that the right model (my stack/priQueue/pool intuition?) will change a Herculean task into a fairly straightfoward task and achievable. Change the problem, to get better answers. I appreciate you and this MT discussion. > Said that: > > - What is in plans is MT-FFI, and that will be available eventually. > - There is an approach I want to re-work, that would allow us profit of multicores without going multithread: the âhydraâ experiment made some years ago by Igor creates a good basis to this. But is also a lot of of work (but a lot less than a complete MT), and not a real priority for nowâ¦ I hope to resume work on that area some dayâ¦ just not anytime soon. Yes, please. I recall those discussions. Hydra is cosmological. Regards, Robert > > Esteban > >> On 18 Oct 2015, at 17:56, Ben Coman <btc(a)openInWorld.com> wrote: >> >> >> On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers >> <robert.w.withers(a)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/10864… >> * 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 >>>> >>>> >>> >

Oct. 19, 2015

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Robert Withers

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(a)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/10864… > * 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 >>> >>> >>

Oct. 19, 2015

Re: [Pharo-dev] [squeak-dev] RE: [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by Robert Withers

Hi Ron , nice to see you too! It has been a number of years, hasn't it? Crypto is timestamped back in 2010, so there is is. I hope these have been kind years to you, as they have for me. I love the idea of optional sources of entropy, depending on the deployed capabilities. So there are our mouse points and such, because they ought to be optional. What are some reliably present sources in the most minimal situation? If we could define minimal as an image with no image level I/O beyond file I/O, I would think we'd have: Kernel, System, Collections, Compiler and FFI. Some intransitives in that scope for entropy would be grand. I was thinking to take 5 millisecondClockValues, separated by 4 non-secure random intervals: take the low order byte of the 4 intervals and reverse & concat them, as a entropic source. I can coordinate these changes. Ron, could you add me to the Cryptography team so I can upload the Pharo Cryptography #bleedingEdge? Thanks and I look forward to more, :) Robert On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: > Hi Robert, > > Nice to see you! > > Looks interesting I know that Chris did something gathering sources of entropy. Seems like the more the better. Could you just make the entropy sources optional such that if they exist we use them? I would have to go back and see what Chris did but he was following suggestions from Schneider in his secureRandom. > > All the best, > > Ron Teitelbaum > >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >> Robert Withers >> Sent: Sunday, October 18, 2015 5:00 AM >> To: The general-purpose Squeak developers list; Pharo Development List >> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] RandomGenerator >> class>>unpredictableStringsDo: >> >> I'm sorry, I forgot the code. I list the existing method, followed by my >> modified Pharo method below. I welcome any feedback. >> >> Regards, >> Robert >> >> --- >> Existing: >> unpredictableStringsDo: aBlock >> "Enumerate sources of information from my environment that >> should be generally hard to guess." >> | time | >> time := Time millisecondsToRun: >> [ aBlock >> value: World imageForm bits compressToByteArray ; >> value: Sensor mousePoint x asString ; >> value: Sensor mousePoint y asString ; >> value: Time millisecondClockValue asByteArray ; >> value: Date today asString ; >> value: Time now asString ; >> value: Display extent asString. >> 100 timesRepeat: [ aBlock value: UUID new ]. >> #(vmVersion platformName primVmPath imageName >> platformSubtype datedVersion lastQuitLogPosition vmStatisticsReportString >> imageName) >> collect: >> [ : each | >> aBlock value: (SmalltalkImage current perform: each) >> asByteArray ] ]. >> aBlock >> value: time asByteArray; >> "maybe the pointer has moved, hit it again." >> value: Sensor mousePoint asString ; >> value: Time millisecondClockValue asByteArray >> >> --- >> Pharo port: >> unpredictableStringsDo: aBlock >> "Enumerate sources of information from my environment that >> should be generally hard to guess." >> >> | time | >> time := Time millisecondsToRun: >> [ aBlock >> value: Time millisecondClockValue asByteArray ; >> value: Date today asString ; >> value: Time now asString. >> 100 timesRepeat: [ aBlock value: UUID new ]. >> #(version primImagePath imagePath datedVersion >> lastQuitLogPosition) >> collect: >> [ : each | >> aBlock value: (SmalltalkImage current perform: each) >> asByteArray ] ]. >> aBlock >> value: time asByteArray; >> value: Time millisecondClockValue asByteArray >> >> >> On 10/18/2015 04:23 AM, Robert Withers wrote: >>> This is a message intended for anyone who was on the Cryptography team. >>> I recently ported it to Pharo and had to make changes to >> RandomGenerator >>> class>>unpredictableStringsDo:. This certainly removed some uncertainty >>> from the results of this message. My question is what should I do about >>> that? This method seems to require non-headless, as it is checking the >>> mouse point and such. This being a crypto cornerstone, what the best >>> answer here. >>> >>> Thank you, >>> Robert > > >

Oct. 19, 2015

Re: [Pharo-dev] Storing System Settings using STON

by Ferlicot D. Cyril

Le 12/10/2015 19:45, Juraj Kubelka a Ã©crit : > Hi, > > we have a slice that introduce new storage solution for System Settings. > See: https://pharo.fogbugz.com/f/cases/16681/Storing-System-Settings-using-STON > > You can load it using: > > Gofer it > smalltalkhubUser: 'Pharo' project: 'Pharo50Inbox'; > package: 'SLICE-Issue-16681-Storing-System-Settings-using-STON'; > load. > > When you open the Setting Browser, you can see that every setting has > new items in context menu: > > > Thanks for reviewing it. > Cheers, > Juraj Hi, Thank you for that. When I make store settings for the first time I have an exception on the write stream because the file doesn't exist. I had to create the folder 5.0 and an empty file to get it right. In Pharo 50392 on Linux. I join the stack: FileHandle>>streamError FileHandle>>writeStream FileSystem>>writeStreamOn: FileReference>>writeStream SystemSettingsPersistence>>writeStream SystemSettingsPersistence>>storeExactStoredSettings: SystemSettingsPersistence>>storeStoredSettings: SystemSettingsPersistence>>storeSettingNodes: SystemSettingsPersistence>>storeSettingNodes SettingTree>>storeSettingNodes SettingBrowser>>storeSettings PluggableButtonMorph>>performAction: [ :m | (m containsPoint: evt cursorPoint) ifTrue: [ m enabled ifTrue: [ m performAction: evt ] ] ] in PluggableButtonMorph>>mouseUp: in Block: [ :m | ... Array(SequenceableCollection)>>do: PluggableButtonMorph>>mouseUp: PluggableButtonMorph(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableButtonMorph(Morph)>>handleEvent: PluggableButtonMorph(Morph)>>handleFocusEvent: [ ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self)) ] in HandMorph>>sendFocusEvent:to:clear: in Block: [ ActiveHand := self.... BlockClosure>>on:do: WorldMorph(PasteUpMorph)>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [ :h | ActiveHand := h. h processEvents. ActiveHand := nil ] in WorldState>>doOneCycleNowFor: in Block: [ :h | ... Array(SequenceableCollection)>>do: WorldState>>handsDo: -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 19, 2015

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Esteban Lorenzano

Hi, just to be clear. When we talk about MTVM, we talk about a MT-FFI, *not* a MTVM in general. In general, a âcommonâ approach to MT cannot be applied in Pharo (or Smalltalk in general) and to get a VM *and* an image working properly is an effort that makes what I called massive some mails above like a small stone compared to a mountain. Said that: - What is in plans is MT-FFI, and that will be available eventually. - There is an approach I want to re-work, that would allow us profit of multicores without going multithread: the âhydraâ experiment made some years ago by Igor creates a good basis to this. But is also a lot of of work (but a lot less than a complete MT), and not a real priority for nowâ¦ I hope to resume work on that area some dayâ¦ just not anytime soon. Esteban > On 18 Oct 2015, at 17:56, Ben Coman <btc(a)openInWorld.com> wrote: > > > On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers > <robert.w.withers(a)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/10864… > * 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 >>> >>> >>

Oct. 19, 2015