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

[Pharo-project] MNU MIMETYPE class>>forURIReturnSingleMimeTypeOrDefault:

by Diogenes Moreira

Hi.. that is a StandardFileStream bug or I'm loosing some thing... may be a versions problem.. somebody can say where is implement that method. Best

Feb. 18, 2011

Re: [Pharo-project] Pharo on LinkedIn ...

by Geert Claes

Sven Van Caekenberghe wrote: > > 63 and counting... > 74 and counting .... -- View this message in context: http://forum.world.st/Pharo-on-LinkedIn-tp3312460p3312759.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 18, 2011

[Pharo-project] Issue 3733 in pharo: Float>>roundUpTo: wrong results

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3733 by Dionisiy...(a)gmail.com: Float>>roundUpTo: wrong results http://code.google.com/p/pharo/issues/detail?id=3733 Try this: (test casa in attachenment) 560.19 roundUpTo: 0.01 >>> 560.2 500.19 roundUpTo: 0.01 >>> 500.19 Attachments: RoundUpToTests.st 560 bytes

Feb. 18, 2011

Re: [Pharo-project] A new GUI visual designer

by Schwab,Wilhelm K

Craig, If I am following this correctly, it's over-engineered and will back fire. You are setting up some of the same mistakes that were made in SmartReferenceStream, only with both sides involved. This is a simple problem calling for a careful solution. Dolphin has this right: version the serialized streams, and the consumer either knows how to read it or not; errors result in the latter case. What you are doing *could* be ok with the developer of both systems on hand to monitor it, but that will be rare. In fact, one might assert that serializers are useful precisely when one of the parties is absent: otherwise one would simply pass the object and be done with it. What you want are tools that make it easy to write the converters (which belong in the affected classes, not the serializer - another SmartReferenceStream oddity). SIXX *might* avoid some of this by focusing on messages rather than instance variable layout, but even then, some attention to legacy data would be required. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Craig Latta [craig(a)netjam.org] Sent: Thursday, February 17, 2011 8:04 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] A new GUI visual designer Hi GÃ¶ran-- > Thinking about this a bit more I realize one interesting aspect: > > Your stuff is basically low level serialization support - right? It is, but what makes it interesting is that it's *interactive* serialization; the producing and consuming systems interact. Traditionally, you serialize to a file, and at the time the consuming system reads it, the producing system is long gone. The consumer can't ask the producer anything about it if finds something confusing, and the producer can't take any information about the consumer into account when creating the bits. Speaking of recipes, imagine following a recipe from a cookbook. You might wonder if you can leave some ingredient out (because you forgot to go the store), but you're on your own figuring that out. All you have is the recipe. But if the author of the recipe were there with you, telling you what to do, you could just ask. And the author might not even bother mentioning the missing ingredient, because he can already see when you start that you don't have it. It's this sort of synchronization that Naiad (Spoon's module system) supports. It's important when transferring individual method literals, entire methods, and entire modules. It's all messages going across the wire between producer and consumer, and their precise content may vary significantly from one consumer to another. Expecting one set of bits to convey the correct thing to all consumers, in a system as dynamic as Smalltalk, always struck as me a bit crazy. :) > So... it all boils down to what kind of object model you pick. Now... > come to think of it - readable and editable? Not sure how you mean > there... I meant it in the sense that I thought you did... the way I'd store GUI information is even more readable than viewspec arrays or XML because it's just the original objects from which we derived the viewspecs and XML. It's more editable for the same reason; we can use the same powerful inspectors and browsers that we used during development. > ...counting the designer tool as the editor is kinda cheating :) Hey, if it's useful, why not? :) > One nice way to make a GUI description to be very robust against > change is to let it be the representation of "a sequence of commands > aimed at a builder API". Thus, the actual UI framework can change all > it wants, as long as the builder API still works. > > So, if your object model is such a "command sequence" then I agree, it > would be as robust as the same thing in Tirade. But... if your model > is the actual built UI then I don't agree that it is as robust - > supporting "migration" from one object model to a new one is kinda > complex. Well, builder APIs can change, too. But sure, I'm not attached to any particular GUI object model, or style of model (declarative or otherwise). I do think, though, that using the actual built UI becomes an interesting option when you have live synchronization. I view the complexity as similar to writing correct "postCopy" methods (not too bad). You could ask a UI object to spit out builder commands, for example, as I suggested in an earlier message. Builder commands could be an exchange format, used occasionally when necessary. -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

