- Pharo-dev - lists.pharo.org

Re: [Pharo-project] decoupling the vm: UI and interpretation

by Igor Stasenko

On 20 December 2011 10:38, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Hi, Â a question to the VM maintainers. > > Would it be hard to decouple the VM, one part handling the object > machinery, and the other the UI portion of the current OS. > > The "UI Vm" would feed the VM with the events, similarly to the > current scheme, Â but there's no need for them to be coupled within the > same project. > So we could implement separately the "UI Vm", that its implemented in > whatever windowed framework we choose ( Cocoa, X11, Windows, etc..). > > In short, do you think it would worth it to break the VM into two pieces: > > 1)UI VM: handles the window, the drawing context were Pharo should be > drawn into, and announcing user events to the Smalltalk VM. > 2)Smalltalk VM: everything else (truly headless). > > (The two OS processes could communicate via any available > IPC(interprocess communication)) > > Wouldn't it make easier the task of maintaining and enhancing both VMs > separately? > I think what would be easier is to make a language side to handle everything. Unfortunately in practice this means moving substantial parts implemented in C and putting in smalltalk. I also don't see how separating it into 2 processes make things easier. I think it will complicate things even more, because now you will need to invent own communication schemes , which is also platform specific. And possibly it will work slower because of IPC overhead. > This idea came up Â because of the current effort to free Pharo, from > the outdated bitmap dependency, into a vectorial user interface > framework. > > Fernando > pd: I've been playing around recently with Cocoa, the "smalltalk and > morphic" ripoff from apple. And found it relatively easy to come with > a "UI VM". > What is difficult is to plug into the current scheme. > -- Best regards, Igor Stasenko.

Dec. 20, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Mariano Martinez Peck

