- Pharo-dev - lists.pharo.org

[Pharo-project] Loading MCZ freezes, but loading the source.st works?
by Stefan Marr Dec. 7, 2011

Dec. 7, 2011

Hi: I got here a Monticello package that does not properly load using the Metacello configuration. The image freezes and cmd+. does not pop up a debugger anymore. However, if I extract the source.st contained in the package and file it in manually, it does not freeze the image. I belief that I once saw with appropriate Transcript>>#show that something caused an infinite loop. There are dependencies in overrides I do on kernel classes. They seem to be properly resolved in the source.st file. Is there a way to force Monticello/Metacello to fall back on the included source instead of using the binary snapshot? (I guess that is going wrong for some reason). Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

5 12

[Pharo-project] [update 1.4] #14251
by Marcus Denker Dec. 7, 2011

Dec. 7, 2011

14251 ----- Issue 5070: Failing test: KernelTests.Objects.SelfEvaluatingObjectTest.testArray http://code.google.com/p/pharo/issues/detail?id=5070 Issue 5069: Do a DebuggerMethodMap initialize in the postscript http://code.google.com/p/pharo/issues/detail?id=5069 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 1.4] #14250
by Marcus Denker Dec. 7, 2011

Dec. 7, 2011

14250 ----- Issue 5064: remove useless stripe behavior from ProgressBarMorph http://code.google.com/p/pharo/issues/detail?id=5064 Issue 4998: ContextPart>>#runUntilErrorOrReturnFrom: http://code.google.com/p/pharo/issues/detail?id=4998 (2nd try) -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 1.4] #14249
by Marcus Denker Dec. 7, 2011

Dec. 7, 2011

14249 ----- Issue 4491: Cleanup DebuggerMethodMap old blocks http://code.google.com/p/pharo/issues/detail?id=4491 -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] Why CompiledMethod print string shows #identityHah ?
by Marcus Denker Dec. 7, 2011

Dec. 7, 2011

On Dec 6, 2011, at 5:15 PM, Mariano Martinez Peck wrote: > > So...my question is, is there any reason why it makes so much sense to print the identityHash of a CompiledMethod ? I use it to see if a method has been recompiled. (if it is different to the one before). Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

[Pharo-project] [update 1.4] #14248
by Marcus Denker Dec. 7, 2011

Dec. 7, 2011

14248 ----- Issue 5066: Sync VM version from image side http://code.google.com/p/pharo/issues/detail?id=5066 Issue 5065: [ENH]: Clean up Mail code (Part 2) http://code.google.com/p/pharo/issues/detail?id=5065 Issue 4994: Two failing test in ProcessTest http://code.google.com/p/pharo/issues/detail?id=4994 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Squeak/Pharo in Fedora
by Pavel Krivanek Dec. 6, 2011

Dec. 6, 2011

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

5 16

[Pharo-project] issue 5048 broke Pharo Kernel
by Pavel Krivanek Dec. 6, 2011

Dec. 6, 2011

Hi, the issue http://code.google.com/p/pharo/issues/detail?id=5048 broke Pharo-Kernel build on CI server. -- Pavel

2 4

Dec. 6, 2011

Hi guys we got rid of preferences as a ugly facade and now we have UITheme and UIManager. I would like to understand how we can skin widgets while be as loosely coupled as possible. May be a UI builder is missingâ¦. I was looking at SystemProgressMorph we setDefaultParameters self theme setSystemProgressMorphDefaultParameters: self updateColor "update the apareance of aMorph" self theme preferGradientFill ifFalse: [^ self]. self fillStyle: (self theme progressFillStyleFor: self) and SystemProgressBarMorph has initialize "Initialize the receiver from the current theme." super initialize. barSize := 0. self fillStyle: ( self theme progressBarFillStyleFor: self); borderStyle: (self theme progressBarBorderStyleFor: self); barFillStyle: ( self theme progressBarProgressFillStyleFor: self) extent: aPoint "Update the bar fillStyle if appropriate." super extent: aPoint. self fillStyle isOrientedFill ifTrue: [ self fillStyle: (self theme progressBarFillStyleFor: self)]. self barFillStyle isOrientedFill ifTrue: [ self barFillStyle: ( self theme progressBarProgressFillStyleFor: self)] So to help me understanding the problem, I thought about the flow of things. I would really to avoid to have - widgets construction code in UITheme and UImanager (ref to debugger UI as mentioned by henryk) - UITheme invocation inside the widgets. May be a widget should have its own state and when we build it the class creation only push the info from the UITheme to the widgets What do you think? Stef

1 0

Re: [Pharo-project] could you test the attached?
by Marcus Denker Dec. 6, 2011

Dec. 6, 2011

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. 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

3 5