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

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