- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Zinc (bug?) - multiple default servers

by Sven Van Caekenberghe

Sean, On 21 Dec 2011, at 04:40, Sean P. DeNigris wrote: > If you evaluate "ZnServer startDefaultOn: aPortNumber" several times, you end > up with that many instances of the default server class. Is that the > intended behavior? #default usually = singleton, so I expected all the calls > to operate on the same instance. ZnServer>>#defaultOn: aNumber "Create a new Default instance on a given port, stopping any previously running Default and replacing it. Register the new instance." Default ifNotNil: [ Default stop ]. ^ Default := (self on: aNumber) register; yourself Hmm, I never looked at it that way, but now that you mention it, a clearer singleton behavior might make more sense. Note that in any case, only one instance was running. But it might make more sense to really maintain a singleton, the comments should be adapted as well. Thanks for bringing this to my attention. Regards, Sven

Dec. 21, 2011

[Pharo-project] Zinc (bug?) - multiple default servers

by Sean P. DeNigris

If you evaluate "ZnServer startDefaultOn: aPortNumber" several times, you end up with that many instances of the default server class. Is that the intended behavior? #default usually = singleton, so I expected all the calls to operate on the same instance. -- View this message in context: http://forum.world.st/Zinc-bug-multiple-default-servers-tp4220409p4220409.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 21, 2011

[Pharo-project] MacRuby Cocoa UIs

by Sean P. DeNigris

For a while, I've been thinking about using MacRuby for native UIs and multiple windows in Pharo on the Mac. I uploaded a proof of concept to https://github.com/seandenigris/PharoMacRubyTest . It has a simple Cocoa UI that uses http to get a value (the current time) from a running Pharo image and displays it in a text field. Sean -- View this message in context: http://forum.world.st/MacRuby-Cocoa-UIs-tp4220336p4220336.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 21, 2011

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

by David T. Lewis

On Mon, Dec 19, 2011 at 10:30:02AM -0800, 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? > > > > > - 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 should work on Windows if you have a copy of the compiled timezone data files copied to the Windows system, or perhaps mounted remotely over a network. The real source for the time zone rules are the Olson database, which has been maintained for may years by Arthur David Olson, and which is now available at <http://www.iana.org/time-zones>. The database consists of human-readable time zone rule files, along with a suite of C programs for compiling the rules into the binary format that you find in /usr/share/zoneinfo. You can download the latest database files and compile them yourself, which will give you the most up to date time zone information possible for loading into Squeak/Pharo. The TimeZoneDatabase package loads its rules from the compiled time zone files, because the data format is well specified and this format is widely available on many computers. It would be quite reasonable to serialize the time zone database using Fuel, which might provide a nice distribution format if someone wants to maintain it that way. Dave > 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. >

Dec. 20, 2011

Re: [Pharo-project] Athens and Cairo, first baby steps

by StÃ©phane Ducasse

Alex normally you will just use athens and you will get a zoomable canvas :). So mondrian should not use Cairo (just athens. Athens defines an API and you will be able to have multiple back ends and your code should run the same on cairo or balloon (may be degraded in balloon). but your code will not be different. Stef > Your work is truly important! > I plan in the long term to make Mondrian and Roassal use Cairo. This has been on my todo list for quite some time already... > > Alexandre > > On 20 Dec 2011, at 14:56, Igor Stasenko wrote: > >> We binding an Athens API for Cairo library. It fits pretty well as a >> backend to API. >> >> Today i got some basics working. >> Mostly, the functionality covered by: >> >> AthensCairoSurfaceExamples example1 >> and >> AthensCairoSurfaceExamples example2 >> >> which drawing nothing fancy but just rectangle(s) with solid color. >> >> example2 >> " >> self example2 >> " >> >> | surf | >> >> surf := self newSurface: 100@100. >> >> surf drawDuring: [:can | >> surf clear. >> >> can setPaint: Color blue. >> >> can drawShape: ( >> can createPath: [:path | >> path >> absolute; >> lineTo: 50@0; >> lineTo: 50@50; >> lineTo: 0@50 >> ]) >> >> ]. >> >> Display getCanvas drawImage: surf asForm at: 0@0 >> >> >> P.S. Stef says that Athens API is quite cool :) >> >> -- >> Best regards, >> Igor Stasenko. >> <Screen Shot 2011-12-20 at 6.56.22 PM.png><Screen Shot 2011-12-20 at 6.57.04 PM.png> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Dec. 20, 2011

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

by Mariano Martinez Peck

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

