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

[Pharo-project] [update 1.3] #13251

by StÃ©phane Ducasse

13251 ----- - fixed logic of automatic variable declaration in workspace. - Issue 4364: PragmaMenuBuilder should not use ToolBuilder anymore http://code.google.com/p/pharo/issues/detail?id=4364 - Issue 4366: openModal: withoutToolBuilder reference. http://code.google.com/p/pharo/issues/detail?id=4366 Stef France - Ukraine 1-1 :)

June 6, 2011

Re: [Pharo-project] Do it in Shout Workspace

by Carlo

Your understanding of the meaning is same as mine. If it's true then user of Workspace must declare variable, and by same token if the radio button is not selected then it is expected that they should declare the variable. So your version below makes sense. On 06 Jun 2011, at 10:03 PM, StÃ©phane Ducasse wrote: Thanks carlo now reading the code this is even more confusing.. > mustDeclareVariables to me measn that you should declare var :) so the correct version is mustDeclareVariableWording ^ mustDeclareVariables ifTrue: ['<no> Automatically create variable declaration' translated] ifFalse: ['<yes> Automatically create variable declaration' translated] but I may be wrong. Stef On Jun 6, 2011, at 9:24 PM, Carlo wrote: > Hi > > As far as I can see the behavior is correct. If you declare the variables as you have >> >>> |persons aPerson| > then they won't be bound to the Workspace. > If you do not declare them then these variables should be bound to the Workspace. > You can bring up the Workspace menu and select 'Inspect variables' to see what is bound. > > I did notice though that there is a boolean logic bug compared to squeak 4.1 in > Workspace>>mustDeclareVariableWording > > ^ mustDeclareVariables not > ifTrue: ['<yes> Automatically create variable declaration' translated] > ifFalse: ['<no> Automatically create variable declaration' translated] > > The 'not' is missing from Pharo1.3 whereas it should be there. This only affects the display logic which may confuse users to which mode they are in. What do you mean? Because we should have the **same** working (not <>) in both branches since the info is displayed as a radio button. if the radio button is on, it creates variable definiton, if this is off = no it says it is off (to the creation of variable and not their non creation) :) So I guess that my proposal is correct but let us know. Stef > > Carlo > > On 06 Jun 2011, at 5:16 PM, StÃ©phane Ducasse wrote: > > Hi miguel > > this is probably linked to the way the workspace keeps its binding to declare variable. > Can you check in 1.3 because we will release it soon. > > Stef > > On Jun 6, 2011, at 4:09 PM, Miguel Sanchez wrote: > >> Hi All, >> >> I'm not sure if this is a bug or a feature or PEBKAC error. >> >> I have strange behaviour In Pharo one click 1.1.1 and 1.2.1, when I open a Shout Workspace and enter the following: >> =============================================== >> >> "Person is a dirty little class that maps from a DB table and a horrible complete creation method." >> >> |persons aPerson| >> >> aPerson := Person personId: '32055' personTypeId: '1' nationalId: 'I00735' firstName: 'ANA ROSA' surname: 'XXX YYY ZZZ' title: 'Ms' birthday: ('01/01/1970' asDate) language: 'ES ' gender: 'F' maritalStatus: 'M' nationality: 'ES' countryOfResidence: 'IT' activity: 'CN-O' regDate: '17/06/2009 00:00:00' vatRegNo: '1234'. >> >> persons := Set new. >> >> persons add: aPerson. >> >> persons add: 3. >> =============================================== >> >> If I ctrl-d each statement individually. after the final line. persons is a set with the two elements I have just added. >> >> If I open a fresh shout workspace, copy and paste the code, select all, and ctrl-d all the text, then I get persons = nil. afterwards. >> >> I've debugged and both methods execute in the same way. >> >> So like I said, bug, feature or PEBKAC? >> >> Thanks, >> >> >> Miguel > > > >

June 6, 2011

Re: [Pharo-project] Do it in Shout Workspace

by StÃ©phane Ducasse

