August 2013 - Pharo-dev - lists.pharo.org

New version of PharoSound

by StÃ©phane Ducasse

Hi I merged Jannik clean and I commited a new version of the configuration. Now it works on Pharo 20 and also on Pharo 30 And I will produce a new System-Sound for the kernel based on Pavel work and I will produce a new configuration. Stef

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by HernÃ¡n Morales Durand

Hi Ben, Even if you adopt a type system or definition as part of Smalltalk, it is not coherent nor intuitive with the system usage. Types are not identifiable in Smalltalk, they belong to other systems semantics (both formal and informal) and probably scientific corpus. Because of that, you are having problems to cite those concepts. And type system definitions are inherently unstable because there is no scientific consensus. Does typing correspond with common reality in Smalltalk developement? Why would you need to think in terms of type checking in an object environment? It is ok if you don't want to break contractualism in your thesis, although to me talking about type checking in Smalltalk is the same as talking about L2 cache hits ;) Cheers, HernÃ¡n El 03/08/2013 14:35, btc(a)openinworld.com escribiÃ³: > btc(a)openinworld.com wrote: >> greetings all, >> >> I'm in the final weeks of writing up my Masters dissertation and >> seeking some scholarly references to Smalltalk being "Strongly Typed." >> >> I my review of Smalltalk I was surprised to find that [1] describes >> Smalltalk as Strongly Typed, since Smalltalk is sometimes denigrated >> as being untyped / weakly typed. From reviewing discussion forums this >> now makes sense, but I can only find one of scholarly reference that >> briefly mentions this [2]. The most enlightening is [3] which defines >> Type Strength as: >> >> "A strongly typed language prevents any operation on the wrong type of >> data. In weakly typed languages there are ways to escape this >> restriction: type conversions" >> >> meaning that getting a MNU is a form of Strong Typing since you can't >> make a Smalltalk object run a method that is not its own. The problem >> appears to be that Strong Typing has been synonymous with Static >> Typing for a long time, and Static Typing strongly ties types to >> variables, except in Dynamically Typed languages, I think types can be >> considered independently from variables, in which case the definition >> of [3] has some merit, hence Smalltalk is Strongly Typed. >> >> Sounds controversial, so I'm just hoping for some peer reviewed backup >> - but only you have something easily to hand. This is just a small >> thing I can just leave out if necessary. >> >> cheers -ben >> >> [1] http://www.squeak.org/Features/ >> [2] p15, >> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.7507&rep=rep1&t… >> >> [3] http://www.cs.kuleuven.ac.be/publicaties/rapporten/cw/CW415.pdf >> >> > > Thank you all for you responses. I am integrating it all into a section > of my report, which I'll paste in a bit for you to pick holes in. I few > quick responses.... > > I agree with Igor and Camille, statically-typed & strongly-typed should > not be synonyms - but as Esteban says, it is common usage - but I think > that doesn't make it right. I think this is due to statically-typed > languages tightly associating types with variables, whereas types exist > independently from variables. > Milan, To clarify, it doesn't prevent the *error*. What it does is > prevent the *operation*. Since a MNU is produced the specified > operation did not execute. Igor gives a good example of why C is weakl > typed. > > Camille, I take your point about defining "Strongly Typed" , which I > will do in my report. > > Kilon, I agree with most of you writeup, except that I think Smalltalk > has types - except the types are not associated with variables, rather > they are associated with objects. This aligns with Igor's comment "in > smalltalk, assignment is not copying value, but changing the reference". > > Enrico, I will cover Duck Typing, thanks. The implication is, if Duck > Typing applies to Smalltalk, then types *are* part of Smalltalk. > Alain, Thanks for the link. To much to respond to here. Bits should end > up in my report. I found this compelling, as it clarify my own thinking > along the same lines "Statically typed languages assign types to > variables, while dynamically typed languages assign types to values" > > Hernan, I disagree that Smalltalk has no types. But they apply to > objects rather than variables, which is where it breaks down for the > explicitly/statically typed crowd. > > Carla, I am thinking along those lines. A type groups data and valid > operations. In non-OO languages, the data and operations are separated, > so the type is associated with a variable, which defines what operations > are valid on the variable, and hence on the data within the variable. In > OO/Smalltalk, the data and operations a combined, so type is associated > with the object, which defines what operations are valid on the object, > and hence the data within the object. > > Juan, I agree with your first post that Smalltalk is strongly typed. > Discussing of multi-typed is beyond what I need to consider for my report. > > German, That paper states "Smalltalk, although an untype language" but > the goes on to indicate many times that Smalltalk has types eg "subtype > polymorphism of Smalltalk" > I think it is common to say "Smalltalk is untyped" but actually the > correct statement should be "In Smalltalk, the *variables* are untyped" > > > I'll paste something in more detail soon. > > Thanks again. All good points to round out my discussion. > > cheers -ben > > > > >

Aug. 3, 2013

Discard option while editing code seems to be broken or strange

by StÃ©phane Ducasse

When I modify a method and click on somewhere else I get a pop up and pressing discard does not work but pops up another. Now I'm trying to reproduce the problem to describe it clearly and I cannot anymore but I'm sure I did get this strange behavior. Stef

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by kilon

btc wrote > btc@ > wrote: > > Kilon, I agree with most of you writeup, except that I think Smalltalk > has types - except the types are not associated with variables, rather > they are associated with objects. This aligns with Igor's comment "in > smalltalk, assignment is not copying value, but changing the reference". Actually I also mostly agree with Igor point. If I am not mistake we agree on the fact that smalltalk has no types. The only thing I would not agree, if my assumption is correct here, is that Igor appears here implying that smalltalk somehow is special to assign values by reference. If this assumption of mine is correct then I do disagree strongly , its actually a very common practice. Python also implement this, Lisp does, ruby and an array of dynamic type languages. I am not so sure about C and C++ but since they use pointers its a moot point anyway. I explain this concept in my book about python that I have published in blenderwiki , section "Reference" which can be found here -> http://wiki.blender.org/index.php/User:Kilon/Python_book_of_magic/05.Dictio… However this concept is implementation specific and not language specific. Its obviously a massive diffirence because a coder rarely worries about the implementation itself the same way a user of an OS does not worry how and why an OS does the things it does, he only care about what it does. Also I am not sure how that prove the existence of types, for me it does not, it only describes how values are assigned. What prevents you from assigning by reference typeless data ? Unless once again we talk about how pharo itself implement this and somehow uses its own internal type system. The question that remain why I the coder should care about this , if at language level Smalltalk is typeless. Maybe Igor can clarify this more to make a more clear picture what happens at implementation level. But at language level yes I have seen nothing that proves the existence of types inside Smalltalk unless we treat types in a very vague kind way which for me it just defeats their purpose. I also agree on the remark of Duck Typing , it definitely smells like smalltalk , but once again the terminology is failed because it implies a type system. Once more I have to stress the importance of dichotomy between language specification and language implementation. Types obviously touch both areas but not necessarily for same reasons. -- View this message in context: http://forum.world.st/Smalltalk-strongly-typed-tp4701894p4702028.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 3, 2013

SimpleMIDIPort midiIsSupported returns the first time false and after all the time true :)

by StÃ©phane Ducasse

Strange May be the logic in the primitive is strange. midiIsSupported "Answer true if this platform supports MIDI." ^ self primPortCount > 0 primPortCount "Answer the number of MIDI ports supported by this platform, or zero if this primitive is not implemented." <primitive: 'primitiveMIDIGetPortCount' module: 'MIDIPlugin'> ^ 0 Stef

Aug. 3, 2013

Re: [Pharo-dev] is the apply in the merge tool working?

by StÃ©phane Ducasse

I checked the code and it does not apply immediately the changes so it looks like it i redundant with keep current or keep incoming. Stef On Aug 3, 2013, at 7:09 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Because when I merge and I click on apply the change is not applied in the image (when I do not accept the button in the merge tool)? > > Stef

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by btc＠openinworld.com

