- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.4] #14142
by Marcus Denker Sept. 16, 2011

Sept. 16, 2011

14142 ----- Issue 4798: Improved CompiledMethod>>isAbstract Issue 4798: Improved CompiledMethod>>isAbstract - do a #cleanUpForRelease -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 1.4] #14141
by Marcus Denker Sept. 16, 2011

Sept. 16, 2011

14141 ----- Issue 2986: DemoMode should not change Fonts only sizes http://code.google.com/p/pharo/issues/detail?id=2986 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Glorp question
by Friedrich Dominicus Sept. 16, 2011

Sept. 16, 2011

Well this may be an ambigous question, but can Glorp generate a description from an existent relationatl Database model? e.g assume i wouuld have Customer id integer field1 string field2 integer address_id foreign key into address address id integer zip .... And Glorp generates a Model from it? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

2 2

[Pharo-project] Smalltalks 2011: Call for Submission/Participacion
by Fundacion FAST Sept. 16, 2011

Sept. 16, 2011

Sorry for multiple copies Following you have the Spanish version of the Smalltalks 2011 Call for Submission/Participation ======== ENGLISH The FundaciÃ³n Argentina de Smalltalk (FAST, http://www.fast.org.ar) invites you to the 5th Argentine Smalltalk Conference, to be held on November 3, 4 and 5, 2011 at the Quilmes University located in Buenos Aires. Everyone, including teachers, students, researchers, developers and entrepreneurs, are welcome as speakers or attendees. Registration is free and now open at http://www.fast.org.ar/smalltalks2011 The goal of the Conference is to strengthen the bonds between the Argentine and the international Smalltalk community through the exchange of works, experiences and anecdotes connected with this technology and related matters. As in the previous editions, renowned members of the international Smalltalk community will visit us, and like last year we will have a Research Session with publications reviewed by an international committee. Also, the traditional Industry Track will be available for those who prefer a more practical environment. You can submit papers or talks now through our website at http://www.fast.org.ar/smalltalks2011/technical-session Finally, a Pharo Sprint will be held prior to the conference for those willing to help the community coding, and two seminars will take place for those who want to get acquainted with or learn more about Smalltalk. For more information go to http://www.fast.org.ar/smalltalks2011/events For any questions please contact us at info(a)fast.org.ar. See you there! ==== SPANISH La FundaciÃ³n Argentina de Smalltalk (FAST, http://www.fast.org.ar) los invita a la 5ta Conferencia de Smalltalk de Argentina, a realizarse desde el 3 al 5 de Noviembre del 2011 en la sede de la Universidad de Quilmes, Buenos Aires. Esperamos verlos a todos entre la audiencia o como oradores, ya sean profesores, estudiantes, investigadores, desarrolladores o empresarios. La registraciÃ³n es gratis y estÃ¡ disponible en http://www.fast.org.ar/smalltalks2011 El objetivo de la conferencia es afianzar los vÃnculos entre las comunidades Smalltalk de Argentina y del mundo y con todo desarrollador, educador o investigador que utilice el paradigma de Objetos. Esto lo lograremos a travÃ©s del intercambio de trabajos, experiencias y vivencias conectadas con esta tecnologÃa. Nuevamente en esta ediciÃ³n nos visitarÃ¡n personalidades de renombre de la comunidad internacional y contaremos con un track de investigaciÃ³n formal con publicaciones y referato de un comitÃ© internacional. Contaremos tambiÃ©n con el tradicional track de industria para aquellos que prefieran un ambiente mÃ¡s prÃ¡ctico. Pueden suscribir sus propuestas de charlas o papers mediante nuestra pÃ¡gina web en http://www.fast.org.ar/smalltalks2011/technical-session Por Ãºltimo, se realizarÃ¡ un Pharo Sprint para todos aquellos que tengan interÃ©s de aportar concretamente con cÃ³digo a la comunidad y se dictarÃ¡n dos seminarios para aquellos que quieran entender y conocer mÃ¡s Smalltalk. Para mÃ¡s informaciÃ³n ir a http://www.fast.org.ar/smalltalks2011/events Cualquier duda no dejen de consultarla enviando un mail a info(a)fast.org.ar Nos vemos en la conferencia!

1 0

[Pharo-project] Explicit return in []
by StÃ©phane Ducasse Sept. 15, 2011

Sept. 15, 2011

Hi this is early (at least to me) and I was asking myself a probably stupid question. But I would like to get your smart answers :) does a smalltalk like language really need explicit return in []? Q1 When are they absolutely required? Q2 What replacing mechanisms would be needed? Q3 What would we gain from an implementation stand point? It seems that in resilience lars removed them and more. Stef for Q1 I see foo x isZero ifTrue: [^ 33]. self continue

