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

[Pharo-project] Issue 3876 in pharo: SqNumberParserTest>>testFloatGradualUnderflow has an odd condition
by pharo＠googlecode.com March 25, 2011

March 25, 2011

Status: Accepted Owner: da...(a)teleport.com Labels: Importance-Low New issue 3876 by da...(a)teleport.com: SqNumberParserTest>>testFloatGradualUnderflow has an odd condition http://code.google.com/p/pharo/issues/detail?id=3876 SqNumberParserTest>>testFloatGradualUnderflow has an odd condition: In the following code, note that #areLowercaseDigitsAllowed is expected to return nil or notNil: "Parse the number in base 16 if possible - it is impossible if lowercase letter are allowed digits due to exponent letter ambiguity." float := self areLowercaseDigitsAllowed ifNil: [SqNumberParser parse: '16r2.D2593D58B4FC4e-256'] ifNotNil: [trueFraction asFloat]. but #areLowercaseDigitsAllowed returns true or false and in the 1.2 image it returns true ... implying that is impossible to parse? As it stands the `trueFraction asFloat` expression is always executed ... I'm trying to port SqNumberParser to GemStone and this little section of code is misleading, especially considering that GemStone doesn't pass the test:)

1 5

[Pharo-project] Issue 3880 in pharo: Balloon Tests not categorized/commented in 1.3
by pharo＠googlecode.com March 25, 2011

March 25, 2011

Status: Accepted Owner: Torsten....(a)astares.de Labels: Milestone-1.3 New issue 3880 by Torsten....(a)astares.de: Balloon Tests not categorized/commented in 1.3 http://code.google.com/p/pharo/issues/detail?id=3880 uncategorizes methods in category "Balloon-Collections-Tests"

1 2

[Pharo-project] Issue 3861 in pharo: Image freeze when changing system time
by pharo＠googlecode.com March 25, 2011

March 25, 2011

Status: New Owner: ---- New issue 3861 by lem...(a)gmail.com: Image freeze when changing system time http://code.google.com/p/pharo/issues/detail?id=3861 Pharo image: Pharo1.2.1a Latest update: #12343 Virtual machine used: 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.47' System: GNU / Linux. Opensuse 11.4 x86_64. KDE 4.6 Steps to reproduce: 1. open the image 2. change the time in my system to a previous time. For example from 13:00 to 12:00. 3. Image freeze... and you have to kill the vm. I try the same thing, with 'Squeak4.1 of 17 April 2010 [latest update: #9957]' VM, and it didn't freeze. I tested also both machines opened, and only cog freeze. So i think maybe it's a cog vm issue.

1 4

[Pharo-project] Issue 3715 in pharo: Workspace shouting after switching between shout/unshout
by pharo＠googlecode.com March 25, 2011

March 25, 2011

Status: Accepted Owner: Benjamin...(a)gmail.com New issue 3715 by Benjamin...(a)gmail.com: Workspace shouting after switching between shout/unshout http://code.google.com/p/pharo/issues/detail?id=3715 I do not know why but when you switch unshout -> shout again in the menu, then when you automatically declare a variable, this one is not correctly shouted But first, I will fix the bold issue ^^

2 10

[Pharo-project] Issue 3859 in pharo: Pluggin control
by pharo＠googlecode.com March 25, 2011

March 25, 2011

Status: FixToInclude Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3859 by stephane...(a)gmail.com: Pluggin control http://code.google.com/p/pharo/issues/detail?id=3859 Hello, just as outcome of previous discussion about security. I think that we missing a mechanism(s) in VM, which will prevent loading new modules into running system, to ensure that no external code could compromise a system security. In terms of implementation a change is quite simple: - add a flag into VM's state, named moduleLoadingEnabled - initially this flag should be set to true during system startup - add a primitive which resets this flag Then modify ioLoadModule: OfLength: to fail unconditionally if module loading is disabled. In practice this means that knowing a secure set of modules you are need for your deployment scenario and have them all loaded at startup, you intentionally disabling a module loading mechanism, to prevent any chance to interact with modules which could compromise your security model. There's also a missing bit in VM api to explicitly load the module with given name. However it is included in IA32ABIPlugin (#primLoadLibrary), but then maybe you don't want to have IA32ABIPlugin at first place, that's why i proposing to promote this primitive to core VM API. So, by having these bits working, one could implement sandbox mode quite easily, by doing something like following during image startup: self deployed ifTrue: [ " make sure we loaded modules we will need" #( 'PluginA' 'PluginB' .... 'PluginZ' ) do: [ :each | Smalltalk loadModule: each ]. Smalltalk disableModuleLoading. ]. Then later any code that will try to use plugins, that is not loaded before you disabled module loading mechanism, will simply fail. This will be good addition to existing security mechanisms. Attachments: SmalltalkImage-loadModule.st 424 bytes SmalltalkImage-disableModuleLoading.st 460 bytes