> >>> Thanks Levente. Well, now all our tests and benchmarks pass like a charm >> :) We will soon include it in the "trunk" of Fuel. Will them be available >> in a repository for squeak? because if so, I can adapt ConfiguratioOfFuel >> so that in Squeak it loads another collections. >> > > The best would be to add the patch to Pharo, which fixes #pointsTo: and > adds #instVarsIncludes:. Then change the code to use #instVarsInclude: in > these collections. If that's all done, then this code should work in both > Pharo and Squeak. Yes, I agree. But anyway, Fuel will load in previous versions of Pharo, where such fix won't be integrated. So we will need to handle this. > > > >> So...from the benchmarks I can say that in large graphs the improve in >> performance was 30% in serialization, and only use in one place the set >> and >> in another one the dictionary. >> > > Great, hopefully the new primitive will increase this even more. :) > > Hopefully. Did you answer Eliot? he was asking what you needed... Ahh BTW, I found another small bug.. LargeIdentityDictionary sends #keyNotFound but it is not implemented. Just adding: errorKeyNotFound: aKey KeyNotFound signalFor: aKey is enough. Cheers > > Levente > > >> Thanks!!! >> >> >> >> >>> Levente >>> >>> >>> Cheers >>>> >>>> >>>> >>>> Levente >>>>> >>>>> >>>>> On Sun, Dec 18, 2011 at 7:17 PM, Mariano Martinez Peck < >>>>> >>>>>> marianopeck(a)gmail.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Now I noticed that SmallIntegers storing is really slow >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>>> This is not entirely true. Every hash table can be made slow if >>>>>>>>>> you >>>>>>>>>> >>>>>>>>> know >>>>>>>>> how it's hash function works. Since in your example all numbers are >>>>>>>>> congruent to 1 modulo 4096 and the size of the array is also 4096, >>>>>>>>> therefore they will be mapped to the same slot (1). Try using >>>>>>>>> random >>>>>>>>> (or at >>>>>>>>> least more realistic) numbers in your test. If this is a real >>>>>>>>> problem, >>>>>>>>> then >>>>>>>>> it may be necessary to implement a new hash method, which uses the >>>>>>>>> primitive for general objects and does something else with >>>>>>>>> SmallIntegers >>>>>>>>> and that method shoul be used from these large collections. >>>>>>>>> >>>>>>>>> >>>>>>>>> I uploaded a new mcz to the FuelExperiments repository, which is >>>>>>>>> >>>>>>>> unaffected by the identity hash differences between Pharo and Squeak >>>>>>>> and >>>>>>>> works better with SmallIntegers. It includes both the dictionary and >>>>>>>> the >>>>>>>> set and (in theory) has slightly better performance for >>>>>>>> non-SmallInteger >>>>>>>> objects. >>>>>>>> >>>>>>>> >>>>>>>> Hi Levente. First let me say I really appreaciate your effort in >>>>>>>> make >>>>>>>> >>>>>>>> it >>>>>>> work. It makes definitvly Fuel faster and it would make sense to >>>>>>> integrate >>>>>>> them also in Squeak and Pharo. >>>>>>> Now, I found another bug. To reproduce it: >>>>>>> >>>>>>> | dict | >>>>>>> dict := LargeIdentityDictionary new. >>>>>>> dict at: 16941057 put: 1035. >>>>>>> >>>>>>> Now, it seems 16941057 largeIdentityHash answers 4096 and the comment >>>>>>> of >>>>>>> #largeIdentityHash says ""Return an integer between 0 and 4095 based >>>>>>> on >>>>>>> all of my bits. Make sure that for nearby receivers the result will >>>>>>> not >>>>>>> be >>>>>>> nearby with high probability."" >>>>>>> >>>>>>> The thing is that LargeIdentityHashedCollection permuteHash: hash + 1 >>>>>>> answers 4096, and hence, when in #at:put: you do: >>>>>>> >>>>>>> at: key put: value >>>>>>> >>>>>>> | hash | >>>>>>> (keys at: (hash := key largeIdentityHash + 1)) >>>>>>> >>>>>>> then you get the out of bounds. >>>>>>> >>>>>>> Modyfing >>>>>>> >>>>>>> initialize >>>>>>> >>>>>>> | rng | >>>>>>> rng := Random seed: 664399324. >>>>>>> PermutationMap := (1 to: 4096) asArray shuffleBy: rng >>>>>>> >>>>>>> to 4095 make some tests to pass, but there are some other failing. >>>>>>> >>>>>>> I will try to continue to see if I find the error. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>> Levente >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Levente >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> numbers := OrderedCollection new. >>>>>>>>> >>>>>>>>> numbers add: 1. >>>>>>>>>> numbers addAll: (1 to: 1 << 29 by: 1 << 14) asArray. >>>>>>>>>> numbers addAll: ((1 to: 1 << 29 by: 1 << 14) asArray collect: >>>>>>>>>> [:each >>>>>>>>>> | >>>>>>>>>> each negated] ). >>>>>>>>>> >>>>>>>>>> dict := LargeIdentityDictionary new. >>>>>>>>>> [numbers do: [:each | >>>>>>>>>> dict at: each put: dict size + 1. >>>>>>>>>> ]. >>>>>>>>>> ] timeToRun >>>>>>>>>> -> 12657 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> whereas with IdentityDictionary it is 37. I guess it could be >>>>>>>>>> related >>>>>>>>>> to >>>>>>>>>> #identityHash or #basicIdentityHash. I tried in Squeak 4.3 and it >>>>>>>>>> is >>>>>>>>>> also >>>>>>>>>> also there. >>>>>>>>>> I will try to take a look into it during the next week. >>>>>>>>>> >>>>>>>>>> Thanks in advance >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Nicolas >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks for any idea. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Dec 17, 2011 at 1:50 PM, StÃ©phane Ducasse >>>>>>>>>>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Dec 16, 2011, at 3:28 PM, Levente Uzonyi wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cool. One more thing: in Squeak the method using primitive >>>>>>>>>>>>>> 132 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> directly >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> was renamed to #instVarsInclude:, so now #pointsTo: works as >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> expected. If >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> this was also added to Pharo, then the #pointsTo: sends >>>>>>>>>>>>> should >>>>>>>>>>>>> >>>>>>>>>>>> be >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> changed to >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> #instVarsInclude:, otherwise Array can be reported as >>>>>>>>>>>>> included >>>>>>>>>>>>> >>>>>>>>>>>> even >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> if it >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> wasn't added. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I'll upload my LargeIdentityDictionary implementation to the >>>>>>>>>>>> same >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> place >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> this evening, since it's still 2-3 factor faster than other >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> solutionts and >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> there seem to be demand for it. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Levente >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> "in Squeak the method using primitive 132 directly was >>>>>>>>>>>>>> renamed >>>>>>>>>>>>>> to >>>>>>>>>>>>>> >>>>>>>>>>>>>> #instVarsInclude:, so now #pointsTo: works as expected." >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I do not get the following. Indeed pointTo: looks like >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> instVarsInclude: >>>>>>>>>>>>>> now I do not understand the rest of your paragraph. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Stef >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Mariano >>>>>>>>>>>>> http://marianopeck.wordpress.********com<http://marianopeck.** >>>>>>>>>>>>> wordpress.com <http://marianopeck.wordpress.****com< >>>>>>>>>>>>> http://marianopeck.**wordpress.com<http://marianopeck.wordpress.com> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>> Mariano >>>>>>>>>> http://marianopeck.wordpress.********com < >>>>>>>>>> http://marianopeck.wordpress.****** >>>>>>>>>> com <http://marianopeck.wordpress.****com<http://marianopeck.** >>>>>>>>>> wordpress.com <http://marianopeck.wordpress.com>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>> Mariano >>>>>>> http://marianopeck.wordpress.******com < >>>>>>> http://marianopeck.wordpress.**** >>>>>>> com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>>> >> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.******com <http://marianopeck.wordpress. >>>>>> **** >>>>>> com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>> >> >>>>>> >>>>>> >>>>>> >>>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.****com <http://marianopeck.wordpress.** >>>> com <http://marianopeck.wordpress.com>> >>>> >>>> >>> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> > -- Mariano http://marianopeck.wordpress.com