btc(a)openinworld.com wrote: > greetings all, > > I'm in the final weeks of writing up my Masters dissertation and > seeking some scholarly references to Smalltalk being "Strongly Typed." > > I my review of Smalltalk I was surprised to find that [1] describes > Smalltalk as Strongly Typed, since Smalltalk is sometimes denigrated > as being untyped / weakly typed. From reviewing discussion forums this > now makes sense, but I can only find one of scholarly reference that > briefly mentions this [2]. The most enlightening is [3] which defines > Type Strength as: > > "A strongly typed language prevents any operation on the wrong type of > data. In weakly typed languages there are ways to escape this > restriction: type conversions" > > meaning that getting a MNU is a form of Strong Typing since you can't > make a Smalltalk object run a method that is not its own. The problem > appears to be that Strong Typing has been synonymous with Static > Typing for a long time, and Static Typing strongly ties types to > variables, except in Dynamically Typed languages, I think types can be > considered independently from variables, in which case the definition > of [3] has some merit, hence Smalltalk is Strongly Typed. > > Sounds controversial, so I'm just hoping for some peer reviewed backup > - but only you have something easily to hand. This is just a small > thing I can just leave out if necessary. > > cheers -ben > > [1] http://www.squeak.org/Features/ > [2] p15, > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.7507&rep=rep1&t… > > [3] http://www.cs.kuleuven.ac.be/publicaties/rapporten/cw/CW415.pdf > > Thank you all for you responses. I am integrating it all into a section of my report, which I'll paste in a bit for you to pick holes in. I few quick responses.... I agree with Igor and Camille, statically-typed & strongly-typed should not be synonyms - but as Esteban says, it is common usage - but I think that doesn't make it right. I think this is due to statically-typed languages tightly associating types with variables, whereas types exist independently from variables. Milan, To clarify, it doesn't prevent the *error*. What it does is prevent the *operation*. Since a MNU is produced the specified operation did not execute. Igor gives a good example of why C is weakl typed. Camille, I take your point about defining "Strongly Typed" , which I will do in my report. Kilon, I agree with most of you writeup, except that I think Smalltalk has types - except the types are not associated with variables, rather they are associated with objects. This aligns with Igor's comment "in smalltalk, assignment is not copying value, but changing the reference". Enrico, I will cover Duck Typing, thanks. The implication is, if Duck Typing applies to Smalltalk, then types *are* part of Smalltalk. Alain, Thanks for the link. To much to respond to here. Bits should end up in my report. I found this compelling, as it clarify my own thinking along the same lines "Statically typed languages assign types to variables, while dynamically typed languages assign types to values" Hernan, I disagree that Smalltalk has no types. But they apply to objects rather than variables, which is where it breaks down for the explicitly/statically typed crowd. Carla, I am thinking along those lines. A type groups data and valid operations. In non-OO languages, the data and operations are separated, so the type is associated with a variable, which defines what operations are valid on the variable, and hence on the data within the variable. In OO/Smalltalk, the data and operations a combined, so type is associated with the object, which defines what operations are valid on the object, and hence the data within the object. Juan, I agree with your first post that Smalltalk is strongly typed. Discussing of multi-typed is beyond what I need to consider for my report. German, That paper states "Smalltalk, although an untype language" but the goes on to indicate many times that Smalltalk has types eg "subtype polymorphism of Smalltalk" I think it is common to say "Smalltalk is untyped" but actually the correct statement should be "In Smalltalk, the *variables* are untyped" I'll paste something in more detail soon. Thanks again. All good points to round out my discussion. cheers -ben

Aug. 3, 2013

Still broken Date comparaison in 2.0?

by hilaire

Instances value from stacking GrowlMorphs: TimeStamp now -> 4 August 2013 1:18:30 am vanishTime -> 4 August 2013 12:51:51.62 am TimeStamp now < vanishTime ->true Inspectors: <http://forum.world.st/file/n4702023/TimesStampInspectors.png> Hilaire -- View this message in context: http://forum.world.st/Still-broken-Date-comparaison-in-2-0-tp4702023.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 3, 2013

is the apply in the merge tool working?

by StÃ©phane Ducasse

Because when I merge and I click on apply the change is not applied in the image (when I do not accept the button in the merge tool)? Stef

Aug. 3, 2013

cleaning AppRegistry and Sound/SoundService...

by StÃ©phane Ducasse

Hi guys I wonder what we can do about AppRegistry I imagine that we can remove MailSender. I'm going over the code on the image as well as http://code.google.com/p/pharo/issues/detail?id=6996 and pavel changes. Any feedback is welcome. Stef

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by GermÃ¡n Leiva

The term "strongly typed" is ambiguos and this thread is the living proof of that. In the introduction of http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf Luca Cardelli talks about untyped universes and later about Smalltalk. For me Smalltalk is a dynamically typed language with implicit type definitions and dynamic type checking. As Esteban said in the industry is really common to hear strongly typed = static type checking, in the academia the term it's used for more than one thing (http://en.m.wikipedia.org/wiki/Strong_and_weak_typing) so in order to avoid miscommunications I prefer the concepts "type declaration" (implicit vs explicit) and "type-checking" (dynamic, static or no type checking at all). Cheers, On Saturday, August 3, 2013, Juan Vuletich (mail lists) wrote: > BTW, I especially like the idea that Smalltalk is Multityped, as an object > can respond to several protocols/interfaces/type specs. So true! > > Quoting "Carla F. Griggio" <carla.griggio(a)gmail.com <javascript:_e({}, > 'cvml', 'carla.griggio(a)gmail.com');>>: > > Well, I've always defined a type as the a set of values and the operations > you can do with them. For example, the set of values { 1, 2, 3, 4, ... } > and the operations { + , - , * , ... } would be the type Integer. With that > in mind, *Smalltalk has types: a set of objects and the messages they > understand*. And thanks to polymorphism a type *is not* a synonym of a > class, as instances of different objects can understand messages in common. > So yes, "everything is an object" beacuse all objects are instances of a > class that inherits from Object, but from my point of view it's not true > that all objects are of one same type. > > Everytime an object doesn't understand a message is telling you that > you're doing an operation on the wrong type of object. > > As some others have already said, I don't like the terms "strongly typed" > or "weakly typed" because sometimes is ambiguous, and I rather say this: *Smalltalk > has dynamic type-checking in runtime* (instead of compilation time), > because it checks if an object can perform the operation you want (the > message) in the moment of executing that operation (when you send the > message). > > Now, talking not-so-siriously, and maybe I'm getting a little > code-philosofical here... If we take into account what I've just defined as > a type, and knowing that all objects are instances of a class that inherits > from Object, I think the term "unityped" should actually be replaced for > "multityped", as the same object could respond to many different types > depending on the interface its client wants it to understand. But that > happens maybe in any object-oriented program, the thing is that in > Smalltalk it's very natural and you don't even have to think about it (in > Java you would have to explicitly use 'interfaces'). > > > > > > On Sat, Aug 3, 2013 at 4:02 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com <javascript:_e({}, 'cvml', > 'hernan.morales(a)gmail.com');>> wrote: > >> That is correct, there are no types in Smalltalk. >> Cheers, >> >> HernÃ¡n >> >> El 02/08/2013 15:55, Igor Stasenko escribiÃ³: >> >> I wonder if 'types' can be applied to smalltalk at all. >>> Saying it is 'unityped' language (since everything is an object) is >>> same as saying it has no types. >>> >>> Because where you need types? When you want to manipulate with data, >>> but in smalltalk all >>> data manipulation semantics is provided and implemented at primitive >>> level, but not by the language itself. >>> At language level the only semantics which is defined is message >>> passing, closures, >>> return and assignment. >>> >>> There is no any rule(s), in smalltalk at language level, saying that >>> result of expression: >>> >>> 1 + 2 >>> >>> should be of integer type. Because this is provided by implementation >>> but not defined by language itself e.g.: >>> it is just a method in corresponding class, which implemented in such >>> a way that result of expression will be instance of Integer (or >>> SmallInteger to be precise). >>> Now, if you change implementation so result will be float (or anything >>> else), will such change allow you to say, that it is no longer >>> smalltalk, or that now it is weakly typed or "anything-else typed"? >>> >>> Because smalltalk code do not operates directly with data, but only >>> with references to it (which is objects). >>> >>> Take an assignment, for example. >>> In staticly-typed language assignment copies the value of expression >>> to variable, e.g.: >>> >>> a = 10 >>> >>> "now variable a has value = 10" >>> >>> in smalltalk, assignment is not copying value, but changing the >>> reference: >>> >>> a := 10 >>> >>> "now variable a points (or refers) to object '10'" >>> >>> and thus, whatever 'type' used to represent the integer value 10 is >>> completely irrelevant >>> for assignment operation. >>> >>> >> >> > Cheers, > Juan Vuletich > -- GermÃ¡n Leiva LeivaGerman(a)gmail.com

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Juan Vuletich (mail lists)

BTW, I especially like the idea that Smalltalk is Multityped, as an object can respond to several protocols/interfaces/type specs. So true! Quoting "Carla F. Griggio" <carla.griggio(a)gmail.com>: > Well, I've always defined a type as the a set of values and the operations you can do with them. For example, the set of values { 1, 2, 3, 4, ... } and the operations { + , - , * , ... } would be the type Integer. With that in mind, SMALLTALK HAS TYPES: A SET OF OBJECTS AND THE MESSAGES THEY UNDERSTAND. And thanks to polymorphism a type _is not_ a synonym of a class, as instances of different objects can understand messages in common. So yes, "everything is an object" beacuse all objects are instances of a class that inherits from Object, but from my point of view it's not true that all objects are of one same type. > > Everytime an object doesn't understand a message is telling you that you're doing an operation on the wrong type of object. > > > As some others have already said, I don't like the terms "strongly typed" or "weakly typed" because sometimes is ambiguous, and I rather say this: SMALLTALK HAS DYNAMIC TYPE-CHECKING IN RUNTIME (instead of compilation time), because it checks if an object can perform the operation you want (the message) in the moment of executing that operation (when you send the message). > > > Now, talking not-so-siriously, and maybe I'm getting a little code-philosofical here... If we take into account what I've just defined as a type, and knowing that all objects are instances of a class that inherits from Object, I think the term "unityped" should actually be replaced for "multityped", as the same object could respond to many different types depending on the interface its client wants it to understand. But that happens maybe in any object-oriented program, the thing is that in Smalltalk it's very natural and you don't even have to think about it (in Java you would have to explicitly use 'interfaces'). > > On Sat, Aug 3, 2013 at 4:02 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > > > That is correct, there are no types in Smalltalk. > > Cheers, > > > > HernÃ¡n > > > > El 02/08/2013 15:55, Igor Stasenko escribiÃ³: > > > > > I wonder if 'types' can be applied to smalltalk at all. > > > Saying it is 'unityped' language (since everything is an object) is > > > same as saying it has no types. > > > > > > Because where you need types? When you want to manipulate with data, > > > but in smalltalk all > > > data manipulation semantics is provided and implemented at primitive > > > level, but not by the language itself. > > > At language level the only semantics which is defined is message > > > passing, closures, > > > return and assignment. > > > > > > There is no any rule(s), in smalltalk at language level, saying that > > > result of expression: > > > > > > 1 + 2 > > > > > > should be of integer type. Because this is provided by implementation > > > but not defined by language itself e.g.: > > > it is just a method in corresponding class, which implemented in such > > > a way that result of expression will be instance of Integer (or > > > SmallInteger to be precise). > > > Now, if you change implementation so result will be float (or anything > > > else), will such change allow you to say, that it is no longer > > > smalltalk, or that now it is weakly typed or "anything-else typed"? > > > > > > Because smalltalk code do not operates directly with data, but only > > > with references to it (which is objects). > > > > > > Take an assignment, for example. > > > In staticly-typed language assignment copies the value of expression > > > to variable, e.g.: > > > > > > a = 10 > > > > > > "now variable a has value = 10" > > > > > > in smalltalk, assignment is not copying value, but changing the reference: > > > > > > a := 10 > > > > > > "now variable a points (or refers) to object '10'" > > > > > > and thus, whatever 'type' used to represent the integer value 10 is > > > completely irrelevant > > > for assignment operation. Cheers, Juan Vuletich

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Juan Vuletich (mail lists)