1 2

[Pharo-project] Issue 3879 in pharo: Wipe out positional arguments cruft from compiler
by pharo＠googlecode.com March 25, 2011

March 25, 2011

Status: FixToInclude Owner: siguc...(a)gmail.com New issue 3879 by siguc...(a)gmail.com: Wipe out positional arguments cruft from compiler http://code.google.com/p/pharo/issues/detail?id=3879 Removes the #positionalArgument from Scanner and Parser So, now #(foo(bar)) is parsed correctly Attachments: Compiler-ar.197.1.cs 1.9 KB

1 2

[Pharo-project] Issue 3881 in pharo: Problem with Inst var refs...
by pharo＠googlecode.com March 25, 2011

March 25, 2011

Status: FixProposed Owner: Benjamin...(a)gmail.com Labels: Nautilus New issue 3881 by Benjamin...(a)gmail.com: Problem with Inst var refs... http://code.google.com/p/pharo/issues/detail?id=3881 If you click, the popup window have the good name, but if you choose to sort var names alphabetically, you have a stupid name Attachments: FixTitleIssueInInstVarBrowser.1.cs 748 bytes

1 2

[Pharo-project] Remove #class as a Compiler optimization
by Mariano Martinez Peck March 25, 2011

March 25, 2011

Hi. I have to say that I hate that the compiler associates a special bytecode for #class and that the VM don't even send the message. I want to be able to overwrite #class in a proxy for example, or to debug it. I did some benchmarks disabling such optimization by doing: (ParseNode classVarNamed: 'StdSelectors') removeKey: #class ifAbsent: []. Compiler recompileAll. And the difference is NOTHING in my tests (maybe I am doing something wrong). With Standard VM and #class optimization [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 50 miliseconds With Standard VM and WITHOUT #class optimization [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 60 miliseconds So...only 10 miliseconds more for asking the class to all the objects in the system.....(done in a PharoCore 1.3) With Cog VM and #class optimization [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 13 miliseconds With Cog VM and WITHOUT #class optimization [SystemNavigation default allObjectsDo: [:each | each class]] timeToRun -> aprox 17 miliseconds So...only 5 miliseconds more for asking the class to all the objects in the system.....(done in a PharoCore 1.3) Considering (5 / 324535) asFloat 0,000015406... of overhead What do you think? Mariano

2 1

Re: [Pharo-project] problem with obsolete classes in latest core
by Marcus Denker March 25, 2011

March 25, 2011

On Mar 25, 2011, at 3:46 PM, Marcus Denker wrote: > >> fixObsoleteReferences only fixes CompiledMethods, doesn't it ? >> > > yep. > And the trick to find them is to inspect SystemNavigation default obsoleteClasses first allInstances and then use the "explore pointers" on that. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 3

Re: [Pharo-project] problem with obsolete classes in latest core
by Marcus Denker March 25, 2011

March 25, 2011

On Mar 25, 2011, at 3:44 PM, Mariano Martinez Peck wrote: > > > On Fri, Mar 25, 2011 at 3:41 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Mar 24, 2011, at 7:25 PM, Mariano Martinez Peck wrote: >> Compiler recompileAll. >> Smalltalk fixObsoleteReferences. >> >> SystemNavigation default obsoleteClasses ->>> an Array(AnObsoleteWordArray) >> >> But I cannot get rid of that final obsoletClass. >> > > > If you check for the users of WordArray, they are stored in some class vars... > > BalloonEngine initialize. > DataStream initialize. > DeflateStream initialize. > FastInflateStream initialize. > ZipConstants initialize. > ZipWriteStream initialize. > PNGReadWriter initialize > > seems to solve it. > > Thanks Marcus...so...I am trying to understand the problem. You are saying that if there is a class stored in an instVar somewhere, class var. > and I remove/renamed or whatever that class, then those instVar will be pointing to the obsolete one? yes. > fixObsoleteReferences only fixes CompiledMethods, doesn't it ? > yep. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0