Dec. 20, 2011

Re: [Pharo-project] Have you played with Ameba?

by Noury Bouraqadi

Hi, I couldn't view the videos (tried with Safari and Firefox), and I could it test your code. I tried on Pharo 1.3 and 1.4. Noury On 17 dÃ©c. 2011, at 08:40, HwaJong Oh wrote: > Markus, > > Forget Ameba. Ani is here. > > Zini das Wuslon is implemented. It moves like a real one. > > > Gofer new > squeaksource: 'DaliotsPlayground'; > package: 'ConfigurationOfDaliotsPlayground'; > load. > > (Smalltalk at: #ConfigurationOfDaliotsPlayground) project lastVersion load: > 'Ani' > > http://appdal.com/groups/36442/wiki/9eee9/Ani.html > > Best Regards > HwaJong Oh > > -- > View this message in context: http://forum.world.st/Have-you-played-with-Ameba-tp3585624p4207593.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > Noury -- http://twitter.com/#!/NouryBouraqadi

Dec. 20, 2011

[Pharo-project] decoupling the vm: UI and interpretation

by Fernando Olivero

Hi, a question to the VM maintainers. Would it be hard to decouple the VM, one part handling the object machinery, and the other the UI portion of the current OS. The "UI Vm" would feed the VM with the events, similarly to the current scheme, but there's no need for them to be coupled within the same project. So we could implement separately the "UI Vm", that its implemented in whatever windowed framework we choose ( Cocoa, X11, Windows, etc..). In short, do you think it would worth it to break the VM into two pieces: 1)UI VM: handles the window, the drawing context were Pharo should be drawn into, and announcing user events to the Smalltalk VM. 2)Smalltalk VM: everything else (truly headless). (The two OS processes could communicate via any available IPC(interprocess communication)) Wouldn't it make easier the task of maintaining and enhancing both VMs separately? This idea came up because of the current effort to free Pharo, from the outdated bitmap dependency, into a vectorial user interface framework. Fernando pd: I've been playing around recently with Cocoa, the "smalltalk and morphic" ripoff from apple. And found it relatively easy to come with a "UI VM". What is difficult is to plug into the current scheme.

Dec. 20, 2011

Re: [Pharo-project] 1.3, PBE and lab setups

by StÃ©phane Ducasse

+1 > > Hi Dave, > thank you for this initiative ! > I think this is better if you can use the current git repository to do > that, because you will have continuous interactions with the community > and maybe people will help you. > I think this is better to commit small modifications every day than > commit a lot of modifications at end, that maybe will not be > integrated by the community. > What do you think about that ? > > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Matsuno Laboratory, Kyoto University, Japan (until 12/2011) > http://www.mechatronics.me.kyoto-u.ac.jp/ > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ >

Dec. 20, 2011

Re: [Pharo-project] Newbie observations on use of Metacello

by StÃ©phane Ducasse

Noooooooooooooooooooo ! Horrible ugly terrible, Don;t touch our SmalltalkImage :) > But i think there could be a compromise. We may add an extension > method to be able to do something like: > > Smalltalk loadMetacelloProject: #ConfigurationOfXYZ > fromRepository: 'http://squeaksource.com/XYZProject' > > and/or: > > Smalltalk loadMetacelloProject: #ConfigurationOfXYZ > fromRepository: 'http://squeaksource.com/XYZProject' > version: 'x.y.z' > > like that, we can have a cake and eat it too.

Dec. 20, 2011

Re: [Pharo-project] Anyone want more timezones in the base image?

by StÃ©phane Ducasse

