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

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

by Janko MivÅ¡ek

S, Esteban Lorenzano piÅ¡e: > Why don't you take another look to Gofer Project Loader? > (http://www.squeaksource.com/Loader.html) > Maybe it needs to be integrated with Gofer to be really useful (as long > as it is "yet another configuration", no one will use it), and maybe it > needs some work on it... but it is already there :) > > Also I think: > > Gofer project load: 'Blah'. > > is far better than: > > Smalltalk loadMetacelloProject: 'Blah' Well, from a newbie standpoint not really. Who knows what Gofer is? Even I have still this problem. A word Installer or some other intent revealing word is needed for such important function as package management is. Maybe simply: Packager load: 'Blah' This one should look into default Monticello repository, search first for ConfigurationOfBlah in http:/mc.default.org/Blah, then in /MetacelloRepository and if not found load plain package Blah-byme.99.mcz Best regards Janko > > best, > Esteban > > El 20/12/2011, a las 5:39a.m., StÃ©phane Ducasse escribiÃ³: > >> 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. >> >> > -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Dec. 20, 2011

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

by Igor Stasenko

I wanting the same long time :) Having a VM which handling a platform-specific nuances and providing a uniform interface to language side is a great advantage. But of course it not comes without drawbacks: you have a minimal common functionality, provided over all supported platforms. It would be cool to change the situation. A first step would be to make a Display/events primitives optional (move them into a separate plugin, outside of core VM). Like that a "default" VM without such plugin will be headless without obligation to support graphical user interface. The next step is, like you said, think about how to encode events without losing flexibility and pass them to language side. On 20 December 2011 13:12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Ok, i'm in favor of having everything in smalltalk too. > > The problem i have is the following: Â i want to change Â "how" the VM > should announce events "were" the vm should draw > > Regarding the "were", currently the VM has a primitive from which you > can specify which Form will act as the Display. But what if i want to > render to something else than a form? > Esteban: how does the COCOA VM draw the Display? Does it create a > NSWindow, with a custom view, which copies the bits from the Display > Form, into a drawing context (Quartz? OpenGL?). > > If we are moving towards a vectorial framework( AthensCanvas rendering > to OpenGL or Cairo), we dont need to hardcode a "Display" a primitive > in the vm. there's no need for such primitive. > We just need access to the drawing context of the Pharo window, and > render whatever we want there. > > We need the following: (using COCOA as an example) > an OS window =>NSWindow > with a custom view ==> subclass of NSView > that creates a Cairo surface to a quartz backend, from which in the > image side i can tell the AthensCanvas to draw into. > > For the event part, i should directly change the platform specific > code for the Cocoa VM's? > Cocoa provides higher level events and the VM is encoding them into > Arrays, that in the image are decoded back into high level events ( > see HandMorph>>generateEvt:from:). Which makes it hard to add new kind > of events, specifically those originated from the trackpad (pinch, > swipe, etc). (another BIG Â problem is that Â currently, all the VMs > arent encoding EXACTLY the same OS events into the VM Arrays of > events). I would like to play with the OS event encoding/decoding, to > not loose so much in the translation. > > Please let me know wether i explained myself clearly, i'm still in the > process of understanding how to detach the VM from the Bitmapped > forms. > > Fernando > > > On Tue, Dec 20, 2011 at 12:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> El 20/12/2011, a las 7:30a.m., Igor Stasenko escribiÃ³: >>> >>> 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. >> >> +1 >> It takes time... but in the long way is the best approach, I think. >> >>> 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. >> >> They are not easier... but can be better for applications. That's the "default" behavior for mac and that's the reason why you usually don't have UI freezes while doing stuff (of course, not all applications -nor our vm, I changed it to single process- Â works that way... because is harder to maintain) >> >> best, >> Esteban >> > -- Best regards, Igor Stasenko.

Dec. 20, 2011

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

by Sven Van Caekenberghe