I fully agree with you. Just a detail. "strongly typed" or "weakly typed" is not ambiguous. Weakly typed means that the system can not guarantee that the types are known and behavior is consistent with them. The main example is C, where a pointer can point to anything, and often there is no type checking. Smalltalk is as strongly typed as Pascal: the type system is always as advertised. Quoting "Carla F. Griggio" <carla.griggio(a)gmail.com>: > Well, I've always defined a type as the a set of values and the operations you can do with them. For example, the set of values { 1, 2, 3, 4, ... } and the operations { + , - , * , ... } would be the type Integer. With that in mind, SMALLTALK HAS TYPES: A SET OF OBJECTS AND THE MESSAGES THEY UNDERSTAND. And thanks to polymorphism a type _is not_ a synonym of a class, as instances of different objects can understand messages in common. So yes, "everything is an object" beacuse all objects are instances of a class that inherits from Object, but from my point of view it's not true that all objects are of one same type. > > Everytime an object doesn't understand a message is telling you that you're doing an operation on the wrong type of object. > > > As some others have already said, I don't like the terms "strongly typed" or "weakly typed" because sometimes is ambiguous, and I rather say this: SMALLTALK HAS DYNAMIC TYPE-CHECKING IN RUNTIME (instead of compilation time), because it checks if an object can perform the operation you want (the message) in the moment of executing that operation (when you send the message). > > > Now, talking not-so-siriously, and maybe I'm getting a little code-philosofical here... If we take into account what I've just defined as a type, and knowing that all objects are instances of a class that inherits from Object, I think the term "unityped" should actually be replaced for "multityped", as the same object could respond to many different types depending on the interface its client wants it to understand. But that happens maybe in any object-oriented program, the thing is that in Smalltalk it's very natural and you don't even have to think about it (in Java you would have to explicitly use 'interfaces'). > > On Sat, Aug 3, 2013 at 4:02 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > > > That is correct, there are no types in Smalltalk. > > Cheers, > > > > HernÃ¡n > > > > El 02/08/2013 15:55, Igor Stasenko escribiÃ³: > > > > > I wonder if 'types' can be applied to smalltalk at all. > > > Saying it is 'unityped' language (since everything is an object) is > > > same as saying it has no types. > > > > > > Because where you need types? When you want to manipulate with data, > > > but in smalltalk all > > > data manipulation semantics is provided and implemented at primitive > > > level, but not by the language itself. > > > At language level the only semantics which is defined is message > > > passing, closures, > > > return and assignment. > > > > > > There is no any rule(s), in smalltalk at language level, saying that > > > result of expression: > > > > > > 1 + 2 > > > > > > should be of integer type. Because this is provided by implementation > > > but not defined by language itself e.g.: > > > it is just a method in corresponding class, which implemented in such > > > a way that result of expression will be instance of Integer (or > > > SmallInteger to be precise). > > > Now, if you change implementation so result will be float (or anything > > > else), will such change allow you to say, that it is no longer > > > smalltalk, or that now it is weakly typed or "anything-else typed"? > > > > > > Because smalltalk code do not operates directly with data, but only > > > with references to it (which is objects). > > > > > > Take an assignment, for example. > > > In staticly-typed language assignment copies the value of expression > > > to variable, e.g.: > > > > > > a = 10 > > > > > > "now variable a has value = 10" > > > > > > in smalltalk, assignment is not copying value, but changing the reference: > > > > > > a := 10 > > > > > > "now variable a points (or refers) to object '10'" > > > > > > and thus, whatever 'type' used to represent the integer value 10 is > > > completely irrelevant > > > for assignment operation. Cheers, Juan Vuletich

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by kilon

" Smalltalk has types: a set of objects and the messages they understand" Nope thats not what a type is. A type is a category of data. Its that simple. Your set of objects and the messages they understand can do thousands of things. Emulating types is one of those things. Also what happens in implementation is not related to language. Implementation is one thing language is another. Also even if you see it philosophical still is very clear. Types in the end is a set of restrictions which tells "I am the language and I wont allow you to shoot yourself on the foot. I know better." Smalltalk on the other hand begs you "Hack me dude, hack me!". Smalltalk does not enforce such restrictions. But then it does not prevent you from implementing such restrictions. Afterall a static typed language does not prevents from implementing dynamic types. If it did it would be impossible to use C to create python or smalltalk. With any language there are a billion ways to skin a cat. What it differs is the things they offer out of the box .Nothing is set in stone. Carla F. Griggio wrote > Well, I've always defined a type as the a set of values and the operations > you can do with them. For example, the set of values { 1, 2, 3, 4, ... } > and the operations { + , - , * , ... } would be the type Integer. With > that > in mind, *Smalltalk has types: a set of objects and the messages they > understand*. And thanks to polymorphism a type *is not* a synonym of a > class, as instances of different objects can understand messages in > common. > So yes, "everything is an object" beacuse all objects are instances of a > class that inherits from Object, but from my point of view it's not true > that all objects are of one same type. > > Everytime an object doesn't understand a message is telling you that > you're > doing an operation on the wrong type of object. > > As some others have already said, I don't like the terms "strongly typed" > or "weakly typed" because sometimes is ambiguous, and I rather say > this: *Smalltalk > has dynamic type-checking in runtime* (instead of compilation time), > because it checks if an object can perform the operation you want (the > message) in the moment of executing that operation (when you send the > message). > > Now, talking not-so-siriously, and maybe I'm getting a little > code-philosofical here... If we take into account what I've just defined > as > a type, and knowing that all objects are instances of a class that > inherits > from Object, I think the term "unityped" should actually be replaced for > "multityped", as the same object could respond to many different types > depending on the interface its client wants it to understand. But that > happens maybe in any object-oriented program, the thing is that in > Smalltalk it's very natural and you don't even have to think about it (in > Java you would have to explicitly use 'interfaces'). > > > > > > On Sat, Aug 3, 2013 at 4:02 AM, HernÃ¡n Morales Durand < > hernan.morales@ >> wrote: > >> That is correct, there are no types in Smalltalk. >> Cheers, >> >> HernÃ¡n >> >> El 02/08/2013 15:55, Igor Stasenko escribiÃ³: >> >> I wonder if 'types' can be applied to smalltalk at all. >>> Saying it is 'unityped' language (since everything is an object) is >>> same as saying it has no types. >>> >>> Because where you need types? When you want to manipulate with data, >>> but in smalltalk all >>> data manipulation semantics is provided and implemented at primitive >>> level, but not by the language itself. >>> At language level the only semantics which is defined is message >>> passing, closures, >>> return and assignment. >>> >>> There is no any rule(s), in smalltalk at language level, saying that >>> result of expression: >>> >>> 1 + 2 >>> >>> should be of integer type. Because this is provided by implementation >>> but not defined by language itself e.g.: >>> it is just a method in corresponding class, which implemented in such >>> a way that result of expression will be instance of Integer (or >>> SmallInteger to be precise). >>> Now, if you change implementation so result will be float (or anything >>> else), will such change allow you to say, that it is no longer >>> smalltalk, or that now it is weakly typed or "anything-else typed"? >>> >>> Because smalltalk code do not operates directly with data, but only >>> with references to it (which is objects). >>> >>> Take an assignment, for example. >>> In staticly-typed language assignment copies the value of expression >>> to variable, e.g.: >>> >>> a = 10 >>> >>> "now variable a has value = 10" >>> >>> in smalltalk, assignment is not copying value, but changing the >>> reference: >>> >>> a := 10 >>> >>> "now variable a points (or refers) to object '10'" >>> >>> and thus, whatever 'type' used to represent the integer value 10 is >>> completely irrelevant >>> for assignment operation. >>> >>> >> >> -- View this message in context: http://forum.world.st/Smalltalk-strongly-typed-tp4701894p4702012.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 3, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by StÃ©phane Ducasse

