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

Re: [Pharo-project] [COTDC] 91 - WeakOrderedCollection

by Sean P. DeNigris

Thank you Mariano and Henrik! -- View this message in context: http://forum.world.st/COTDC-91-WeakOrderedCollection-tp4164903p4166075.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 6, 2011

[Pharo-project] Squeak/Pharo in Fedora

by Pavel Krivanek

Hi, I want make a little report about progress with making of Fedora pakcages for Smalltalk related projects (StackVM, CogVM, Pharo...) by Jaroslav Å karvada. Currently there are three packages in Fedora repositories - squeak-vm, squeak-image and squeak-vm-nonXOplugins (that contains plugins like OSProcess). It uses resources from the Squeak site. Red Hat has quite restrictive demands on packages and it is a small miracle that they tolerate current squeak packages :-). The conditions simply do expect that a program is a set of source codes and not a system of communicating objects. One problem is that Squeak VM is one of few metacircular packages that are needed for their own building. Because binary executables are prohibited, it would require a special bureaucratically problematic exception. Fortunately for virtual machine generation we may use the current squeak packages - more precisely their updated versions. The next issue for virtual machine generation may be the fact, that some packages used for VM generation are in repositories with public read&write permissions. Because image can be likened to *.jar files that are prohibited and must be recompiled during package generation, we are lucky that squeak-image package is currently accepted. If someone starts tinkering, we are in big trouble. There is a little issue with *.sources placement. The current VM package contains symlinks from VM path to sources files that are present in package with the image. This is really ugly solution. Squeak and Pharo uses this sequence for sources lookup: vm path, image path, current path. So I think that the best solution will be to have sources file in the image package, do not have symlinks in vm package and to create symlink to sources together with changes in the image path via mysqueak initialization script. Btw., Jaroslav told me that he saw a lot of creepy projects but nothing like Squeak VM :-) And there is a mess in VM versioning. What is the latest CogVM/StackVM version number? Cheers, -- Pavel

Dec. 6, 2011

Re: [Pharo-project] [squeak-dev] could you test the attached?

by Eliot Miranda

On Mon, Dec 5, 2011 at 9:13 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Dec 5, 2011, at 2:58 PM, Marcus Denker wrote: > > > Hi, > > > > With this change set, we get an error when doing the following: > > > > In the workspace do a "debug it" on this code: > > > > Transcript show: Class name > > > > then two times "step over" --> Subscript out of bounds error. Without > > the change it works. > > this shows that squeak related fix should be applied with care and that we > should understand deeply our system. > Not really. That was not a fix. It was a potential fix that I was asking people to test. Marcus found a test case that demonstrated a problem with my fix. With Marcus' case I was able to correct my fix and today Levente committed my revised fix to Squeak and Marcus has updated Pharo. So things worked well. I found a bug, developed a partial fix, asked for testing help, got it, revised my fix. And this in a very difficult to understand part of the system. I'm trying but I'm not happy with my knowledge on certain parts. But since > there is little documentation and some abstractions > are not aligned, this makes everything more challenging. > > When I see the senders, I think that it will be delicate to fix > > Process>>terminate > "Stop the process that the receiver represents forever. Unwind to > execute pending ensure:/ifCurtailed: blocks before terminating." > > | ctxt unwindBlock oldList | > self isActiveProcess > ifTrue: [ > ctxt := thisContext. > [ ctxt := ctxt findNextUnwindContextUpTo: nil. > ctxt isNil ] whileFalse: > [ (ctxt tempAt: 2) ifNil: > [ ctxt tempAt: 2 put: nil. > unwindBlock := ctxt tempAt: 1. > thisContext terminateTo: ctxt. > unwindBlock value ]]. > thisContext terminateTo: nil. > self suspend ] > ifFalse: [ > "Always suspend the process first so it doesn't > accidentally get woken up" > oldList := self suspend. > suspendedContext ifNotNil:[ > "Figure out if we are terminating the > process while waiting in Semaphore>>critical: > In this case, pop the suspendedContext so > that we leave the ensure: block inside > Semaphore>>critical: without signaling the > semaphore." > (oldList class == Semaphore and:[ > suspendedContext method == > (Semaphore compiledMethodAt: #critical:)]) ifTrue:[ > suspendedContext := > suspendedContext home.]. > > "If we are terminating a process halfways through > an unwind, try to complete that unwind block first." > (suspendedContext > findNextUnwindContextUpTo: nil) ifNotNil: [ :outer | > (suspendedContext findContextSuchThat: [ :c > | c closure == (outer tempAt: 1)]) > ifNotNil: [ :inner | > "This is an unwind block > currently under evaluation" > suspendedContext > runUntilErrorOrReturnFrom: inner ]]. > ctxt := self popTo: suspendedContext bottomContext. > ctxt == suspendedContext bottomContext ifFalse: [ > self debug: ctxt title: 'Unwind error > during termination']] ]. > > Process>>complete: aContext > "Run self until aContext is popped or an unhandled error is raised. > Return self's new top context, unless an unhandled error was raised then > return the signaler context (rather than open a debugger)." > > | ctxt pair error | > ctxt := suspendedContext. > suspendedContext := nil. "disable this process while running its > stack in active process below" > pair := ctxt runUntilErrorOrReturnFrom: aContext. > suspendedContext := pair first. > error := pair second. > error ifNotNil: [^ error signalerContext]. > ^ suspendedContext > > > > > > On Wed, Nov 16, 2011 at 8:58 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi All, > >> > >> I've found a bug in ContextPart>>#runUntilErrorOrReturnFrom: that > in a > >> certain rare circumstance causes the method to peel back too much of the > >> stack. This method is used in the debugger (e.g. completeStep: et al) > but > >> also in Process termination. So it is right at the heart of the system. > >> I'm loath to simply commit it I'd really appreciate y'all testing > with the > >> fix and reporting any changes you see. It does not affect the trunk > test > >> suite (there is a test, WeakSetInspectorTest, which is unreliable, but > apart > >> form that no observed effects). So, brave souls, please try with the > >> attached and see if you come to grief or not. > >> -- > >> thanks, > >> Eliot > >> > > > > > > > > -- > > -- > > Marcus Denker -- denker(a)acm.org > > http://www.marcusdenker.de > > > > > -- best, Eliot

