September 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] (no subject)
by Skrishnamachari Sept. 10, 2010

Sept. 10, 2010

http://www.apple.com/pr/library/2010/09/09statement.html This should help push scratch back into AppStore n allow all of pharo apps to work...! Sent from my iPad

1 0

[Pharo-project] [update 1.2] #12134
by StÃ©phane Ducasse Sept. 10, 2010

Sept. 10, 2010

12134 ----- Deleting Graphics package which is overlapping Stef and gabriel :)

1 0

[Pharo-project] i18n tools
by Panu Suominen Sept. 10, 2010

Sept. 10, 2010

To keep the story short. I did not find any tools to use translations in seaside and magritte so I had to made something up on my own. I am skeptic wether it will have any value beyond myself but comments are very welcome. There is more explanation in the following conversation: (pharo-project subscribers, sorry for double post). Forwarded conversation Subject: i18n tools ------------------------ From: *Panu Suominen* <panu.j.m.suominen(a)gmail.com> Date: 2010/9/9 To: pharo-users(a)lists.gforge.inria.fr I am researching wether out team could start using Pharo. I have tried to locate some tools to do user interface translations but I did not find anything in time so I had to develop some rudimentary key-based translation tools my self. I would like to know is this lack of translation tools reality and if others are having same kind of problems? -- Panu ---------- From: *StÃ©phane Ducasse* <stephane.ducasse(a)inria.fr> Date: 2010/9/9 To: panu.suominen(a)iki.fi, A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> Cc: Hilaire Fernandes <hilaire.fernandes(a)gmail.com> hilaire can you provide some pointers because you did a lot of translations. Stef > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users ---------- From: *Panu Suominen* <panu.j.m.suominen(a)gmail.com> Date: 2010/9/10 To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> Cc: A friendly place where any question about pharo is welcome < pharo-users(a)lists.gforge.inria.fr>, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> To stimulate little more.. I have done rudimentary translation support for magritte and seaside. Should I publish them or are there already working options? -- Panu ---------- From: *Stanislav Paskalev* <kshorg(a)gmail.com> Date: 2010/9/10 To: panu.suominen(a)iki.fi, A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> Seaside had none the last time I asked. Please do so. Stanislav Paskalev ---------- From: *Panu Suominen* <panu.j.m.suominen(a)gmail.com> Date: 2010/9/10 To: Stanislav Paskalev <kshorg(a)gmail.com> Cc: A friendly place where any question about pharo is welcome < pharo-users(a)lists.gforge.inria.fr> 2010/9/10 Stanislav Paskalev <kshorg(a)gmail.com>: I am in a bit hurry, but I hope you can still make sense out of this. The whole seaside and translation thing is based on the fact that Seaside render: method is dispatched to objects renderOn: method where we can access session. On the other hand we can store language to session. If we implement object that is able to answer correctly to translate: -message with language as a parameter we have a simple translation framework. I created a simple translation framework which is able to return translation for certain key. Keys are looked from properly named subclass. Names are form of LanguagePackOfProgramX_fi, LanguagePackOfProgramX_en. Each containing translations for the given language. K3LanguagePack and tests should give better idea. Notice that examples below need language -method in session.... Example to use with seaside: renderContentOn: html html render: (LanguegPackOfMyProgram translationFor: #greetingMessge) Example with magritte: descriptionEmail ^MAStringDescription new accessor: #email; label: (K3CoreLanguagePack translationFor: #email); addCondition: [:value | value includes: $@] labelled: (LanguegPackOfMyProgram translationFor: #emailNotValid); beRequired; requiredErrorMessage: (LanguegPackOfMyProgram translationFor: #emailIsRequired); priority: 10; yourself. The magritte part was builded on top of 2.0.5 magritte-seaside. This code enabled me to build seaside application demo that could change its user interface on the fly. Meaning that anything else stays as it is, only the language changes. But I don't know how useful this is for other people. Currently the major flaw is that there is no way to set the arguments for the translation ('Hello user, your name is {1}'). It is not a big addition but haven't needed it in this proof of concept. However it should not be very hard to implement. Other thing that should be discussed is the way translations are stored. I chose to use symbols that points to methods and thus translations can be encapsulated in classes. However there seems to be NaturalLanguageTranslator and string translate already in existence and I am wondering should I change the implementation to use them instead. I am very open to suggestions. -- Panu ---------- From: *Mariano Martinez Peck* <marianopeck(a)gmail.com> Date: 2010/9/10 To: panu.suominen(a)iki.fi, A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> Cc: Seaside - general discussion <seaside(a)lists.squeakfoundation.org> Panu, maybe you may want to cc seaside mailing list too ;) -- Panu

1 0

[Pharo-project] Feature Request: Strict Compiler / Monticello Mode
by Philippe Marschall Sept. 10, 2010

Sept. 10, 2010

Hi It seems like we unintentionally introduced an override for Collection >> #sorted in Grease. That puts in a hard place because we can't simply remove it from Grease. Because if you do that everybody who updates looses the method and potentially breaks his image. Yeah, I see that the real fix you be for Monticello to restore the old method but that hasn't happened in years. Monticello / the compiler already warns about a lot of less important things. Now I know adding an additional preference for that is ugly and I'd welcome and better/nicer solution. Cheers Philippe

7 19

Re: [Pharo-project] Pharo-project Digest, Vol 29, Issue 57
by Ralph Boland Sept. 10, 2010

Sept. 10, 2010

I posted the following earlier to the Squeak list but didn't get a responce. Hopefully someone on the Pharo list can help me. I need this information so I can make some planned changes to the ProgressDisplay package I released a while back. ----------------------------------------------------------------------------------------------------------------- A SystemProgressMorph is used to display progress while some computation is being done. Furthermore the progress bars can be stacked to show progress of component computations within a computation. This I understand and understand most of the code. But not All. What I have trouble with is understanding why a ProgressInitiationException is needed. In particular, String>>displayProgressAt:from:to:during: does: ProgressInitiationException display: self at: aPoint from: minVal to: maxVal during: workBlock. This method sets a few variables and then does: ^self signal This signal is caught where upon a SystemProgressMorph is started or extended with an additional progress bar. But I don't understand why sending a signal to a ProgressInitiationException is needed to get the ball rolling, Can someone please explain why things are done the way they are? Regards, Ralph Boland

2 1

[Pharo-project] [ANN] OPAL Digest
by StÃ©phane Ducasse Sept. 9, 2010

Sept. 9, 2010

hi guys Since Opalers are working hard in the shadow, I thought that I can do a little digest for them. Each time I will delete ten entries I will do a small digest. Thanks marcus, Jorge and JB for their time and energy. Stef PS: OPAL is the new compiler framework we will have in 1.3. Really cool. OPAL comes from the Opal coast near to lille with cool dunes and birds. ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.33 Author: MarcusDenker Time: 9 September 2010, 8:12:20 pm UUID: beb4fce5-38ef-4ff1-ba41-924245ff6456 Ancestors: OpalCompiler-Core-MarcusDenker.32 - cleanups (unsent methods) - make sure to hand over array of copiedTemos to IRBuilder, not Set. final one for today... things start to work. Failing tests down to 24 (from 40). TestCoverage 81% ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.29 Author: MarcusDenker Time: 9 September 2010, 7:47:08 pm UUID: aa19bd88-0895-4ab8-b55c-3f62f1698e33 Ancestors: OpalCompiler-Tests-MarcusDenker.28 - ASTChecker tests does not use verifyin, but just the ASTChecker - misc changes ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.32 Author: MarcusDenker Time: 9 September 2010, 7:46:21 pm UUID: 845092d2-e58f-441a-9304-43106311e5a1 Ancestors: OpalCompiler-Core-MarcusDenker.31 -> ASTTraslator now requests a tempVector from IRBuilder if needed -> simplified ASTClosureAnalyzer --> moved code to block/method scope -> tempVector now is not a temp anymore, just a copying one if needed -> verifyIn: now calls both visitors. ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.31 Author: MarcusDenker Time: 9 September 2010, 5:49:20 pm UUID: ab2dc77f-71b4-4f82-9cb4-4a2c1261e3fe Ancestors: OpalCompiler-Core-MarcusDenker.30 - simplify a bit re-lookup of variables in OCASTClosureAnalyzer - scopes now have a unique name after ASTChecker pass (this is then used as the name of the vector) ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.28 Author: MarcusDenker Time: 9 September 2010, 5:49:34 pm UUID: 4821aa22-5ca5-4973-9c18-df0b1bb0297f Ancestors: OpalCompiler-Tests-MarcusDenker.27 more tests... ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.27 Author: MarcusDenker Time: 9 September 2010, 5:09:43 pm UUID: 49dfe8ab-d8af-4b61-9bcc-066fcf7e5aa0 Ancestors: OpalCompiler-Tests-JorgeRessia.26 fix tests... ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.30 Author: MarcusDenker Time: 9 September 2010, 5:09:27 pm UUID: 2485ef0c-25fe-4863-bd49-fad1aaa0f8bc Ancestors: OpalCompiler-Core-jb.29, OpalCompiler-Core-JorgeRessia.29 more work for scope analysis... -> after variables are re-looked up, add copying temps to outer scop -> Fixes ==================== Summary ==================== Name: OpalCompiler-Tests-JorgeRessia.26 Author: JorgeRessia Time: 7 September 2010, 9:29:08 pm UUID: 4def3fb1-2057-45fe-b7f7-62f057c999fb Ancestors: OpalCompiler-Tests-MarcusDenker.25 - Introduction of optimized block scopes. - the closure analysis is been moved out of the astchecker ==================== Summary ==================== Name: OpalCompiler-Core-JorgeRessia.29 Author: JorgeRessia Time: 7 September 2010, 9:28:46 pm UUID: 02e0a230-43fb-4c08-97f2-a767968faaf8 Ancestors: OpalCompiler-Core-MarcusDenker.28 - Introduction of optimized block scopes. - the closure analysis is been moved out of the astchecker ==================== Summary ==================== Name: OpalCompiler-Core-jb.29 Author: jb Time: 7 September 2010, 11:31:01 am UUID: 06331cc1-732f-4e49-8327-1d6eef92bf26 Ancestors: OpalCompiler-Core-MarcusDenker.28 Fix some bug about Jump in decompiler and clean a bit the code.

1 0

[Pharo-project] [update 1.2] #12131
by StÃ©phane Ducasse Sept. 9, 2010

Sept. 9, 2010

12131 ----- - Issue 2936: DateAndTimeTest has failures. Thanks Pavel Krivanek. - Issue 2937: TimespanTest >> testEnd failing. Thanks Pavel Krivanek. - Issue 2929: remove #tiny, #tinyDisplay and the class var Tiny. - Issue 2499: MaskedTextMorph class for masked input fields. Thanks Dionisiygod. Stef

1 0

[Pharo-project] TimespanTest >> testEnd failing
by Pavel Krivanek Sept. 9, 2010

Sept. 9, 2010

http://code.google.com/p/pharo/issues/detail?id=2937

2 1

[Pharo-project] DateAndTimeTest failures
by Pavel Krivanek Sept. 9, 2010

Sept. 9, 2010

Hi, I tried to fix DateAndTimeTest failures, see http://code.google.com/p/pharo/issues/detail?id=2936 The patch adds methods clearOffset and withoutOffset to DateAndTime. Cheers, -- Pavel

2 3

[Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.
by John M McIntosh Sept. 9, 2010

Sept. 9, 2010

Ok, I was going to spend a few of my precious evenings going thru and rebuilding all/some of the plugins for the Cocoa V5.x series of VMs. Maybe even update them for the Cog Stack and JIT VM. However to do this I need some help from the community to test the creatures after they are done. This evening I rebuild the Locale plugin and checked it into SVN to close this Pharo issue: http://code.google.com/p/pharo/issues/detail?id=2660 Now the problem is the Smalltalk code "Locale" for talking to this plugin sucks, it doesn't actually call most of the primitives and there aren't any tests. Obviously if no-cares about using the plugin then I can't be bothered to poke at it. However I did write some Objective-C code and jiggle it with a stick. Therefore someone should write some tests, fix the Locale Class, etc and tell me if the plugin is sane. You'll find the plugin in the Experimental Folder sub folder "5.x Plugins" http://homepage.mac.com/johnmci/.Public/experimental/5.x%20Plugins/LocalePl… Just unzip and drop it into the *.app/Contents/Resources/ folder Now this might work with Squeak 4.x VMs, I've not tried it. It might work with 64bit VMs (5.7x), I've not tried it. It might work on PowerPC, I've not tried it. It should work on the 5.8x series but I've not tried it out of canadian english, metric, PST, daylight savings time, georgian calendar settings so I have no idea if it works oh say in France where you use Euros versus $ signs? I've not bothered ported to iOS devices since it's unclear if anyone supports the Locale class? Lastly I'll take suggestions on which plugin to rework next. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

2 5