+1 On 20 Dec 2011, at 12:53, Esteban Lorenzano wrote: > Why don't you take another look to Gofer Project Loader? (http://www.squeaksource.com/Loader.html) > Maybe it needs to be integrated with Gofer to be really useful (as long as it is "yet another configuration", no one will use it), and maybe it needs some work on it... but it is already there :) > > Also I think: > > Gofer project load: 'Blah'. > > is far better than: > > Smalltalk loadMetacelloProject: 'Blah'

Dec. 20, 2011

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

by Fernando Olivero

Ok, i'm in favor of having everything in smalltalk too. The problem i have is the following: i want to change "how" the VM should announce events "were" the vm should draw Regarding the "were", currently the VM has a primitive from which you can specify which Form will act as the Display. But what if i want to render to something else than a form? Esteban: how does the COCOA VM draw the Display? Does it create a NSWindow, with a custom view, which copies the bits from the Display Form, into a drawing context (Quartz? OpenGL?). If we are moving towards a vectorial framework( AthensCanvas rendering to OpenGL or Cairo), we dont need to hardcode a "Display" a primitive in the vm. there's no need for such primitive. We just need access to the drawing context of the Pharo window, and render whatever we want there. We need the following: (using COCOA as an example) an OS window =>NSWindow with a custom view ==> subclass of NSView that creates a Cairo surface to a quartz backend, from which in the image side i can tell the AthensCanvas to draw into. For the event part, i should directly change the platform specific code for the Cocoa VM's? Cocoa provides higher level events and the VM is encoding them into Arrays, that in the image are decoded back into high level events ( see HandMorph>>generateEvt:from:). Which makes it hard to add new kind of events, specifically those originated from the trackpad (pinch, swipe, etc). (another BIG problem is that currently, all the VMs arent encoding EXACTLY the same OS events into the VM Arrays of events). I would like to play with the OS event encoding/decoding, to not loose so much in the translation. Please let me know wether i explained myself clearly, i'm still in the process of understanding how to detach the VM from the Bitmapped forms. Fernando On Tue, Dec 20, 2011 at 12:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > El 20/12/2011, a las 7:30a.m., Igor Stasenko escribiÃ³: >> >> 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. > > +1 > It takes time... but in the long way is the best approach, I think. > >> 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. > > They are not easier... but can be better for applications. That's the "default" behavior for mac and that's the reason why you usually don't have UI freezes while doing stuff (of course, not all applications -nor our vm, I changed it to single process- Â works that way... because is harder to maintain) > > best, > Esteban >

Dec. 20, 2011

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

by Esteban Lorenzano

Why don't you take another look to Gofer Project Loader? (http://www.squeaksource.com/Loader.html) Maybe it needs to be integrated with Gofer to be really useful (as long as it is "yet another configuration", no one will use it), and maybe it needs some work on it... but it is already there :) Also I think: Gofer project load: 'Blah'. is far better than: Smalltalk loadMetacelloProject: 'Blah' best, Esteban El 20/12/2011, a las 5:39a.m., StÃ©phane Ducasse escribiÃ³: > 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] decoupling the vm: UI and interpretation

by Esteban Lorenzano

El 20/12/2011, a las 7:30a.m., Igor Stasenko escribiÃ³: > > 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. +1 It takes time... but in the long way is the best approach, I think. > 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. They are not easier... but can be better for applications. That's the "default" behavior for mac and that's the reason why you usually don't have UI freezes while doing stuff (of course, not all applications -nor our vm, I changed it to single process- works that way... because is harder to maintain) best, Esteban

Dec. 20, 2011

[Pharo-project] [update 1.4] #14263

by Marcus Denker

14263 ----- Issue 3766: Lets fix this one (which is not broken) http://code.google.com/p/pharo/issues/detail?id=3766 Issue 4688: progress bar disappears on image save http://code.google.com/p/pharo/issues/detail?id=4688 Issue 4616: ClassTest may let a Unclassified category after their execution http://code.google.com/p/pharo/issues/detail?id=4616 Issue 3806: Duration>>hours is broken http://code.google.com/p/pharo/issues/detail?id=3806 -- Marcus Denker -- http://marcusdenker.de

Dec. 20, 2011

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