Dec. 6, 2011

Re: [Pharo-project] Zinc problem

by Sven Van Caekenberghe

On 06 Dec 2011, at 18:37, Norbert Hartl wrote: > Sven, > > I've uploaded the fix. Information can be found in the issue > > http://code.google.com/p/pharo/issues/detail?id=5063 > > Norbert Accepted! See my comments in the issue. Thanks a lot. Sven

Dec. 6, 2011

Re: [Pharo-project] issue 5048 broke Pharo Kernel

by Pavel Krivanek

We need it in the Kernel because some classes log system messages there (like Compiler during recompilation of the image). I think that own separate package would be fine. -- Pavel On Tue, Dec 6, 2011 at 5:36 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > how can we fix it? > Because we believe that Transcript should not be packaged in Stream. > Now may be in its own package. > > Stef > > On Dec 6, 2011, at 3:40 PM, Pavel Krivanek wrote: > >> Hi, >> >> the issue http://code.google.com/p/pharo/issues/detail?id=5048 broke >> Pharo-Kernel build on CI server. >> >> -- Pavel >> > >

Dec. 6, 2011

Re: [Pharo-project] UIManager

by Pavel Krivanek

On Tue, Dec 6, 2011 at 12:30 PM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 06.12.2011 11:46, Henrik Sperre Johansen wrote: >> >> Is it just me, or is UIManager gradually turning into a new >> SystemDictionary/Project? >> >> Cheers, >> Henry > > And by that I mean equivalent to those classes in purity of purpose and > simplicity; > UIManager used to have a clear purpose - Provide a polymorphic interface for > accessing common GUI dialogs for code which doesn't care which GUI framework > is in use. > > Right now, MorphicUIMananger also has methods for > - Component building (a poor mans ToolBuilder, basically) > - Â Global state accessor, not polymorphic (world and uiProcess handling ) > - Debugger components building (!) > - Accessing common Smalltalk tools (not necessarily a bad thing, but > shouldn't that be the responsibility of ToolRegistry? IE a UIManager should > install a proper ToolRegistry when activated, not provide an extra layer of > indirection you HAVE to use if you say, want your app to work headlessly) > - something called interactiveParserFor: I have no idea what means. this method resolves if the UIManager is able to process questions from the parser/compiler on user (like warnings about unimplemented callss, undeclared instance variables etc.). -- Pavel > - etc. etc. etc. > > Cheers, > Henry > > > >

Dec. 6, 2011

