- Pharo-dev - lists.pharo.org

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