On Aug 3, 2013, at 2:13 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Marcus, > > On Thu, Aug 1, 2013 at 12:33 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Aug 1, 2013, at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> since years marcus is telling that MC storing ancestor information is doomed but we do not have something to really replace it. >>> >> >> This is yet another thing. >> >> Monticello keep all history data of all package in image, this is not a cache. When you delete it, your package loses >> it's history and you can not merge anymore. >> >> MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. > > When I looked at this I noticed that there was lots of duplicate > entries in the ancestry list. I *think* this happens on merge. I > think one ends up with each of the ancestries of the merged packages > after a merge, i.e. when merging near the head one effectively doubles > the ancestry. I think Monticello should unique the ancestry, either > after a merge, or better still, before saving. This I think will > shrink the space taken by ancestry significantly. > > I have some code handy if you'd like, but its not a hard thing to do. Can you send it so that we have a look? Tx > >> >> We did that on Pharo2 release and it saved 8MB (nearly a third of the image). >> >> Marcus > > > > -- > best, > Eliot >

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Carla F. Griggio

Well, I've always defined a type as the a set of values and the operations you can do with them. For example, the set of values { 1, 2, 3, 4, ... } and the operations { + , - , * , ... } would be the type Integer. With that in mind, *Smalltalk has types: a set of objects and the messages they understand*. And thanks to polymorphism a type *is not* a synonym of a class, as instances of different objects can understand messages in common. So yes, "everything is an object" beacuse all objects are instances of a class that inherits from Object, but from my point of view it's not true that all objects are of one same type. Everytime an object doesn't understand a message is telling you that you're doing an operation on the wrong type of object. As some others have already said, I don't like the terms "strongly typed" or "weakly typed" because sometimes is ambiguous, and I rather say this: *Smalltalk has dynamic type-checking in runtime* (instead of compilation time), because it checks if an object can perform the operation you want (the message) in the moment of executing that operation (when you send the message). Now, talking not-so-siriously, and maybe I'm getting a little code-philosofical here... If we take into account what I've just defined as a type, and knowing that all objects are instances of a class that inherits from Object, I think the term "unityped" should actually be replaced for "multityped", as the same object could respond to many different types depending on the interface its client wants it to understand. But that happens maybe in any object-oriented program, the thing is that in Smalltalk it's very natural and you don't even have to think about it (in Java you would have to explicitly use 'interfaces'). On Sat, Aug 3, 2013 at 4:02 AM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > That is correct, there are no types in Smalltalk. > Cheers, > > HernÃ¡n > > El 02/08/2013 15:55, Igor Stasenko escribiÃ³: > > I wonder if 'types' can be applied to smalltalk at all. >> Saying it is 'unityped' language (since everything is an object) is >> same as saying it has no types. >> >> Because where you need types? When you want to manipulate with data, >> but in smalltalk all >> data manipulation semantics is provided and implemented at primitive >> level, but not by the language itself. >> At language level the only semantics which is defined is message >> passing, closures, >> return and assignment. >> >> There is no any rule(s), in smalltalk at language level, saying that >> result of expression: >> >> 1 + 2 >> >> should be of integer type. Because this is provided by implementation >> but not defined by language itself e.g.: >> it is just a method in corresponding class, which implemented in such >> a way that result of expression will be instance of Integer (or >> SmallInteger to be precise). >> Now, if you change implementation so result will be float (or anything >> else), will such change allow you to say, that it is no longer >> smalltalk, or that now it is weakly typed or "anything-else typed"? >> >> Because smalltalk code do not operates directly with data, but only >> with references to it (which is objects). >> >> Take an assignment, for example. >> In staticly-typed language assignment copies the value of expression >> to variable, e.g.: >> >> a = 10 >> >> "now variable a has value = 10" >> >> in smalltalk, assignment is not copying value, but changing the reference: >> >> a := 10 >> >> "now variable a points (or refers) to object '10'" >> >> and thus, whatever 'type' used to represent the integer value 10 is >> completely irrelevant >> for assignment operation. >> >> > >

Aug. 3, 2013

Re: [Pharo-dev] [Vm-dev] modified method temp references in closures: possible bug?

by StÃ©phane Ducasse

In fact we say that closure capture variables but they capture "location" or access to variables. I will reread what I wrote I gave some examples in the forth coming book Deep into Pharo :) http://rmod.lille.inria.fr/pbe2/ On Aug 2, 2013, at 3:35 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 2 August 2013 15:27, Max Leske <maxleske(a)gmail.com> wrote: >> >> Sorry, yes, "dict" should be "collection". >> >> >> On 02.08.2013, at 15:16, ClÃ©ment BÃ©ra <bera.clement(a)gmail.com> wrote: >> >> This is not a bug. >> > > yes, the expression: > > [ methodScope ] > > does not capturing the current value of methodScope variable. > > means that closure, when evaluated will always return the value > methodScope at the moment of evaluation. > > Closures do not capturing values of free variables, because then it > will mean different semantic than rest of code (in method's body). > > >> Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope. >> >> >> Yes, I understand that. I just wanted to make sure that's the intended functionality. The reason I ask is that the error isn't easy to spot and there's no cue that one might be doing something wrong (It's not my code by the way :P). Especially for newcomers this can be a tricky one. >> >> I totally agree with you that the variables belong to the block and should be declared there. >> >> >> Your code is the same as if you wrote : >> | methodScope | >> methodScope := 1. >> methodScope := 2. >> At the end, methodScope is of course 2. >> >> If you want the result : >> 1 >> 2 >> you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block. >> >> collection := OrderedCollection new. >> 1 to: 2 do: [ :index | >> | methodScope | >> methodScope := index. >> dict add: [ methodScope ] ]. >> collection do: [ :block | Transcript show: block value; cr ] >> >> >> 2013/8/2 Max Leske <maxleske(a)gmail.com> >>> >>> >>> I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): >>> >>> expected (by my feeble mind): >>> 1 >>> 2 >>> >>> actual: >>> 2 >>> 2 >>> >>> | methodScope | >>> collection := OrderedCollection new. >>> 1 to: 2 do: [ :index | >>> methodScope := index. >>> dict add: [ methodScope ] ]. >>> >>> collection do: [ :block | Transcript show: block value; cr ] >>> >>> I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors. >>> >>> Should I open a bug report? >>> >>> Cheers, >>> Max >> >> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by HernÃ¡n Morales Durand

That is correct, there are no types in Smalltalk. Cheers, HernÃ¡n El 02/08/2013 15:55, Igor Stasenko escribiÃ³: > I wonder if 'types' can be applied to smalltalk at all. > Saying it is 'unityped' language (since everything is an object) is > same as saying it has no types. > > Because where you need types? When you want to manipulate with data, > but in smalltalk all > data manipulation semantics is provided and implemented at primitive > level, but not by the language itself. > At language level the only semantics which is defined is message > passing, closures, > return and assignment. > > There is no any rule(s), in smalltalk at language level, saying that > result of expression: > > 1 + 2 > > should be of integer type. Because this is provided by implementation > but not defined by language itself e.g.: > it is just a method in corresponding class, which implemented in such > a way that result of expression will be instance of Integer (or > SmallInteger to be precise). > Now, if you change implementation so result will be float (or anything > else), will such change allow you to say, that it is no longer > smalltalk, or that now it is weakly typed or "anything-else typed"? > > Because smalltalk code do not operates directly with data, but only > with references to it (which is objects). > > Take an assignment, for example. > In staticly-typed language assignment copies the value of expression > to variable, e.g.: > > a = 10 > > "now variable a has value = 10" > > in smalltalk, assignment is not copying value, but changing the reference: > > a := 10 > > "now variable a points (or refers) to object '10'" > > and thus, whatever 'type' used to represent the integer value 10 is > completely irrelevant > for assignment operation. >

Aug. 3, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Eliot Miranda

Hi Marcus, On Thu, Aug 1, 2013 at 12:33 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 1, 2013, at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> since years marcus is telling that MC storing ancestor information is doomed but we do not have something to really replace it. >> > > This is yet another thing. > > Monticello keep all history data of all package in image, this is not a cache. When you delete it, your package loses > it's history and you can not merge anymore. > > MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. When I looked at this I noticed that there was lots of duplicate entries in the ancestry list. I *think* this happens on merge. I think one ends up with each of the ancestries of the merged packages after a merge, i.e. when merging near the head one effectively doubles the ancestry. I think Monticello should unique the ancestry, either after a merge, or better still, before saving. This I think will shrink the space taken by ancestry significantly. I have some code handy if you'd like, but its not a hard thing to do. > > We did that on Pharo2 release and it saved 8MB (nearly a third of the image). > > Marcus -- best, Eliot

Aug. 3, 2013

flash: does not work in Pharo 3.0

by StÃ©phane Ducasse