Feb. 18, 2011

Re: [Pharo-project] Pharo on LinkedIn ...

by Sven Van Caekenberghe

63 and counting... On 18 Feb 2011, at 12:11, Geert Claes wrote: > We would like to invite those Pharoers who have a LinkedIn account to join > our LinkedIn Pharo group. > > http://www.linkedin.com/e/hzbhb7-gkawp6l9-36/vgh/2558378/

Feb. 18, 2011

Re: [Pharo-project] 1.2 Dev Status

by StÃ©phane Ducasse

for 5) I fixed it. Stef > Little update! > > Build is working now: https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ > > There are already some tests to fix: > > >>> CollectionsTests.Arrayed.FloatArrayTest.testArithmeticCoercion 0.0030 1 > >>> Metacello.TestsMC.MetacelloCurrentVersionTest.testFoo40Loaded1Package1LaterPackage 3.363 18 > >>> Metacello.TestsMC.MetacelloGoferBasedAtomicLoaderTest.testBaselineFetch 0.059 18 > >>> Metacello.TestsMC.MetacelloGoferBasedAtomicLoaderTest.testBaselineLoad 0.757 18 > >>> Metacello.TestsMC.MetacelloGoferBasedAtomicLoaderTest.testIssue49PartialLoadC 1.506 18 > >>> Metacello.TestsMC.MetacelloGoferBasedAtomicLoaderTest.testIssue49PartialLoadG 1.717 18 > >>> Metacello.TestsMC.MetacelloGoferBasedLoaderTest.testIssue49PartialLoadC 1.62 18 > >>> Metacello.TestsMC.MetacelloGoferBasedLoaderTest.testIssue49PartialLoadG 1.774 18 > >>> Metacello.TestsMC.MetacelloGoferBasedLoaderTest.testBaselineLoad 0.828 18 > >>> Metacello.TestsMC.MetacelloGoferBasedLoaderTest.testBaselineFetch 0.058 18 > >>> Metacello.TestsMC.MetacelloGoferFunctionalTest.testPackageResolution 0.011 18 > >>> Metacello.TestsMC.MetacelloGoferFunctionalTest.testComparison 0.0080 18 > >>> Metacello.TestsMC.MetacelloMCCachingLoaderTestCase.testBaselineLoad 0.963 18 > >>> Metacello.TestsMC.MetacelloMCSpecLoaderTest.testLatestPackage 0.016 18 > >>> Tests.Release.ReleaseTest.testObsoleteClasses 1.081 56 > >>> Refactoring.Tests.Core.RBInlineMethodFromComponentTest.testInlineEmptyComponentMethod 0.148 102 > >>> Tests.Release.ReleaseTest.testUndeclared > > > 1) Most of them (actually 13 of 17), are from metacello and Gofer. Dale said he's going to replicate Gofer changes to squeak and gemstone, and fix the tests after that. > > 2) One is from the recently added Collections-Arithmetic. It's sending #clone instead of #copy. > > 3) testObsoleteClasses is fixed here (http://code.google.com/p/pharo/issues/detail?id=3681&q=testObsoleteClasses&…) I will > integrate it in a minutes. > > 4) testInlineEmptyComponentMethod is failing because there is an initialization method that is doing: > > Refactoring class>>initializeRefactoringOptions > RefactoringOptions := IdentityDictionary new. > RefactoringOptions > at: #implementorToInline > put: [ :ref :imps | self error: #implementorToInline ]; > > at: #methodName > put: [ :ref :methodName | self error: #methodName ]; > > at: #selfArgumentName > put: [ :ref | self error: #selfArgumentName ]; > > at: #selectVariableToMoveTo > put: [ :ref :class :selector | self error: #selectVariableToMoveTo ]; > > at: #variableTypes > put: [ :ref :types :selected | self error: #variableTypes ]; > > at: #extractAssignment > put: [ :ref :varName | self error: #extractAssignment ]; > > at: #inlineExpression > put: [ :ref :string | self error: #inlineExpression ]; > > at: #alreadyDefined > put: [ :ref :cls :selector | self error: #alreadyDefined ]; > > at: #useExistingMethod > put: [ :ref :selector | self error: #useExistingMethod ]; > > at: #openBrowser > put: [ :ref :env | self error: #openBrowser ] > > And it breaks when the test is using that dictionary elements ;). Does someone know about it? > > 5) testUndeclared. Undeclared still has inside it #CustomMenu, #DefaultStubs, #KedamaFloatArray. > #CustomMenu is fixed (http://code.google.com/p/pharo/issues/detail?id=3712&q=CustomMenu&colspec=I…) I'll integrate it in a while. > #DefaultStubs remains to be fixed: (http://code.google.com/p/pharo/issues/detail?id=3711&q=DefaultStubs&colspec…) > #KedamaFloatArray is referenced in WordArray #+, #-, #*, #=. Should it be referencing to FloatArray instead? :P. It's a change for Collection-Arithmetic. > > Any clue about unresolved tasks? > > Thanks! > Guille