7 18

Re: [Pharo-project] [squeak-dev] Re: Issue 4538 and CompiledMethod equality
by Eliot Miranda Sept. 15, 2011

Sept. 15, 2011

On Thu, Sep 15, 2011 at 1:00 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/9/15 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Thu, Sep 15, 2011 at 9:45 AM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> Ok, I understand. But > >> > >> On Thu, Sep 15, 2011 at 6:05 PM, Henrik Sperre Johansen > >> <henrik.s.johansen(a)veloxit.no> wrote: > >>> > >>> On 15.09.2011 17:27, Mariano Martinez Peck wrote: > >>> > >>> Hi guys. I am having a problem with the integration of issue 4538: > >>> http://code.google.com/p/pharo/issues/detail?id=4538 > >>> > >>> I am serializing CompiledMethods with Fuel and then I materialize them. > >>> To test they are correct, I use #= > >>> So far it was working correctly, but now for the materialized method it > >>> says they are not equal. The problem is that #= is failing in > >>> > >>> (self sameLiteralsAs: aCompiledMethod) > >>> > >>> And inside that method, it is failing because (literal1 == literal2 > >>> or: [ literal1 literalEqual: literal2 ]) > >>> answers false. > >>> > >>> So... why literal1 literalEqual: literal2 answers false? from what I > can > >>> say, having that selector: "literalEqual", then both MUST be equal, > because > >>> they are. > >>> The problem is that it was added: > >>> > >>> Association >> literalEqual: otherLiteral > >>> "Answer true if the receiver and otherLiteral represent the same > >>> literal. > >>> Variable bindings are literally equals only if identical. > >>> This is how variable sharing works, by preserving identity and > >>> changing only the value." > >>> ^self == otherLiteral > >>> > >>> > >>> So....I am not sure I agree with this change. > >>> > >>> Any idea how can we deal with this problem? > >>> > >>> Cheers > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> > >>> The change is correct, here's an example: > >>> > >>> Create a global: > >>> Global := 1 > >>> > >>> Create a method: > >>> foo > >>> ^Global > >>> > >>> Serialize method, deserialize > >>> > >>> Change value of global: > >>> Global := 5. > >>> > >>> foo should return 5, not 1. > >>> Unless it's actually the same association as in the SystemDictionary, > >>> this will not be true. > >>> > >> > >> I understand that. In fact, in Fuel we use exactly the same association > of > >> SystemDictionary for globals. Look this test example: > >> > >> testGlobalVariableMethod > >> > >> | materializedCompiledMethod | > >> Smalltalk globals at: #TestGlobalVariableMethod2 put: false. > >> (self class compileSilently: 'globalVariableForTestingMethod > >> Transcript name. > >> ^ GlobalVariableForTesting.'). > >> > >> materializedCompiledMethod := self materializedCompiledMethod: (self > >> class >> #globalVariableForTestingMethod). > >> Smalltalk globals at: #GlobalVariableForTesting put: true. > >> self assert: (materializedCompiledMethod valueWithReceiver: self > >> arguments: #()). > >> > >> > >> > >> BUT, it doesn't mean that Association is always used for globals. > >> CompiledMethod equality is failing because of the last literal, the one > that > >> maps class name (symbol) and point to the real class. So...when I > >> materialize, both CMs have non-identical associations for the last > literal, > >> but equal. > > > > As Henrik says the last literals are ideally #== to each other. However, > no > > Squeak dialect makes any attempt to keep the class0side associations > equal. > > Look at a class-side method and you'll see it's last literal is > > nil->SomeClass class. Now since this association doesn't exist in > Smalltalk > > (unlike last literals on the instance side) the compiler merely creates > > distinct ones for each class-side method. > > Personally I don't think one can defend the position where method > equality > > is different for instance-side or class-side methods so there must be > some > > solutions: > > Hmm, good catch. > A metaclass is never accessed by dictionary lookup, but only by > sending #class to a class, so there is no point in maintaining a > unique Association. > (otherwise, we could maintain such Association in inst. var. thisClass). > Having a nil key is a clear indication that lookup is pointless. > > The question is why having an association at all in the CompiledMethod ? > For handling super sends ? > Yes, but two reasons. One is super sends and the other is being able to answer the methodClass (e.g. for CompiledMethod>>printOn: and for the debugger). One doesn't need to use an association, but one can't change that without changing al the VMs /and/ changing the ClassBuilder so that when it becomes a class on class redefinition the methodsa are updated. Indeed VisualWorks does exactly this. In any case, the super send implementation in the VM means we can't change this overnight :) > I think a simple reference to the class would be enough. > IMHO, the purpose was to simplify implementation. > > And I don't think the example of Henrik is worth : > Lets just change it a bit: > > Object subclass: #SuperFoo.! > Object subclass: #Bar.! > SuperFoo subclass: #Foo.! > > SuperFoo compile: 'bar ^1'. > Foo compile: 'bar > ^super bar *2'. > foo := Foo new. > Smalltalk at: #Foo put: Bar. > ^foo bar > > Could you predict the result (will it try to invoke super Bar bar) ? > Yes, since the last association is shared, we just broke (foo > class>>bar) for no reason... > Right. But Rube Goldberg machines work like Rube Goldberg machines. Tis the nature of the beast. Doctors say "don't do that", and in Smalltalk we should say "what did you expect"? :) Being able to change the system is worth the cost of it behaving contrary to common-sense. Just like the physical world :) > Nicolas > > > 1. special case comparison of the last literal (the methodClass literal), > > comparing keys and insisting that the keys be #== and the values be #== > > (can't just define it as keys #== since all similar class-side methods > will > > be equal irrespective of their actual class). > > 2. special case comparison of the last literal (the methodClass literal), > > insisting only that the class of the literal be the same if it > > isVariableBinding. > > 3. make the compile unique class-side methodClass literals. i.e. if a > class > > already has a class-side method then the compiler or method dictionary > > insertion code must find that existing association and reuse it > > Other ideas? > > > >> > >> >From my point of view, that literal, the last one does not need to be > >> identical to assume 2 CMs are equal. They just need to be equal. > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > > > > > -- > > best, > > Eliot > > > > > > > > > > -- best, Eliot

