December 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] MacRuby Cocoa UIs

by Sean P. DeNigris

I uploaded a short screencast to http://vimeo.com/34095659 -- View this message in context: http://forum.world.st/MacRuby-Cocoa-UIs-tp4220336p4226620.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 22, 2011

Re: [Pharo-project] Tiling Window Manager

by Sean P. DeNigris

laurent laffont wrote > > Actually TWM has these ways for grouping windows: > Cool, I retract. Let me play with those and report back! -- View this message in context: http://forum.world.st/Tiling-Window-Manager-tp4226499p4226583.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 22, 2011

Re: [Pharo-project] Tiling Window Manager

by laurent laffont

How would you group / identify related windows ? Actually TWM has these ways for grouping windows: - worlds: http://magaloma.blogspot.com/2011/06/multiple-worlds-for-twm.html (Pharo 1.4): http://magaloma.blogspot.com/2011/07/twm-docking-windows.html - tabs: (GroupWindowMorph new openInWindowLabeled: 'Window organizer') extent: 400@400 - dock: DockingWindowMorph new openInWorld. but needs some work to be really nice. Laurent On Thu, Dec 22, 2011 at 9:09 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > The concept and look of TWM is cool, but for me it groups things in a way > that is non-helpful. I never want to tile "all the browsers" or "all the > workspaces". I want to group tools logically, e.g. "show only the tools > related to fixing bug 1234". > > -- > View this message in context: > http://forum.world.st/Tiling-Window-Manager-tp4226499p4226499.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Dec. 22, 2011

Re: [Pharo-project] COTDC

by laurent laffont

On Thu, Dec 22, 2011 at 9:07 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > The last three classes got no responses. Do we not want to play anymore? > > Maybe Xmas is not the good period for intense activity. But please yes. Laurent > -- > View this message in context: > http://forum.world.st/COTDC-tp4226492p4226492.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Dec. 22, 2011

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

by Mariano Martinez Peck

So...the fix for #pointsTo: and #instVarsInclude: is in inbox: http://code.google.com/p/pharo/issues/detail?id=5118 If anyone wants to take a look... Cheers On Tue, Dec 20, 2011 at 11:01 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > 2011/12/20 Levente Uzonyi <leves(a)elte.hu> > >> On Tue, 20 Dec 2011, Mariano Martinez Peck wrote: >> >> >>>> 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. >>> >> >> This can easily solved with a separate Metacello configuration. >> >> > Yes, I will do that. > > > >> >> >>> >>> >>>> >>>> >>>> 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... >>> >> >> I did answer his private email about the primitive. >> >> > Ahh ok, excellent :) > > >> >> >>> Ahh BTW, I found another small bug.. LargeIdentityDictionary sends >>> #keyNotFound but it is not implemented. Just adding: >>> >>> errorKeyNotFound: aKey >>> >>> KeyNotFound signalFor: aKey >>> >>> is enough. >>> >> >> Go ahead. :) >> >> > Done > > >> >> Levente >> >> >>> 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://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<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 <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 > > -- Mariano http://marianopeck.wordpress.com

Dec. 22, 2011

[Pharo-project] Tiling Window Manager

by Sean P. DeNigris

The concept and look of TWM is cool, but for me it groups things in a way that is non-helpful. I never want to tile "all the browsers" or "all the workspaces". I want to group tools logically, e.g. "show only the tools related to fixing bug 1234". -- View this message in context: http://forum.world.st/Tiling-Window-Manager-tp4226499p4226499.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 22, 2011

[Pharo-project] COTDC

by Sean P. DeNigris

The last three classes got no responses. Do we not want to play anymore? -- View this message in context: http://forum.world.st/COTDC-tp4226492p4226492.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 22, 2011

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

by csrabak＠bol.com.br

Em 20/12/2011 07:38, Fernando Olivero < fernando.olivero(a)usi.ch > escreveu: > 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..). I think this is an idea which may have appeal for theoretic reasons and even if it is short to medium term feasible it will not have the impact it deserves. > 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)) It would add complexity, reduce performance without any obvious advantage for the final user... > Wouldn't it make easier the task of maintaining and enhancing both > VMs separately? No, because the problems to port for each platform would remain all there. Worse, if we need to create a new "upper level" abstraction in order to translate all the UI VM primitives to all the corresponding platform OSs. > This idea came up because of the current effort to free Pharo, from > the outdated bitmap dependency, into a vectorial user interface > framework. Which I see as distantly related issue which is not easily solvable by the proposal of this post. > 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. Yes, then imagine plug into the current scheme 'n' different UI VMs. . . > >

Dec. 22, 2011

Re: [Pharo-project] MacRuby Cocoa UIs

by Sean P. DeNigris

Fernando olivero-2 wrote > > I was about to play with a similar approach using Cocoa. > I just used MacRuby because it is more fun than ObjC :) Fernando olivero-2 wrote > > Did you try with more complex examples? > No, I just wanted the build and play with simplest possible example. Fernando olivero-2 wrote > > i would like to understand if HTTP would be fast enough as an IPC, > between the UI and a Pharo headless vm. > Me too :) -- View this message in context: http://forum.world.st/MacRuby-Cocoa-UIs-tp4220336p4226347.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 22, 2011

Re: [Pharo-project] [OT] Pharo and children

by laurent laffont

On Thu, Dec 22, 2011 at 7:29 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Thu, Dec 22, 2011 at 6:53 PM, laurent laffont > <laurent.laffont(a)gmail.com> wrote: > > my son will soon have 7 years old and starts to show interest in how all > > these things move on screen. I wonder what are your cool ways to teach > > programming with instant fun for kids. > > Squeak: Learn Programming with Robots > oh I forgot this one. Just ordered :) Laurent > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > >

Dec. 22, 2011