- Pharo-dev - lists.pharo.org

[Pharo-project] Small tools rant
by Schwab,Wilhelm K Sept. 10, 2010

Sept. 10, 2010

Hello all, I spent some time this morning cleaning up the categorization of some of my code and noted that changing a method category goes something like this: (1) add a new method category; (2) there was no way to paste the desired name, fortunately at least the new one remained selected; (3) rename the newly added category and paste the desired name, adding the * in front of the name; (4) the browser is now filtered to the new category, so nothing is displayed; (5) display all methods again and hunt down the one to be changed; (6) drag it to the new category (after finding same). It is unlikely that I will wade into the tools any time soon; my skills are elsewhere (streams, sockets, etc.). I might be able to create something that would allow programmatic packaging of a compiled method. Does that already exist? Bill

3 4

[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

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