1 0

Re: [Pharo-project] [update 1.4] #14141
by Marcus Denker Sept. 15, 2011

Sept. 15, 2011

On Sep 15, 2011, at 2:48 PM, StÃ©phane Ducasse wrote: >> Proably, clearly some more work is required before it is ready >>> (maybe a StackLayout with the adornment in a spaceFill Panel with proportional layout would work) >>> >> >> Now doing the undo with yet another update would be a lot of work... >> >> Is is ok to just remove update 14141-1413 from the update stream? > > Yes Done and Jenkins build re-started. I will take some time off from integrating fixes.. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] [update 1.4] #14141
by Marcus Denker Sept. 15, 2011

Sept. 15, 2011

On Sep 15, 2011, at 2:21 PM, Gary Chambers wrote: > Proably, clearly some more work is required before it is ready > (maybe a StackLayout with the adornment in a spaceFill Panel with proportional layout would work) > Now doing the undo with yet another update would be a lot of work... Is is ok to just remove update 14141-1413 from the update stream? -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] [update 1.4] #14141
by Marcus Denker Sept. 15, 2011

Sept. 15, 2011

On Sep 15, 2011, at 1:40 PM, Gary Chambers wrote: > Somewhat... > The change in PluggableTextMorph>>initialize to a proportional layout > affects the minExtent calculation, hence splitters for text will not allow shrinkage any more... > Maybe we should just undo all the changes... -- Marcus Denker -- http://marcusdenker.de

3 2

[Pharo-project] Class>>asRingDescription
by Fernando Olivero Sept. 15, 2011

Sept. 15, 2011

Veronica, i've started to adopt Ring in Gaucho. Very nice work, excellent tests also! A question, why does the following is true? Collection asRingDefinition methods isEmpty = true If you look at the following method, they should be added here right?, on the ring definition creation. Class>>asRingDefinition | ring | ring := (RGFactory current createClassNamed: self name) category: self category; superclassName: self superclass name; traitCompositionSource: self traitCompositionString; addInstanceVariables: self instVarNames; addClassVariables: self classVarNames; addPoolDictionaries: self poolDictionaryNames; comment: self organization classComment; stamp: self organization commentStamp; definitionSource: self definition; withMetaclass. ring theMetaClass traitCompositionSource: self theMetaClass traitCompositionString; definitionSource: self theMetaClass definition; addInstanceVariables: self theMetaClass instVarNames. ^ring I'm using the latest Pharo1.4 from Jenkins. Fernando

1 0