On Dec 19, 2011, at 7:30 PM, Paul DeBruicker wrote: > Thanks for the feedback. Comments below. > > > Sven Van Caekenberghe wrote >> >> >> I had a quick look at your code and it seems like a logical addition >> (given what TimeZone currently is and what you want to do: interpret tz >> abbreviations). I have 3 remarks/comments: >> >> - the list is currently a dynamic array that is recreated on every access, >> wouldn't a lazy initialized class variable be better ? >> > > Yes of course I would love that but I don't know how to create a class > variable when just using extensions on a class. Is there a way? > Indeed one day we will have to fix that first class instance variable should help. For now I hate that but I use a class initialize method that use addInstanceVarNameâ¦. >> - one other goal of a list of timezones is to present them to the user to >> pick one; for that TimeZone as it stands now is insufficient (there is no >> country/city mapping, which is the most user friendly way to pick one, >> IMHO). it seems a bit wastefull to have such a list and not be able to >> support that goal as well. >> > I agree but that would entail mapping also when each timezone is in effect > in each locale during different times of the year. My Something the Chronos > (http://www.chronos-st.org) package does and I think the TimeZoneDatabase > from Dave Lewis does. My solution is definitely much simpler and less > useful. > > > >> - on Mac OS X and Linux, there is enough data in /usr/share/zoneinfo to >> dynamically load/parse from, if something equivalent existed on Windows, >> we could use that (and benefit from OS level updates to this DB); I know >> it is more work, I'm just thing out loud. >> > > I'm glad you are thinking about it. Dave Lewis's TimeZoneDatabase does > this, I think not on windows but I'm not positive. . It also seems to me > that adopting the TimeZoneDatabase is natural next step for the > TimeZone/Chronology package to go if there's reason to make Pharo better > able to handle cross-timezone issues. But it would need to have a source > for Olson time zone data on Windows. Dave has created a primitive > (primitiveUtcWithOffset) in the interpreterVM that would be good to port to > the CogVM. Chronos is great and exact but also Big in the image. > > > > > > > -- > View this message in context: http://forum.world.st/Anyone-want-more-timezones-in-the-base-image-tp420639… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 20, 2011

Re: [Pharo-project] JetBraind support Redline Smalltalk ...

by Marcus Denker

On Dec 20, 2011, at 9:16 AM, Philippe Marschall wrote: > On 12/20/2011 01:32 AM, James Ladd wrote: >> >> Hey everyone, >> So this is the skinny. We've met the >> basic requirements original discussed with Jet Brains early in 2011 for >> Redline Smalltalk support to make it onto their roadmap. >> We need your >> help to get it moved up. Jet Brains has a voting system where registered >> users vote up features they want to see implemented. >> As of today, there >> is now one for Redline support. The next step is pretty simple... >> >> We need everyone to sign in with google/Yahoo or sign up for a Jet Brains account and vote for Redline support.We need you to tweet about it.... to email people about it.... to google + about it. >> ... to stand on the street corner talking about how the world is going to come to an end unless this happens. >> This could be a big deal and your help is greatly appreciated. >> >> http://youtrack.jetbrains.net/issue/IDEA-79069 > > If I was JetBrains I'd be pretty pissed if I got 500 votes for this, > implemented it, and then sold only two copies because nobody voting was > actually considering buying IDEA at any point. > > Don't treat this as "Do you think Smalltalk is cool?", treat this as > "Would you buy IDEA if it had this?". > In addition, I would wait for a 1.0 release *and* to have some real users. Voting for something not yet released looks strange. Marcus -- Marcus Denker -- http://marcusdenker.de

Dec. 20, 2011

Re: [Pharo-project] JetBraind support Redline Smalltalk ...

by Philippe Marschall

On 12/20/2011 01:32 AM, James Ladd wrote: > > Hey everyone, > So this is the skinny. We've met the > basic requirements original discussed with Jet Brains early in 2011 for > Redline Smalltalk support to make it onto their roadmap. > We need your > help to get it moved up. Jet Brains has a voting system where registered > users vote up features they want to see implemented. > As of today, there > is now one for Redline support. The next step is pretty simple... > > We need everyone to sign in with google/Yahoo or sign up for a Jet Brains account and vote for Redline support.We need you to tweet about it.... to email people about it.... to google + about it. > ... to stand on the street corner talking about how the world is going to come to an end unless this happens. > This could be a big deal and your help is greatly appreciated. > > http://youtrack.jetbrains.net/issue/IDEA-79069 If I was JetBrains I'd be pretty pissed if I got 500 votes for this, implemented it, and then sold only two copies because nobody voting was actually considering buying IDEA at any point. Don't treat this as "Do you think Smalltalk is cool?", treat this as "Would you buy IDEA if it had this?". Cheers Philippe

Dec. 20, 2011

[Pharo-project] JetBraind support Redline Smalltalk ...

by James Ladd

Hey everyone, So this is the skinny. We've met the basic requirements original discussed with Jet Brains early in 2011 for Redline Smalltalk support to make it onto their roadmap. We need your help to get it moved up. Jet Brains has a voting system where registered users vote up features they want to see implemented. As of today, there is now one for Redline support. The next step is pretty simple... We need everyone to sign in with google/Yahoo or sign up for a Jet Brains account and vote for Redline support.We need you to tweet about it.... to email people about it.... to google + about it. ... to stand on the street corner talking about how the world is going to come to an end unless this happens. This could be a big deal and your help is greatly appreciated. http://youtrack.jetbrains.net/issue/IDEA-79069

Dec. 20, 2011