Display flash: (0@0 corner: 200@200) does not work on Pharo 30 while it was working on 2.0. It looks that this is VM related because on the linux of laurent it is working. I'm too tired to get how to extract the VM versionâ¦. I tried --version and others but it did not work. pharo -version bin unknown option: -version Usage: [<option>...] [<imageName> [<argument>...]] [<option>...] -- [<argument>...] Common <option>s: -help print this help message, then exit -memory <size>[mk] use fixed heap size (added to image size) -headless run in headless (no window) mode (default: false) Notes: <imageName> defaults to `Squeak.image'. If `-memory' is not specified then the heap will grow dynamically. <argument>s are ignored, but are processed by the Squeak image. The first <argument> normally names a Squeak `script' to execute. Precede <arguments> by `--' to use default image. bin pharo -version 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 ' Stef too tired and exhausted to think

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Alain Plantec

Hi Ben, Thanks for the references, I've also found this post interesting: http://blogs.perl.org/users/ovid/2010/08/what-to-know-before-debating-type-… Cheers Alain On 2 aoÃ»t 2013, at 06:03, btc(a)openinworld.com wrote: > greetings all, > > I'm in the final weeks of writing up my Masters dissertation and seeking some scholarly references to Smalltalk being "Strongly Typed." > > I my review of Smalltalk I was surprised to find that [1] describes Smalltalk as Strongly Typed, since Smalltalk is sometimes denigrated as being untyped / weakly typed. From reviewing discussion forums this now makes sense, but I can only find one of scholarly reference that briefly mentions this [2]. The most enlightening is [3] which defines Type Strength as: > > "A strongly typed language prevents any operation on the wrong type of data. In weakly typed languages there are ways to escape this restriction: type conversions" > > meaning that getting a MNU is a form of Strong Typing since you can't make a Smalltalk object run a method that is not its own. The problem appears to be that Strong Typing has been synonymous with Static Typing for a long time, and Static Typing strongly ties types to variables, except in Dynamically Typed languages, I think types can be considered independently from variables, in which case the definition of [3] has some merit, hence Smalltalk is Strongly Typed. > > Sounds controversial, so I'm just hoping for some peer reviewed backup - but only you have something easily to hand. This is just a small thing I can just leave out if necessary. > > cheers -ben > > [1] http://www.squeak.org/Features/ > [2] p15, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.7507&rep=rep1&t… > [3] http://www.cs.kuleuven.ac.be/publicaties/rapporten/cw/CW415.pdf >

Aug. 2, 2013

drawReverseFrame: is strange because it does not use self

by StÃ©phane Ducasse

Rectangle>>drawReverseFrame: rect Display border: rect width: 2 rule: Form reverse fillColor: Color gray and force user to create a dummy rectangle to invoke it. Stef

Aug. 2, 2013

Why we should run SmallLint

by StÃ©phane Ducasse

convertFromCompoundText | readStream converter | readStream := self readStream. ^ self class new: self size streamContents: [ :writeStream| converter := CompoundTextConverter new. converter ifNil: [^ self]. [readStream atEnd] whileFalse: [ writeStream nextPut: (converter nextFromStream: readStream)]]. CompoundTextConverter new -> DNU convertFromSystemString | readStream converter | readStream := self readStream. ^ self class new: self size streamContents: [ :writeStream| converter := LanguageEnvironment defaultSystemConverter. converter ifNil: [^ self]. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [readStream atEnd] whileFalse: [ writeStream nextPut: (converter nextFromStream: readStream)]]. systemConverterClass self subclassResponsibility. ^ Latin1TextConverter. What!!!! Stef

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Enrico Schwass

Hello If people ask me about Smalltalk I soon refer to the term duck typing. It perfectly fits. Enno On 02.08.2013, at 20:55, Igor Stasenko <siguctua(a)gmail.com> wrote: > I wonder if 'types' can be applied to smalltalk at all. > Saying it is 'unityped' language (since everything is an object) is > same as saying it has no types. > > Because where you need types? When you want to manipulate with data, > but in smalltalk all > data manipulation semantics is provided and implemented at primitive > level, but not by the language itself. > At language level the only semantics which is defined is message > passing, closures, > return and assignment. > > There is no any rule(s), in smalltalk at language level, saying that > result of expression: > > 1 + 2 > > should be of integer type. Because this is provided by implementation > but not defined by language itself e.g.: > it is just a method in corresponding class, which implemented in such > a way that result of expression will be instance of Integer (or > SmallInteger to be precise). > Now, if you change implementation so result will be float (or anything > else), will such change allow you to say, that it is no longer > smalltalk, or that now it is weakly typed or "anything-else typed"? > > Because smalltalk code do not operates directly with data, but only > with references to it (which is objects). > > Take an assignment, for example. > In staticly-typed language assignment copies the value of expression > to variable, e.g.: > > a = 10 > > "now variable a has value = 10" > > in smalltalk, assignment is not copying value, but changing the reference: > > a := 10 > > "now variable a points (or refers) to object '10'" > > and thus, whatever 'type' used to represent the integer value 10 is > completely irrelevant > for assignment operation. > > -- > Best regards, > Igor Stasenko. >

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Igor Stasenko

I wonder if 'types' can be applied to smalltalk at all. Saying it is 'unityped' language (since everything is an object) is same as saying it has no types. Because where you need types? When you want to manipulate with data, but in smalltalk all data manipulation semantics is provided and implemented at primitive level, but not by the language itself. At language level the only semantics which is defined is message passing, closures, return and assignment. There is no any rule(s), in smalltalk at language level, saying that result of expression: 1 + 2 should be of integer type. Because this is provided by implementation but not defined by language itself e.g.: it is just a method in corresponding class, which implemented in such a way that result of expression will be instance of Integer (or SmallInteger to be precise). Now, if you change implementation so result will be float (or anything else), will such change allow you to say, that it is no longer smalltalk, or that now it is weakly typed or "anything-else typed"? Because smalltalk code do not operates directly with data, but only with references to it (which is objects). Take an assignment, for example. In staticly-typed language assignment copies the value of expression to variable, e.g.: a = 10 "now variable a has value = 10" in smalltalk, assignment is not copying value, but changing the reference: a := 10 "now variable a points (or refers) to object '10'" and thus, whatever 'type' used to represent the integer value 10 is completely irrelevant for assignment operation. -- Best regards, Igor Stasenko.

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by kilon

I dont see the reason for the confusion. Static typed language is a language that defines the type of the variable at the creating of the variable. Strongly typed language is a language that wont automatically convert the type of a variable if the correct type is not used. Dynamic typed language use types but variable can change types depending on the type of data it receives. Weakly typed language will convert the type automatically if the wrong type is used. There is nothing stopping a static type language being weakly typed. Actually javascript is such an example. I have no idea how one could mix up static typing with strong typing , they look similar as word but they semantics if you exclude the fact that both talk about types are vastly different. In case of smalltalk none of the above is valid because smalltalk does not use types but rather objects. At best you could say it uses objects that emulate types, but since the object itself is typeless I dont think it makes a difference. Because of this its possible to emulate all these characteristic at the same time since the nature of smalltalk is to be very flexible. Probably lisp is very similar too. Afterall what forcing an object to complain about its type or do not allow to convert data at passing , or allow it / implement it ? You can do pretty much anything with message sending. Super powerful stuff. -- View this message in context: http://forum.world.st/Smalltalk-strongly-typed-tp4701894p4701965.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 2, 2013

Re: [Pharo-dev] 3.0 rolled back to 30321

by StÃ©phane Ducasse

thanks! Stef On Aug 2, 2013, at 4:14 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I needed to rollback to previous integration because there are some problems related to last integration (and Ben is in vacations and cannot deliver a "hot-fix" :) > > Esteban

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Camille Teruel

On 2 aoÃ»t 2013, at 15:47, Esteban Lorenzano wrote: > > On Aug 2, 2013, at 3:39 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> Just a citation: >> >> âI spent a few weeks ... trying to sort out the terminology of âstrongly typedâ, >> âstatically typedâ, âsafeâ, etc., and found it amazingly difï¬cult ... The usage of these >> terms is so various as to render them almost useless.â >> -- Benjamin C. Pierce >> >> If you use one of these terms, you should give a definition. >> And if you hear one, you shouldn't assume the author means what you think. >> For example some people could argue that Smalltalk is untyped (or unityped [1]), while you argued that it is strongly typed since there is no implicit type conversion. >> For most people, the static/dynamic and the weak/strong distinctions are supposed to be orthogonal. >> So, for most people, strong typing is not a synonymous of static typing. > > I have to say that IMHO, you are wrong in this one. For researchers, maybe. But I have seen in "industry word" that the terms are often exchangeable and for most people I have known, strong=static :( It depends on the people one knows then ;) All that shows that these terms are unclear for everyone and must be defined when used. > >> >> [1] http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-stati… >> >> >> On 2 aoÃ»t 2013, at 06:03, btc(a)openInWorld.com wrote: >> >>> greetings all, >>> >>> I'm in the final weeks of writing up my Masters dissertation and seeking some scholarly references to Smalltalk being "Strongly Typed." >>> >>> I my review of Smalltalk I was surprised to find that [1] describes Smalltalk as Strongly Typed, since Smalltalk is sometimes denigrated as being untyped / weakly typed. From reviewing discussion forums this now makes sense, but I can only find one of scholarly reference that briefly mentions this [2]. The most enlightening is [3] which defines Type Strength as: >>> >>> "A strongly typed language prevents any operation on the wrong type of data. In weakly typed languages there are ways to escape this restriction: type conversions" >>> >>> meaning that getting a MNU is a form of Strong Typing since you can't make a Smalltalk object run a method that is not its own. The problem appears to be that Strong Typing has been synonymous with Static Typing for a long time, and Static Typing strongly ties types to variables, except in Dynamically Typed languages, I think types can be considered independently from variables, in which case the definition of [3] has some merit, hence Smalltalk is Strongly Typed. >>> >>> Sounds controversial, so I'm just hoping for some peer reviewed backup - but only you have something easily to hand. This is just a small thing I can just leave out if necessary. >>> >>> cheers -ben >>> >>> [1] http://www.squeak.org/Features/ >>> [2] p15, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.7507&rep=rep1&t… >>> [3] http://www.cs.kuleuven.ac.be/publicaties/rapporten/cw/CW415.pdf >>> >> >

