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

[Pharo-project] How to manage removed classes, ScriptLoader and Undeclared ?
by Mariano Martinez Peck May 14, 2011

May 14, 2011

Hi guys. It seems when a class is removed, and used by ScriptLoader, it goes to Undeclared, logically. Example: SMxHandMorph was removed. However, ScriptLoader >> update13143 did something with such class. So, now, it is in Undeclared. How can we correctly solve this kind of problem? 1) Always use "Smalltalk at:" and #perform: in ScriptLoader updates? 2) remove those #update methods ? 3) Fix the broken ones by Smalltalk at: a and #perform: ? Thanks -- Mariano http://marianopeck.wordpress.com

2 2

[Pharo-project] Monticello can't load a simple project in PharoCore1.2 or 1.3
by Damien Cassou May 14, 2011

May 14, 2011

http://code.google.com/p/pharo/issues/detail?id=4229 Try to execute the following in a PharoCore: Gofer new url: 'http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/SwaUtilities'; package: 'Animations'; load (you don't need Gofer, you can also use the MC browser directly). It looks like Monticello manages to install the package correctly, but then the image is frozen and CPU runs hot. The problem appears in MCPackageLoader>>basicload between the following 2 lines: methodAdditions do: [:each | each installMethod]. methodAdditions do: [:each | each notifyObservers]. And when I say between, I really mean between. The line execute just fine, but then the CPU runs hot and image freezes. What do you think? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

2 2

[Pharo-project] Need help with 1.3 Full Image
by Marcus Denker May 14, 2011

May 14, 2011

Hi, In the past, the build of the Full/Dev image was broken most of the time, leading to bugs being discovered late, bugs not fixed while everyone is using the system and getting bitten by them... Now the Dev/Full image exactly is a such a thing that has no bottleneck: it's just some load scripts loading third party tools/libs. Just editing scripts and bug the maintainers. Nothing else to do. So it should be fixed far faster and much easier than Core, as it can be done in parallel? Right? Right? Wrong. The only person doing anyting is Mariano... (and me, I fixed 1.2 Full after is was broken an *astonishing* 23 *days* !!!!) I personally think this really wants to tell us something, but that's just me. So what we need is people who look at this list: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3-DevImage And *fix* the issues. Fast. I can not. Really not. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

7 12

[Pharo-project] [update 1.3] #13199
by Marcus Denker May 14, 2011

May 14, 2011

13199 ----- Issue 4165: Failing Tests: DecompilerTests Issue 4223: Not all test packages are being unload in #cleanUpForProduction Issue 4202: Collections-Atomic-Tests --> CollectionTests-Atomic Issue 4170: AbstractTool references non-existing DialogGroupAdder Issue 4216: ThreadsafeTranscript hat undeclared Reference Issue 4220: Remove #dropSourcePointer from Objects as methods -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] How to manage removed classes, ScriptLoader and Undeclared ?
by Marcus Denker May 14, 2011

May 14, 2011

On May 14, 2011, at 4:07 PM, Mariano Martinez Peck wrote: > Hi guys. It seems when a class is removed, and used by ScriptLoader, it goes to Undeclared, logically. > Example: SMxHandMorph was removed. However, ScriptLoader >> update13143 did something with such class. So, now, it is in Undeclared. > How can we correctly solve this kind of problem? > > 1) Always use "Smalltalk at:" and #perform: in ScriptLoader updates? > 2) remove those #update methods ? > 3) Fix the broken ones by Smalltalk at: a and #perform: ? > I just comment them, as the code in scriptloader is just for reference. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Funky BalloonMorph
by Hilaire Fernandes May 14, 2011

May 14, 2011

The balloon morph color and layout mess really give a bad bad feeling, I gave a look to try to fix it: * COLOR, it seems to be just an initialize issue, one should execute this in the image: BalloonMorph setBalloonColorTo: BalloonMorph defaultBalloonColor. * FONT, same problem, one should execute in the image : BalloonMorph balloonFont: StandardFonts defaultFont. * LAYOUT, the problem comes from the method String>>withNoLineLongerThan: doing very badly its job. Moreover this method need to be refactored to be readable, it is too looooong. Jannick can you give a try, you seem to be the author? Hilaire

3 8

[Pharo-project] RMLL anyone?
by Hilaire Fernandes May 14, 2011

May 14, 2011

I will be there at Strasbourg from 9 to 14 of Jully - http://www.rmll.info Any Pharoer is joining? Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