Dec. 20, 2011

Re: [Pharo-project] Athens and Cairo, first baby steps

by Alexandre Bergel

Your work is truly important! I plan in the long term to make Mondrian and Roassal use Cairo. This has been on my todo list for quite some time already... Alexandre On 20 Dec 2011, at 14:56, Igor Stasenko wrote: > We binding an Athens API for Cairo library. It fits pretty well as a > backend to API. > > Today i got some basics working. > Mostly, the functionality covered by: > > AthensCairoSurfaceExamples example1 > and > AthensCairoSurfaceExamples example2 > > which drawing nothing fancy but just rectangle(s) with solid color. > > example2 > " > self example2 > " > > | surf | > > surf := self newSurface: 100@100. > > surf drawDuring: [:can | > surf clear. > > can setPaint: Color blue. > > can drawShape: ( > can createPath: [:path | > path > absolute; > lineTo: 50@0; > lineTo: 50@50; > lineTo: 0@50 > ]) > > ]. > > Display getCanvas drawImage: surf asForm at: 0@0 > > > P.S. Stef says that Athens API is quite cool :) > > -- > Best regards, > Igor Stasenko. > <Screen Shot 2011-12-20 at 6.56.22 PM.png><Screen Shot 2011-12-20 at 6.57.04 PM.png> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 20, 2011

[Pharo-project] Athens and Cairo, first baby steps

by Igor Stasenko

We binding an Athens API for Cairo library. It fits pretty well as a backend to API. Today i got some basics working. Mostly, the functionality covered by: AthensCairoSurfaceExamples example1 and AthensCairoSurfaceExamples example2 which drawing nothing fancy but just rectangle(s) with solid color. example2 " self example2 " | surf | surf := self newSurface: 100@100. surf drawDuring: [:can | surf clear. can setPaint: Color blue. can drawShape: ( can createPath: [:path | path absolute; lineTo: 50@0; lineTo: 50@50; lineTo: 0@50 ]) ]. Display getCanvas drawImage: surf asForm at: 0@0 P.S. Stef says that Athens API is quite cool :) -- Best regards, Igor Stasenko.

Dec. 20, 2011

Re: [Pharo-project] [update 1.4] #14263

by StÃ©phane Ducasse

I moved the inbox of the items to the PharoTreatedItems. Stef > 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] Newbie observations on use of Metacello

by Ben Coman

Esteban Lorenzano wrote: > Hi, > > A newbie also does not know anything about Smalltalk object, what metacello is or even what is a Package... > At some point we need to stop lowering the level and expect our newbies have capability of learning and willing to do it... > If we define Gofer as the "access point for every loadable artifact in Pharo", is easier for a newbie to look there when he wants to load something... much easier than split the functionality in different conceptual issues like Smalltalk, Packager or "Monticello Packager (Gofer)" > But having one tool for "_every_ loadable artifact" clutters up the higher level package management. I LIKE the segregation defined in the PBE2 Metacello sample chapter: * Monticello - managing source code versioning * Gofer - Moniticello Scripting API * Metacello - package dependency manager On further consideration of the PBE2 Metacello chapter I note that Metacello is a "Package Management System" and not a "Package Management Tool." Significantly what I expected to find as a newbie is The Tool, not The System. Consider that The Tool is for users and The System is for developers. While with Smalltalk we all end up developers, people being introduced to Pharo start as users. > anyway... you can call it as you want... what I'm just asking is: please, don't doit again... it is already there, waiting to be integrated :) > GopherProjectLoader particularly aligns with what I expected a class Metacello would do. Here are some significant ones... GopherProjectLoader class >> createRepositories "I answer a list of all pre-defined repositories on system" ^OrderedCollection with: (GoferProjectRepository location: 'http://www.squeaksource.com/MetacelloRepository') GoferProject class >> projectPrefix ^'ConfigurationOf' GopherProject >> toProjectList: aCollection "I collect all package names (with the form 'ConfigurationOf*' and transform them into project names)" ^(aCollection collect: [ :each | self toProjectName: each ]) asSet asOrderedCollection GopherProjectLoader>list "Lists all available projects, scanning all repositories" ^self repositories inject: OrderedCollection new into: [ :packageNames :each | packageNames, each list ] > cheers, > Esteban > > El 20/12/2011, a las 9:59a.m., Janko MivÅ¡ek escribiÃ³: > > >> 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' >> +1 but not Installer or Packager, but Metacello!!! - the "defined" package management tool for Pharo. >> 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