Aug. 2, 2013

3.0 rolled back to 30321

by Esteban Lorenzano

Hi, I needed to rollback to previous integration because there are some problems related to last integration (and Ben is in vacations and cannot deliver a "hot-fix" :) Esteban

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Esteban Lorenzano

On Aug 2, 2013, at 3:39 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > Just a citation: > > âI spent a few weeks ... trying to sort out the terminology of âstrongly typedâ, > âstatically typedâ, âsafeâ, etc., and found it amazingly difï¬cult ... The usage of these > terms is so various as to render them almost useless.â > -- Benjamin C. Pierce > > If you use one of these terms, you should give a definition. > And if you hear one, you shouldn't assume the author means what you think. > For example some people could argue that Smalltalk is untyped (or unityped [1]), while you argued that it is strongly typed since there is no implicit type conversion. > For most people, the static/dynamic and the weak/strong distinctions are supposed to be orthogonal. > So, for most people, strong typing is not a synonymous of static typing. I have to say that IMHO, you are wrong in this one. For researchers, maybe. But I have seen in "industry word" that the terms are often exchangeable and for most people I have known, strong=static :( > > [1] http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-stati… > > > On 2 aoÃ»t 2013, at 06:03, btc(a)openInWorld.com wrote: > >> greetings all, >> >> I'm in the final weeks of writing up my Masters dissertation and seeking some scholarly references to Smalltalk being "Strongly Typed." >> >> I my review of Smalltalk I was surprised to find that [1] describes Smalltalk as Strongly Typed, since Smalltalk is sometimes denigrated as being untyped / weakly typed. From reviewing discussion forums this now makes sense, but I can only find one of scholarly reference that briefly mentions this [2]. The most enlightening is [3] which defines Type Strength as: >> >> "A strongly typed language prevents any operation on the wrong type of data. In weakly typed languages there are ways to escape this restriction: type conversions" >> >> meaning that getting a MNU is a form of Strong Typing since you can't make a Smalltalk object run a method that is not its own. The problem appears to be that Strong Typing has been synonymous with Static Typing for a long time, and Static Typing strongly ties types to variables, except in Dynamically Typed languages, I think types can be considered independently from variables, in which case the definition of [3] has some merit, hence Smalltalk is Strongly Typed. >> >> Sounds controversial, so I'm just hoping for some peer reviewed backup - but only you have something easily to hand. This is just a small thing I can just leave out if necessary. >> >> cheers -ben >> >> [1] http://www.squeak.org/Features/ >> [2] p15, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.7507&rep=rep1&t… >> [3] http://www.cs.kuleuven.ac.be/publicaties/rapporten/cw/CW415.pdf >> >

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Igor Stasenko

On 2 August 2013 15:27, Milan Mimica <milan.mimica(a)gmail.com> wrote: > On 2 August 2013 06:03, <btc(a)openinworld.com> wrote: >> >> >> "A strongly typed language prevents any operation on the wrong type of >> data. In weakly typed languages there are ways to escape this restriction: >> type conversions" >> >> meaning that getting a MNU is a form of Strong Typing since you can't make >> a Smalltalk object run a method that is not its own. > > > How is that preventing? > by implementation? Otherwise if it not preventing, then it will be 'weak typed'. > > -- > Milan Mimica > http://sparklet.sf.net -- Best regards, Igor Stasenko.

Aug. 2, 2013

Re: [Pharo-dev] [Vm-dev] modified method temp references in closures: possible bug?

by Max Leske