2 4

[Pharo-project] We are still small, don't worry
by Mariano Martinez Peck May 14, 2011

May 14, 2011

Taking the latest PharoCore 1.3 and doing "ScriptLoader new cleanUpForProduction" (mostly cleanUps and tests removal ) Gives me a 6.9 MB image. So we are quite good. Cheers -- Mariano http://marianopeck.wordpress.com

2 1

Re: [Pharo-project] Help "migrating" from classic streams to XStreams
by mkobetic＠gmail.com May 13, 2011

May 13, 2011

"Mariano Martinez Peck"<marianopeck(a)gmail.com> wrote: > Hi guys. We are developing Fuel with Martin Dias. Fuel is a binary > serializer similar to Parcels. More info in > http://rmod.lille.inria.fr/web/pier/software/Fuel > > For the moment, we are using the "classic" streams we want to give it a try > to XStreams. My knowledge on streams is very little, so if someone can give > me a hint I would really appreciate it. > What I want to do right now is an adaptor of XStreams to classic stream. I > mean, I want to create custom subclasses of XTFileWriteStream and > XTFileReadStream that implements the same API from classic streams that we > use in Fuel. And the implementations of such methods will do just a "self > something" where something is the way of doing that in XStreams. I'd also recommend generic wrapper for any kind of Xtream rather than subclassing specific terminal. In VW the usual way to create the classic streams is via #readStream or #writeStream, so I'd add something like: XTReadStream>>readStream ^XTClassicReadStream on: self XTWriteStream>>writeStream ^XTClassicWriteStream on: self The "classic" guys would then implement the classic API by invoking Xtreams API on their source/destination. You can even subclass those from the classic ReadStream and WriteStream to possibly inherit some behavior and only implement some core part of the protocol. > So, the following is the protocol we use in Fuel for streams, and what I > would love to know is the associated way to do it it XStreams. The left is > classic streams, and after the "->" it is XStreams: > > *Reading:* > > nextNumber: -> ?? > nextPutAll: -> write: > nextStringPut: -> ?? > nextPut: -> put: > nextNumber:put: -> ?? > nextWordPut: -> ?? > > *Writing: > * > nextNumber: -> ?? > next: -> read: It's not as simple, there can be subtle differences. For example in VW it should be something like: next: anInteger ^[ source read: anInteger ] on: Incomplete do: [ :incomplete | IncompleteNextCountError new parameter: incomplete count; raiseRequest ] > nextString -> ?? > next -> get Again, in VW it would be more like: get ^[ source get ] on: Incomplete do: [ :incomplete | EndOfStreamNotification raiseRequest ] > nextWord -> ?? For the specialized element types (Number, String) you can pretty much copy the classic implementations (or even inherit them). Alternatively they seem to fall into a category that we call "interpreting" in Xtreams. What we have is primarily focused on interpreting bytes as various C-types (short, long, float, double,....) for which we have convenient primitives in VW, but the concept can certainly be extended further (the interpretation definitions are pluggable). Unfortunately this part wasn't ported yet from VW. For quick overview you can peek at the end of http://code.google.com/p/xtreams/wiki/Transforms. There's also general marshaling stream available on VW side (built on top of the interpreting streams) which might be helpful example of how one can approach this type of problem with Xtreams. HTH, Martin

1 0

Re: [Pharo-project] Adding "Extended Search" to OB context menu
by Lukas Renggli May 13, 2011

May 13, 2011

Sure, that can be done. The point is that the RB code menu is fully implemented in OB now. Previously OB just used the menu provided by Pharo, what caused all kinds of problems. "Method source with it" was never an operation backed by OB. Lukas On 9 May 2011 11:46, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi Lukas, > > do you think it would be possible to use what is currently selected in > the code pane to set the default value of the 'Refactor -> Search > code' window? > > > ---------- Forwarded message ---------- > From: Mariano Martinez Peck <marianopeck(a)gmail.com> > Date: Mon, May 9, 2011 at 10:56 AM > Subject: Re: [Pharo-project] Adding "Extended Search" to OB context menu > To: Pharo-project(a)lists.gforge.inria.fr > > >> Have you tried 'Refactor -> Search code' ? > > Thanks Damien. But that's something completely different. What I want > to do is to select text, right button, method source with it. That's > all. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > -- Lukas Renggli www.lukas-renggli.ch

2 3