Re: [Pharo-project] Zinc problem

by Norbert Hartl

Sven, I've uploaded the fix. Information can be found in the issue http://code.google.com/p/pharo/issues/detail?id=5063 Norbert Am 06.12.2011 um 18:03 schrieb Norbert Hartl: > > Am 06.12.2011 um 16:23 schrieb Sven Van Caekenberghe: > >> Please file a bug report. You could also suggest a fix based on the lastet version if you feel like it. Or at least some unit test. > > I have a fix for it. But I can't commit because squeaksource is down. > > Basically I changed ZnUtils>>writeQueryFields:on: to ZnUtils>>writeQueryFields:withTextEncoding:on: which uses encodeForHTTPWithTextEncoding: instead of encodeForHTTP. In ZnApplicationFormUrlEncodedEntity it checks for the encoding and uses the appropriate method. > > This is not nice but en par with the previous solution. I think the default behaviour (which encoding to use) needs to be configurable as well. The only thing that points towards a default is the w3c recommendation to use utf-8 for url safe encoding. But there is no strong reason to use any of those. >

Dec. 6, 2011

Re: [Pharo-project] Zinc problem

by Norbert Hartl

Am 06.12.2011 um 16:23 schrieb Sven Van Caekenberghe: > Please file a bug report. You could also suggest a fix based on the lastet version if you feel like it. Or at least some unit test. I have a fix for it. But I can't commit because squeaksource is down. Basically I changed ZnUtils>>writeQueryFields:on: to ZnUtils>>writeQueryFields:withTextEncoding:on: which uses encodeForHTTPWithTextEncoding: instead of encodeForHTTP. In ZnApplicationFormUrlEncodedEntity it checks for the encoding and uses the appropriate method. This is not nice but en par with the previous solution. I think the default behaviour (which encoding to use) needs to be configurable as well. The only thing that points towards a default is the w3c recommendation to use utf-8 for url safe encoding. But there is no strong reason to use any of those. Norbert

Dec. 6, 2011

Re: [Pharo-project] Loading MCZ freezes, but loading the source.st works?

by StÃ©phane Ducasse

> > Yes. With the experiment of Tobias, the #writeSnapshot: and #loadDefinitions took only 1% of the whole process.....soâ¦ the problem is - classbuilder - logging - â¦ so we should go step by step > > Now, for that radical change you mention, we have started to think a little bit: > > 1) we need to store the source code anyway. This is because we would need to recompile all CompiledMethod (because of instance variable accessing bytecodes) when the superclass of a class which is in the image changes it shape (hence, instance variables moved their index). For this purpose, we thought we can easily store the source code in the method trailer and serialize that. The thing is at materialization. What do we once we have materialized? we keep the sources in teh CM or we put them in the .changes file and we put back a .changes pointer in the trailer??? should a load of a package always store in .changes ? > > 2) Since we materialize classes without class builder, and this monster does everything together, we need to analyze what has to be done exactly when materializing a package for example: notify class creation/modification, validations (what happens if the class already exist, etc.), etc, etc. This is the most difficult part for us, since understanding what the classbuilder does is complicated.... > > Our progress is in FuelPackageLoader... > > Cheers > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 6, 2011

Re: [Pharo-project] Questions about Weak classes

by Igor Stasenko

Its an object format specific stuff. The weak object can have a fixed slots (ivars) which are strongly referenced, and only variable slots are weakly referenced. If you will want to make ivars to be also weakly referenced, then you will need another object format. On 6 December 2011 16:14, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. I have two small questions related to weak objects. > > 1) It seems all Weak objects are variable. ALWAYS. Why?Â It doesn't make > sense to have a fixed weak object ? > > 2) We have the methods: > > variableByteSubclass: t instanceVariableNames: fÂ classVariableNames: d > poolDictionaries: s category: cat > variableSubclass: t instanceVariableNames: fÂ classVariableNames: d > poolDictionaries: s category: cat > variableWordSubclass: t instanceVariableNames: f classVariableNames: d > poolDictionaries: s category: cat > > So... WHY we have then: > > weakSubclass: t instanceVariableNames: fÂ classVariableNames: d > poolDictionaries: s category: cat > > rather than > > variableWeakSubclass: t instanceVariableNames: fÂ classVariableNames: d > poolDictionaries: s category: cat > > is there any reason I am not seeing? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

Dec. 6, 2011