On 02.08.2013, at 15:35, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 2 August 2013 15:27, Max Leske <maxleske(a)gmail.com> wrote: >> >> Sorry, yes, "dict" should be "collection". >> >> >> On 02.08.2013, at 15:16, ClÃ©ment BÃ©ra <bera.clement(a)gmail.com> wrote: >> >> This is not a bug. >> > > yes, the expression: > > [ methodScope ] > > does not capturing the current value of methodScope variable. > > means that closure, when evaluated will always return the value > methodScope at the moment of evaluation. > > Closures do not capturing values of free variables, because then it > will mean different semantic than rest of code (in method's body). Ok, thanks. > > >> Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope. >> >> >> Yes, I understand that. I just wanted to make sure that's the intended functionality. The reason I ask is that the error isn't easy to spot and there's no cue that one might be doing something wrong (It's not my code by the way :P). Especially for newcomers this can be a tricky one. >> >> I totally agree with you that the variables belong to the block and should be declared there. >> >> >> Your code is the same as if you wrote : >> | methodScope | >> methodScope := 1. >> methodScope := 2. >> At the end, methodScope is of course 2. >> >> If you want the result : >> 1 >> 2 >> you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block. >> >> collection := OrderedCollection new. >> 1 to: 2 do: [ :index | >> | methodScope | >> methodScope := index. >> dict add: [ methodScope ] ]. >> collection do: [ :block | Transcript show: block value; cr ] >> >> >> 2013/8/2 Max Leske <maxleske(a)gmail.com> >>> >>> >>> I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): >>> >>> expected (by my feeble mind): >>> 1 >>> 2 >>> >>> actual: >>> 2 >>> 2 >>> >>> | methodScope | >>> collection := OrderedCollection new. >>> 1 to: 2 do: [ :index | >>> methodScope := index. >>> dict add: [ methodScope ] ]. >>> >>> collection do: [ :block | Transcript show: block value; cr ] >>> >>> I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors. >>> >>> Should I open a bug report? >>> >>> Cheers, >>> Max >> >> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Camille Teruel

Just a citation: âI spent a few weeks ... trying to sort out the terminology of âstrongly typedâ, âstatically typedâ, âsafeâ, etc., and found it amazingly difï¬cult ... The usage of these terms is so various as to render them almost useless.â -- Benjamin C. Pierce If you use one of these terms, you should give a definition. And if you hear one, you shouldn't assume the author means what you think. For example some people could argue that Smalltalk is untyped (or unityped [1]), while you argued that it is strongly typed since there is no implicit type conversion. For most people, the static/dynamic and the weak/strong distinctions are supposed to be orthogonal. So, for most people, strong typing is not a synonymous of static typing. [1] http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-stati… On 2 aoÃ»t 2013, at 06:03, btc(a)openInWorld.com wrote: > greetings all, > > I'm in the final weeks of writing up my Masters dissertation and seeking some scholarly references to Smalltalk being "Strongly Typed." > > I my review of Smalltalk I was surprised to find that [1] describes Smalltalk as Strongly Typed, since Smalltalk is sometimes denigrated as being untyped / weakly typed. From reviewing discussion forums this now makes sense, but I can only find one of scholarly reference that briefly mentions this [2]. The most enlightening is [3] which defines Type Strength as: > > "A strongly typed language prevents any operation on the wrong type of data. In weakly typed languages there are ways to escape this restriction: type conversions" > > meaning that getting a MNU is a form of Strong Typing since you can't make a Smalltalk object run a method that is not its own. The problem appears to be that Strong Typing has been synonymous with Static Typing for a long time, and Static Typing strongly ties types to variables, except in Dynamically Typed languages, I think types can be considered independently from variables, in which case the definition of [3] has some merit, hence Smalltalk is Strongly Typed. > > Sounds controversial, so I'm just hoping for some peer reviewed backup - but only you have something easily to hand. This is just a small thing I can just leave out if necessary. > > cheers -ben > > [1] http://www.squeak.org/Features/ > [2] p15, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.7507&rep=rep1&t… > [3] http://www.cs.kuleuven.ac.be/publicaties/rapporten/cw/CW415.pdf >

Aug. 2, 2013

Re: [Pharo-dev] [Vm-dev] modified method temp references in closures: possible bug?

by Igor Stasenko

On 2 August 2013 15:27, Max Leske <maxleske(a)gmail.com> wrote: > > Sorry, yes, "dict" should be "collection". > > > On 02.08.2013, at 15:16, ClÃ©ment BÃ©ra <bera.clement(a)gmail.com> wrote: > > This is not a bug. > yes, the expression: [ methodScope ] does not capturing the current value of methodScope variable. means that closure, when evaluated will always return the value methodScope at the moment of evaluation. Closures do not capturing values of free variables, because then it will mean different semantic than rest of code (in method's body). > Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope. > > > Yes, I understand that. I just wanted to make sure that's the intended functionality. The reason I ask is that the error isn't easy to spot and there's no cue that one might be doing something wrong (It's not my code by the way :P). Especially for newcomers this can be a tricky one. > > I totally agree with you that the variables belong to the block and should be declared there. > > > Your code is the same as if you wrote : > | methodScope | > methodScope := 1. > methodScope := 2. > At the end, methodScope is of course 2. > > If you want the result : > 1 > 2 > you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block. > > collection := OrderedCollection new. > 1 to: 2 do: [ :index | > | methodScope | > methodScope := index. > dict add: [ methodScope ] ]. > collection do: [ :block | Transcript show: block value; cr ] > > > 2013/8/2 Max Leske <maxleske(a)gmail.com> >> >> >> I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): >> >> expected (by my feeble mind): >> 1 >> 2 >> >> actual: >> 2 >> 2 >> >> | methodScope | >> collection := OrderedCollection new. >> 1 to: 2 do: [ :index | >> methodScope := index. >> dict add: [ methodScope ] ]. >> >> collection do: [ :block | Transcript show: block value; cr ] >> >> I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors. >> >> Should I open a bug report? >> >> Cheers, >> Max > > > > -- Best regards, Igor Stasenko.

Aug. 2, 2013

Re: [Pharo-dev] [Vm-dev] modified method temp references in closures: possible bug?

by Max Leske

Sorry, yes, "dict" should be "collection". On 02.08.2013, at 15:16, ClÃ©ment BÃ©ra <bera.clement(a)gmail.com> wrote: > This is not a bug. > > Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope. Yes, I understand that. I just wanted to make sure that's the intended functionality. The reason I ask is that the error isn't easy to spot and there's no cue that one might be doing something wrong (It's not my code by the way :P). Especially for newcomers this can be a tricky one. I totally agree with you that the variables belong to the block and should be declared there. > > Your code is the same as if you wrote : > | methodScope | > methodScope := 1. > methodScope := 2. > At the end, methodScope is of course 2. > > If you want the result : > 1 > 2 > you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block. > > collection := OrderedCollection new. > 1 to: 2 do: [ :index | > | methodScope | > methodScope := index. > dict add: [ methodScope ] ]. > collection do: [ :block | Transcript show: block value; cr ] > > > 2013/8/2 Max Leske <maxleske(a)gmail.com> > > I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): > > expected (by my feeble mind): > 1 > 2 > > actual: > 2 > 2 > > | methodScope | > collection := OrderedCollection new. > 1 to: 2 do: [ :index | > methodScope := index. > dict add: [ methodScope ] ]. > > collection do: [ :block | Transcript show: block value; cr ] > > I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors. > > Should I open a bug report? > > Cheers, > Max >

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Milan Mimica

On 2 August 2013 06:03, <btc(a)openinworld.com> wrote: > > "A strongly typed language *prevents* any operation on the wrong type of > data. In weakly typed languages there are ways to escape this restriction: > type conversions" > > meaning that getting a MNU is a form of Strong Typing since you can't make > a Smalltalk object run a method that is not its own. How is that preventing? -- Milan Mimica http://sparklet.sf.net

Aug. 2, 2013

Re: [Pharo-dev] [Vm-dev] modified method temp references in closures: possible bug?

by ClÃ©ment BÃ©ra

This is not a bug. Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope. Your code is the same as if you wrote : | methodScope | methodScope := 1. methodScope := 2. At the end, methodScope is of course 2. If you want the result : 1 2 you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block. collection := OrderedCollection new. 1 to: 2 do: [ :index | | methodScope | methodScope := index. dict add: [ methodScope ] ]. collection do: [ :block | Transcript show: block value; cr ] 2013/8/2 Max Leske <maxleske(a)gmail.com> > > I just came across this (possible) bug and I'm able to reproduce it in > Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): > > expected (by my feeble mind): > 1 > 2 > > actual: > 2 > 2 > > | methodScope | > collection := OrderedCollection new. > 1 to: 2 do: [ :index | > methodScope := index. > dict add: [ methodScope ] ]. > > collection do: [ :block | Transcript show: block value; cr ] > > I'm aware that using method temps in this way is not good programming > style (usually) but I still think this behavior is curious if not at least > very likely to cause a lot of weird errors. > > Should I open a bug report? > > Cheers, > Max

Aug. 2, 2013

Re: [Pharo-dev] [Vm-dev] modified method temp references in closures: possible bug?

by Igor Stasenko

On 2 August 2013 15:08, Max Leske <maxleske(a)gmail.com> wrote: > > I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): > > expected (by my feeble mind): > 1 > 2 > > actual: > 2 > 2 > > | methodScope | > collection := OrderedCollection new. > 1 to: 2 do: [ :index | > methodScope := index. > dict add: [ methodScope ] ]. > > collection do: [ :block | Transcript show: block value; cr ] > err.. i see dict add: but where dict was declared? > I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors. > > Should I open a bug report? > > Cheers, > Max -- Best regards, Igor Stasenko.

Aug. 2, 2013

modified method temp references in closures: possible bug?

by Max Leske

I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): expected (by my feeble mind): 1 2 actual: 2 2 | methodScope | collection := OrderedCollection new. 1 to: 2 do: [ :index | methodScope := index. dict add: [ methodScope ] ]. collection do: [ :block | Transcript show: block value; cr ] I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors. Should I open a bug report? Cheers, Max

Aug. 2, 2013

Morph inspect weird behavior

by Erwan Douaille

Hi, I found something else weird, When i inspect a Morph the bounds are resized. Do it : a := Morph newBounds: (Rectangle origin: (0@0) corner: (300@300) ). a color: Color red. a openInWorld Now click on the morph, open halo, inspect it and the bounds are resized. Is that normal ? (I guess not) Thanks :) -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Igor Stasenko

On 2 August 2013 06:03, <btc(a)openinworld.com> wrote: > greetings all, > > I'm in the final weeks of writing up my Masters dissertation and seeking > some scholarly references to Smalltalk being "Strongly Typed." > > I my review of Smalltalk I was surprised to find that [1] describes > Smalltalk as Strongly Typed, since Smalltalk is sometimes denigrated as > being untyped / weakly typed. From reviewing discussion forums this now > makes sense, but I can only find one of scholarly reference that briefly > mentions this [2]. The most enlightening is [3] which defines Type Strength > as: > > "A strongly typed language prevents any operation on the wrong type of data. > In weakly typed languages there are ways to escape this restriction: type > conversions" > > meaning that getting a MNU is a form of Strong Typing since you can't make a > Smalltalk object run a method that is not its own. The problem appears to > be that Strong Typing has been synonymous with Static Typing for a long > time, and Static Typing strongly ties types to variables, except in > Dynamically Typed languages, I think types can be considered independently > from variables, in which case the definition of [3] has some merit, hence > Smalltalk is Strongly Typed. > > Sounds controversial, so I'm just hoping for some peer reviewed backup - but > only you have something easily to hand. This is just a small thing I can > just leave out if necessary. > There's not much controversy.. C, for instance is weakly typed, since you can say: unsigned int a = 10; int b = a; but at same time, C is statically typed language. So apparently 'strong' is not synonym to 'static'. > cheers -ben > > [1] http://www.squeak.org/Features/ > [2] p15, > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.7507&rep=rep1&t… > [3] http://www.cs.kuleuven.ac.be/publicaties/rapporten/cw/CW415.pdf > -- Best regards, Igor Stasenko.

Aug. 2, 2013

New Cog VMs available

by Eliot Miranda

...at http://www.mirandabanda.org/files/Cog/VM/VM.r2761/. CogVM binaries as per VMMaker.oscog-eem.317/r2761 Fix bug in transferTo:(from:) when doing a code compaction when ensuring there is a machine code method when switching to a process whose context has a machine code pc. Limit the ammount of space the Cogit will stack allocate when compiling. This limits the maximum number of bytecodes in a method that the Cogit will compile. Currently set at 1.5Mb of stack space from empirical tests of alloca on Mac OS X 10.6, linux 2.6 & Windows XP. Fix become for cog methods that are not paired with their bytecoded methods (e.g. Newspeak accessors). Linux: There are two variants of the Linux VMs; those ending in "ht" have a heartbeat thread, while those that don't, use an interval timer for the heartbeat (the Windows and Mac VMs have a threaded heartbeat). The threaded heartbeat is better (for example, signals from the interval timer interfere with system calls, etc), but to use it one must have a kernel later than 2.6.12 and configure linux to allow the VM to use multiple thread priorities. To do so, create a file called VM.conf where VM is the name of the vm executable ("squeak" for the Squeak vm, "nsvm" for the Newspeak vm) in /etc/security/limits.d/ with contents: * hard rtprio 2 * soft rtprio 2 e.g. sudo cat >/etc/security/limits.d/squeak.conf <<END * hard rtprio 2 * soft rtprio 2 sudo cp /etc/security/limits.d/squeak.conf /etc/security/limits.d/nsvm.conf END Then log out and log back in for the limits to take effect. -- best, Eliot

Aug. 2, 2013

Smalltalk = strongly typed

by btc＠openinworld.com