Thanks carlo now reading the code this is even more confusing.. > mustDeclareVariables to me measn that you should declare var :) so the correct version is mustDeclareVariableWording ^ mustDeclareVariables ifTrue: ['<no> Automatically create variable declaration' translated] ifFalse: ['<yes> Automatically create variable declaration' translated] but I may be wrong. Stef On Jun 6, 2011, at 9:24 PM, Carlo wrote: > Hi > > As far as I can see the behavior is correct. If you declare the variables as you have >> >>> |persons aPerson| > then they won't be bound to the Workspace. > If you do not declare them then these variables should be bound to the Workspace. > You can bring up the Workspace menu and select 'Inspect variables' to see what is bound. > > I did notice though that there is a boolean logic bug compared to squeak 4.1 in > Workspace>>mustDeclareVariableWording > > ^ mustDeclareVariables not > ifTrue: ['<yes> Automatically create variable declaration' translated] > ifFalse: ['<no> Automatically create variable declaration' translated] > > The 'not' is missing from Pharo1.3 whereas it should be there. This only affects the display logic which may confuse users to which mode they are in. What do you mean? Because we should have the **same** working (not <>) in both branches since the info is displayed as a radio button. if the radio button is on, it creates variable definiton, if this is off = no it says it is off (to the creation of variable and not their non creation) :) So I guess that my proposal is correct but let us know. Stef > > Carlo > > On 06 Jun 2011, at 5:16 PM, StÃ©phane Ducasse wrote: > > Hi miguel > > this is probably linked to the way the workspace keeps its binding to declare variable. > Can you check in 1.3 because we will release it soon. > > Stef > > On Jun 6, 2011, at 4:09 PM, Miguel Sanchez wrote: > >> Hi All, >> >> I'm not sure if this is a bug or a feature or PEBKAC error. >> >> I have strange behaviour In Pharo one click 1.1.1 and 1.2.1, when I open a Shout Workspace and enter the following: >> =============================================== >> >> "Person is a dirty little class that maps from a DB table and a horrible complete creation method." >> >> |persons aPerson| >> >> aPerson := Person personId: '32055' personTypeId: '1' nationalId: 'I00735' firstName: 'ANA ROSA' surname: 'XXX YYY ZZZ' title: 'Ms' birthday: ('01/01/1970' asDate) language: 'ES ' gender: 'F' maritalStatus: 'M' nationality: 'ES' countryOfResidence: 'IT' activity: 'CN-O' regDate: '17/06/2009 00:00:00' vatRegNo: '1234'. >> >> persons := Set new. >> >> persons add: aPerson. >> >> persons add: 3. >> =============================================== >> >> If I ctrl-d each statement individually. after the final line. persons is a set with the two elements I have just added. >> >> If I open a fresh shout workspace, copy and paste the code, select all, and ctrl-d all the text, then I get persons = nil. afterwards. >> >> I've debugged and both methods execute in the same way. >> >> So like I said, bug, feature or PEBKAC? >> >> Thanks, >> >> >> Miguel > > > >

June 6, 2011

Re: [Pharo-project] supporting bootstrap

by Carlo

Sorry ignore...didn't read your comment... On 06 Jun 2011, at 9:51 PM, Carlo wrote: How about: (((value class isObsolete not) and: [value isTrait not]) and: [ key == value name ]) not sure if it covers all the same scenarios but in my image it gave the same answers as before the change: Smalltalk globals flushClassNameCache. Smalltalk globals classNames size. 1940 Smalltalk globals nonClassNames size. 96 Cheers Carlo On 06 Jun 2011, at 9:28 PM, StÃ©phane Ducasse wrote: fillCaches "Fill cachedClassNames and cachedNonClassNames. Return an array with the calculated values." | classNames nonClassNames | classNames := OrderedCollection new: self size. nonClassNames := OrderedCollection new. self keysAndValuesDo: [ :key :value | "The key == value name test below addresses two separate issues: 1) Obsolete classes, where key = #Foo and value name = 'AnObsoleteFoo' 2) Aliases, i.e., Smalltalk at: #OtherName put: aClass" ((value isKindOf: (self class environment at: #Class)) and: [ key == value name ]) ifTrue: [ classNames add: key ] ifFalse: [ nonClassNames add: key ] ]. "The expression (self class environment at: #Class) deserves some explanation. For bootstrapping we need to have a different Class when executing value isKindOf: Class : In such expression Class represents a kind of fixed point: the class of the class of the system. When bootstrapping we want the class Class of the current kernel defined in the current namespace. Since the current namespace should contains the class that describes itself as well as a new Class class. we are done :). - StephaneDucasse" classNames sort. cachedNonClassNames := nonClassNames sort. cachedClassNames := classNames. ^{ classNames. nonClassNames } Stef France - ukraine still 0-0 :)