Feb. 18, 2011

Re: [Pharo-project] Menu creation and invocation

by Alain Plantec

exactly. We have to specify where to search for the pragmas in order to be able to use the same menu pragma keyword in different contexts. I can't dig into it now but this is the idea. Cheers Alain Le 18/02/2011 11:41, Henrik Johansen a Ã©crit : > If I understood him correctly, essentially, you limit the scope of a menu symbol. > > When using globalPragmaKeyword: (pragmaKeyword: today) it will search for methods containing the pragma in the entire system, which means you can have multiple classes defining menu entries in the same (global) menu. > When using pragmaKeyword: (or what Alain calls localPragmaKeyword: ), only the hierarchy of the class in in which the method defining the PragmaMenuBuilder would be searched. > Thus, you could have two different morph classes both defining<menu: #rightClickMenu> entries, and have their menu builders only pick up those defined for that class. > > Cheers, > Henry >

Feb. 18, 2011

Re: [Pharo-project] Menu creation and invocation

by Alain Plantec

Le 18/02/2011 10:40, Henrik Johansen a Ã©crit : > Yes, searching the class only would be a good idea, I'd almost consider making it the default and rename #pragmaKeyword: to #globalPragmaKeyword:. yes, I will do it. > It's faster, and in most cases it does what you need, also in the case where you want extensibility (through extension methods, only risk is clashing names) > > Cheers, > Henry

Feb. 18, 2011

[Pharo-project] Issue 3732 in pharo: default omni browser size bigger

by pharo＠googlecode.com

Status: Accepted Owner: guillerm...(a)gmail.com Labels: Milestone-1.2-DevImage New issue 3732 by guillerm...(a)gmail.com: default omni browser size bigger http://code.google.com/p/pharo/issues/detail?id=3732 please :)

Feb. 18, 2011

[Pharo-project] Issue 3731 in pharo: default browser size bigger

by pharo＠googlecode.com

Status: Accepted Owner: guillerm...(a)gmail.com Labels: Milestone-1.2 New issue 3731 by guillerm...(a)gmail.com: default browser size bigger http://code.google.com/p/pharo/issues/detail?id=3731 please :)

Feb. 18, 2011