greetings all, I'm in the final weeks of writing up my Masters dissertation and seeking some scholarly references to Smalltalk being "Strongly Typed." I my review of Smalltalk I was surprised to find that [1] describes Smalltalk as Strongly Typed, since Smalltalk is sometimes denigrated as being untyped / weakly typed. From reviewing discussion forums this now makes sense, but I can only find one of scholarly reference that briefly mentions this [2]. The most enlightening is [3] which defines Type Strength as: "A strongly typed language prevents any operation on the wrong type of data. In weakly typed languages there are ways to escape this restriction: type conversions" meaning that getting a MNU is a form of Strong Typing since you can't make a Smalltalk object run a method that is not its own. The problem appears to be that Strong Typing has been synonymous with Static Typing for a long time, and Static Typing strongly ties types to variables, except in Dynamically Typed languages, I think types can be considered independently from variables, in which case the definition of [3] has some merit, hence Smalltalk is Strongly Typed. Sounds controversial, so I'm just hoping for some peer reviewed backup - but only you have something easily to hand. This is just a small thing I can just leave out if necessary. cheers -ben [1] http://www.squeak.org/Features/ [2] p15, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.7507&rep=rep1&t… [3] http://www.cs.kuleuven.ac.be/publicaties/rapporten/cw/CW415.pdf

Aug. 2, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Marcus Denker

On Aug 1, 2013, at 9:04 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > indeed this is what marcus thought. > So we found a nice bug. > I added a tracker entry: https://pharo.fogbugz.com/f/cases/11291/Announcer-for-Morphs-should-be-Weak (I will be on holidays starting tomorrow afternoon, so no action on this from me for a whileâ¦) Marcus

Aug. 1, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by StÃ©phane Ducasse

indeed this is what marcus thought. So we found a nice bug. Stef On Aug 1, 2013, at 7:47 PM, phil(a)highoctane.be wrote: > Continuing on the topic, it looks like that every single window that I ever opened is remembered by the Announcements... > > Cursor wait showWhile: [ > (FileSystem disk workingDirectory / 'WindowLabelled-labels.txt') asFileReference writeStreamDo: [ :s | > > WindowLabelled allInstances do: [ :each | each label printOn: s. s lf ]. > > ] > ]. > > The attached file is what I got. > > Phil > > On Thu, Aug 1, 2013 at 3:47 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ok, we are looking at that with marcus. > > So, one thing that may be causing problems is that there are some usages of #onAnnouncement: anAnnouncement do: aBlock. And since we don't have ephermerons, the usage of blocks in announcements is leaking references. > > Also, looking at the usages of onAnnouncement:do:, we found NECController>>setEditor:, which is called for every keystroke in when using autocompletion :D. Maybe the cause is around here? > > > > > On Thu, Aug 1, 2013 at 1:40 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Yes, I think the announcers of morph might be the cause of the problem... > > > On Thu, Aug 1, 2013 at 1:09 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I did a little run on those MorphExtensions and got the output file in annex. > > Cursor wait showWhile: [ > (FileSystem disk workingDirectory / 'MorphExtensions.txt') asFileReference writeStreamDo: [ :s | > MorphExtension allInstancesDo: [ :each | > each printOn: s. > s lf > ] > ] > ]. > > Looks like there are a lot of Announcers. > > Phil > > > On Thu, Aug 1, 2013 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 1, 2013, at 1:31 AM, phil(a)highoctane.be wrote: > >> Doing the flushCaches... >> >> Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/estebanlm/EclipsePack/m… : 324017564 >> Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/estebanlm/EclipsePack/m… : 324137232 >> Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/DripfeedIt… : 324137232 >> Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/DripfeedIt… : 324195720 >> Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOWebStack… : 324195720 >> Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOWebStack… : 324255300 >> Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOExperime… : 324255300 >> Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOExperime… : 324314868 >> >> Definitely not going down... >> > > No, we already saw that in your case the reason are many,many instances of MorphExtension without the Morphs hanging around. > (which should not happen as MorphExtensions are only referenced by the Morph they extend). > > Your case is not a case of caches, there is a real problem somewhere. > > Marcus > > > > > > -- > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de > > > <WindowLabelled-labels.txt.gz>

Aug. 1, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by phil＠highoctane.be

Continuing on the topic, it looks like that every single window that I ever opened is remembered by the Announcements... Cursor wait showWhile: [ (FileSystem disk workingDirectory / 'WindowLabelled-labels.txt') asFileReference writeStreamDo: [ :s | WindowLabelled allInstances do: [ :each | each label printOn: s. s lf ]. ] ]. The attached file is what I got. Phil On Thu, Aug 1, 2013 at 3:47 PM, Guillermo Polito <guillermopolito(a)gmail.com>wrote: > Ok, we are looking at that with marcus. > > So, one thing that may be causing problems is that there are some usages > of #onAnnouncement: anAnnouncement do: aBlock. And since we don't have > ephermerons, the usage of blocks in announcements is leaking references. > > Also, looking at the usages of onAnnouncement:do:, we found > NECController>>setEditor:, which is called for every keystroke in when > using autocompletion :D. Maybe the cause is around here? > > > > > On Thu, Aug 1, 2013 at 1:40 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> Yes, I think the announcers of morph might be the cause of the problem... >> >> >> On Thu, Aug 1, 2013 at 1:09 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: >> >>> I did a little run on those MorphExtensions and got the output file in >>> annex. >>> >>> Cursor wait showWhile: [ >>> (FileSystem disk workingDirectory / 'MorphExtensions.txt') >>> asFileReference writeStreamDo: [ :s | >>> MorphExtension allInstancesDo: [ :each | >>> each printOn: s. >>> s lf >>> ] >>> ] >>> ]. >>> >>> Looks like there are a lot of Announcers. >>> >>> Phil >>> >>> >>> On Thu, Aug 1, 2013 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >>> >>>> >>>> On Aug 1, 2013, at 1:31 AM, phil(a)highoctane.be wrote: >>>> >>>> Doing the flushCaches... >>>> >>>> Image size before cleaning a MCSmalltalkhubRepository( >>>> http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324017564 >>>> Image size after cleaning a MCSmalltalkhubRepository( >>>> http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324137232 >>>> Image size before cleaning a MCSmalltalkhubRepository( >>>> http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324137232 >>>> Image size after cleaning a MCSmalltalkhubRepository( >>>> http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324195720 >>>> Image size before cleaning a MCSmalltalkhubRepository( >>>> http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324195720 >>>> Image size after cleaning a MCSmalltalkhubRepository( >>>> http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324255300 >>>> Image size before cleaning a MCSmalltalkhubRepository( >>>> http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : >>>> 324255300 >>>> Image size after cleaning a MCSmalltalkhubRepository( >>>> http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : >>>> 324314868 >>>> >>>> Definitely not going down... >>>> >>>> >>>> No, we already saw that in your case the reason are many,many instances >>>> of MorphExtension without the Morphs hanging around. >>>> (which should not happen as MorphExtensions are only referenced by the >>>> Morph they extend). >>>> >>>> Your case is not a case of caches, there is a real problem somewhere. >>>> >>>> Marcus >>>> >>>> >>> >> >> >> -- >> -- >> Marcus Denker -- denker(a)acm.org >> http://www.marcusdenker.de >> > >

Aug. 1, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by phil＠highoctane.be

I got a pretty large number with these announcements... provided nothing special is running at the moment... Announcement allSubInstances size. 14120 And: (Announcement allSubInstances collect: [ :a | a class ]) asSet a Set(WindowOpened WindowLabelled WindowClosed KMCompleteMatch TestSuiteEnded ClassRemoved) And ann:=(Announcement allSubInstances collect: [ :a | a class ]) asSet. ann do: [ :each | Transcript nextPutAll: each className; nextPut: $:; nextPutAll: each allInstances size printString;cr]. Transcript flush. gives: WindowOpened class:WindowOpened class:953 WindowOpened class:956 WindowLabelled class:11837 WindowClosed class:1345 KMCompleteMatch class:6 TestSuiteEnded class:1 ClassRemoved class:1 Well, 11837 for WindowLabelled is quite large. Hope it gives a hint. Phil

Aug. 1, 2013

Re: [Pharo-dev] killing all uses of caseOf: and caseOf:otherwise from the image

by Frank Shearar

On 1 August 2013 15:20, Igor Stasenko <siguctua(a)gmail.com> wrote: > We had quite hot discussion about this topic in the past.. > I don't think it makes sense to repeat arguments.. > because i think it won't convert anyone in either camp (those who > [dis]agree, will still [dis]agree). > so, lets just move on. In a way I'm not asking about the merits or otherwise of #caseOf:. I'm just wondering about what you _gain_ by removing the calls. Replacing type-switching code with polymorphism is almost always a clear win, for instance. But "kill all (non-type-switching) senders" doesn't give you much, except harder to read chained if/elses. frank > -- > Best regards, > Igor Stasenko. >

Aug. 1, 2013

Re: [Pharo-dev] killing all uses of caseOf: and caseOf:otherwise from the image

by Igor Stasenko

We had quite hot discussion about this topic in the past.. I don't think it makes sense to repeat arguments.. because i think it won't convert anyone in either camp (those who [dis]agree, will still [dis]agree). so, lets just move on. -- Best regards, Igor Stasenko.

Aug. 1, 2013

Re: [Pharo-dev] Windows problem with FilePlugin ?

by Marcus Denker

On Aug 1, 2013, at 4:17 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > Yep :) > > Thanks for your help. > I opened an issue for that (11293) and I will try to tackle it tonight > There is already 11195 FileBrowser Tree in Pharo 3.0 does not work on Windows https://pharo.fogbugz.com/f/cases/11195

Aug. 1, 2013