June 6, 2011

Re: [Pharo-project] supporting bootstrap

by Carlo

How about: (((value class isObsolete not) and: [value isTrait not]) and: [ key == value name ]) not sure if it covers all the same scenarios but in my image it gave the same answers as before the change: Smalltalk globals flushClassNameCache. Smalltalk globals classNames size. 1940 Smalltalk globals nonClassNames size. 96 Cheers Carlo On 06 Jun 2011, at 9:28 PM, StÃ©phane Ducasse wrote: fillCaches "Fill cachedClassNames and cachedNonClassNames. Return an array with the calculated values." | classNames nonClassNames | classNames := OrderedCollection new: self size. nonClassNames := OrderedCollection new. self keysAndValuesDo: [ :key :value | "The key == value name test below addresses two separate issues: 1) Obsolete classes, where key = #Foo and value name = 'AnObsoleteFoo' 2) Aliases, i.e., Smalltalk at: #OtherName put: aClass" ((value isKindOf: (self class environment at: #Class)) and: [ key == value name ]) ifTrue: [ classNames add: key ] ifFalse: [ nonClassNames add: key ] ]. "The expression (self class environment at: #Class) deserves some explanation. For bootstrapping we need to have a different Class when executing value isKindOf: Class : In such expression Class represents a kind of fixed point: the class of the class of the system. When bootstrapping we want the class Class of the current kernel defined in the current namespace. Since the current namespace should contains the class that describes itself as well as a new Class class. we are done :). - StephaneDucasse" classNames sort. cachedNonClassNames := nonClassNames sort. cachedClassNames := classNames. ^{ classNames. nonClassNames } Stef France - ukraine still 0-0 :)

June 6, 2011

Re: [Pharo-project] supporting bootstrap

by StÃ©phane Ducasse

fillCaches "Fill cachedClassNames and cachedNonClassNames. Return an array with the calculated values." | classNames nonClassNames | classNames := OrderedCollection new: self size. nonClassNames := OrderedCollection new. self keysAndValuesDo: [ :key :value | "The key == value name test below addresses two separate issues: 1) Obsolete classes, where key = #Foo and value name = 'AnObsoleteFoo' 2) Aliases, i.e., Smalltalk at: #OtherName put: aClass" ((value isKindOf: (self class environment at: #Class)) and: [ key == value name ]) ifTrue: [ classNames add: key ] ifFalse: [ nonClassNames add: key ] ]. "The expression (self class environment at: #Class) deserves some explanation. For bootstrapping we need to have a different Class when executing value isKindOf: Class : In such expression Class represents a kind of fixed point: the class of the class of the system. When bootstrapping we want the class Class of the current kernel defined in the current namespace. Since the current namespace should contains the class that describes itself as well as a new Class class. we are done :). - StephaneDucasse" classNames sort. cachedNonClassNames := nonClassNames sort. cachedClassNames := classNames. ^{ classNames. nonClassNames } Stef France - ukraine still 0-0 :)

June 6, 2011

[Pharo-project] [update 1.3] #13250

by StÃ©phane Ducasse

13250 ----- - Issue 4368: tests in SystemNavigationOnNewlyCreatedEnvironmentTest failing. http://code.google.com/p/pharo/issues/detail?id=4368 - Issue 4369: tests failing: ClassFactoryWithOrganizationTest http://code.google.com/p/pharo/issues/detail?id=4369

June 6, 2011

Re: [Pharo-project] Do it in Shout Workspace

by Carlo

Hi As far as I can see the behavior is correct. If you declare the variables as you have > >> |persons aPerson| then they won't be bound to the Workspace. If you do not declare them then these variables should be bound to the Workspace. You can bring up the Workspace menu and select 'Inspect variables' to see what is bound. I did notice though that there is a boolean logic bug compared to squeak 4.1 in Workspace>>mustDeclareVariableWording ^ mustDeclareVariables not ifTrue: ['<yes> Automatically create variable declaration' translated] ifFalse: ['<no> Automatically create variable declaration' translated] The 'not' is missing from Pharo1.3 whereas it should be there. This only affects the display logic which may confuse users to which mode they are in. Carlo On 06 Jun 2011, at 5:16 PM, StÃ©phane Ducasse wrote: Hi miguel this is probably linked to the way the workspace keeps its binding to declare variable. Can you check in 1.3 because we will release it soon. Stef On Jun 6, 2011, at 4:09 PM, Miguel Sanchez wrote: > Hi All, > > I'm not sure if this is a bug or a feature or PEBKAC error. > > I have strange behaviour In Pharo one click 1.1.1 and 1.2.1, when I open a Shout Workspace and enter the following: > =============================================== > > "Person is a dirty little class that maps from a DB table and a horrible complete creation method." > > |persons aPerson| > > aPerson := Person personId: '32055' personTypeId: '1' nationalId: 'I00735' firstName: 'ANA ROSA' surname: 'XXX YYY ZZZ' title: 'Ms' birthday: ('01/01/1970' asDate) language: 'ES ' gender: 'F' maritalStatus: 'M' nationality: 'ES' countryOfResidence: 'IT' activity: 'CN-O' regDate: '17/06/2009 00:00:00' vatRegNo: '1234'. > > persons := Set new. > > persons add: aPerson. > > persons add: 3. > =============================================== > > If I ctrl-d each statement individually. after the final line. persons is a set with the two elements I have just added. > > If I open a fresh shout workspace, copy and paste the code, select all, and ctrl-d all the text, then I get persons = nil. afterwards. > > I've debugged and both methods execute in the same way. > > So like I said, bug, feature or PEBKAC? > > Thanks, > > > Miguel

June 6, 2011

[Pharo-project] supporting bootstrap

by StÃ©phane Ducasse

Hi guys with ben we changed ((value isKindOf: Class) and: [ key == value name ]) into fillCaches "Fill cachedClassNames and cachedNonClassNames. Return an array with the calculated values." | classNames nonClassNames | classNames := OrderedCollection new: self size. nonClassNames := OrderedCollection new. self keysAndValuesDo: [ :key :value | "The key == value name test below addresses two separate issues: 1) Obsolete classes, where key = #Foo and value name = 'AnObsoleteFoo' 2) Aliases, i.e., Smalltalk at: #OtherName put: aClass" ((value isKindOf: Class) and: [ key == value name ]) ifTrue: [ classNames add: key ] ifFalse: [ nonClassNames add: key ] ]. classNames sort. cachedNonClassNames := nonClassNames sort. cachedClassNames := classNames. ^{ classNames. nonClassNames } by ((value isKindOf: (self at: #Class)) and: [ key == value name ]) and this is not a good change because it assumes that an environment has a class Class and it jumps over the fix point created by the compiled time binding to Class. Now we did that because in Hazel we build a new kernel and the new environment needs to have its own Class class. Now I have the impression that ((value isKindOf: (self environment at: #Class)) and: [ key == value name ]) is the solution since HSystemDictionary which should be defined in itself could work Now if somebody has a better idea, I'm all ears (esepcially sincewe do not have a nice object to dispatch on). stef

June 6, 2011

[Pharo-project] [update 1.3] #13249

by StÃ©phane Ducasse

13249 ----- Issue 4370: Little fix in TestRunner. Thanks Benjamin van Ryseghem http://code.google.com/p/pharo/issues/detail?id=4370 Stef

June 6, 2011