January 2014 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 37b358: 30679
by GitHub Jan. 8, 2014

Jan. 8, 2014

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 37b3585f618c111f88707fbd578c5b8085b5ff68 https://github.com/pharo-project/pharo-core/commit/37b3585f618c111f88707fbd… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-08 (Wed, 08 Jan 2014) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script332.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30679.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Zinc-Zodiac.package/ZnHTTPSTests.class/instance/private/runningOnWindowsInriaCI.st M Zinc-Zodiac.package/ZnHTTPSTests.class/instance/testing/testGetPharoVersion.st Log Message: ----------- 30679 12377 ZnHTTPSTests.>>testGetPharoVersion fails on Windows slave https://pharo.fogbugz.com/f/cases/12377 http://files.pharo.org/image/30/30679.zip

2 1

[pharo-project/pharo-core]
by GitHub Jan. 8, 2014

Jan. 8, 2014

Branch: refs/tags/30679 Home: https://github.com/pharo-project/pharo-core

1 0

Update Log Messages
by Sean P. DeNigris Jan. 8, 2014

Jan. 8, 2014

Is there an easy way to see the messages chronologically? i.e. for 30535, then 30536 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Update-Log-Messages-tp4735044.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

2 2

#runOnce: of StartupAction not working
by roberto.minelli＠usi.ch Jan. 8, 2014

Jan. 8, 2014

Hi, I am playing with StartupActionâs. I discovered that the #runOnce: message is apparently not working. Try to put this (https://dl.dropboxusercontent.com/u/6281855/pincopallino.st) StartupAction into ~/Library/Preferences/pharo and open an image. The first time the name is set as expected. Then, change the âPincoPallino' name in the pincopallino.st file to another name, save and open another time your image. I think it should change the name again, since #runOnce: is set to false. But it does not. Looking around seems that the StartupLoader handles the preferences in a Dictionary whose keys are names (BAD) and if there is a preference with the same name of an already executed one it does not re-execute even though #runOnce: false. I also put an entry in the tracker: https://pharo.fogbugz.com/f/cases/12594/runOnce-of-StartupAction-not-working Cheers, R

1 0

12538 Renaming an extension does not work
by Nicolai Hess Jan. 8, 2014

Jan. 8, 2014

I fail to see what does not work. Renaming Spec-Core to ValueHolders works. Even if ValueHolders isn't already there, it is created. The only thing I encountered, the ValueHolder entry wont' show up in the rename dialog, if - the Package doesn't exist (of course, thats ok) - the Package is empty ( but it still works). Or should we prevent to rename a category *XYZ if package XYZ doesn't exists? Nicolai

1 0

Anyone working with Komitter
by Nicolai Hess Jan. 8, 2014

Jan. 8, 2014

Anyone working with komitter on Windows? Or is it just me getting this (issue 12508<https://pharo.fogbugz.com/default.asp?12508>) ?

1 0

[pharo-project/pharo-core]
by GitHub Jan. 8, 2014

Jan. 8, 2014

Branch: refs/tags/30678 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] 0f1725: 30678
by GitHub Jan. 8, 2014

Jan. 8, 2014

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 0f172572174ff143319c4f74f5211c65a2bba461 https://github.com/pharo-project/pharo-core/commit/0f172572174ff143319c4f74… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-08 (Wed, 08 Jan 2014) Changed paths: A Kernel.package/DateAndTime.class/class/instance creation/fromMethodTimeStamp_.st R Kernel.package/TimeStamp.class/class/instance creation/fromMethodTimeStamp_.st M Monticello.package/MCDefinition.class/instance/comparing/fullTimeStamp.st M Monticello.package/MCMethodDefinition.class/instance/accessing/fullTimeStamp.st M Monticello.package/MCVersionInfo.class/instance/accessing/timeStamp.st M RecentSubmissions.package/MessageList.class/instance/actions/addFirstVersion.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script331.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30678.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Changes.package/ChangeRecord.class/instance/access/timeStamp.st M Text-Scanning.package/BitBltDisplayScanner.class/instance/displaying/displayEmbeddedForm_.st M Text-Scanning.package/DisplayScanner.class/instance/private/placeEmbeddedObject_.st Log Message: ----------- 30678 12494 Replace usage of TimeStamp with DateAndTime for methods stamps https://pharo.fogbugz.com/f/cases/12494 12592 Text Embedded Morphs Broken https://pharo.fogbugz.com/f/cases/12592 http://files.pharo.org/image/30/30678.zip

1 0

Re: [Pharo-dev] XMLParser Problem with SVG
by monty Jan. 8, 2014

Jan. 8, 2014

The problem with not fetching external DTDs/parsed entities is that they can contain entity declarations that affect the way the document is parsed. So your document is valid, but because it references &someEntity; which was declared in external.dtd, it will generate an error because external.dtd wasn't retrieved. But I am still considering what the best default behavior is. At a minimum I think the caching behavior (for HTTP) will become default. Old XML and code should still work, unless it references an external DTD or contains an internal subset it doesn't conform to. As for security, I already figured out how to secure the parser completely against every type of DoS attack (billion laughs, entity blowup, and so on) and will be adding that shorlty. I'm still considering what limits to impose on input. Right now there is already a three-deep limit on entity replacement. these limits will be configurable and removable. Â ----- Original Message ----- From: Igor Stasenko Sent: 01/06/14 11:25 AM To: Pharo Development List Subject: Re: [Pharo-dev] XMLParser Problem with SVG Hmm, my only question is about default behavior.Before it was not using/resolving any DTD links,and now it is... which means old code which was worked perfectly before, now will stop to function.So, maybe its worth to change the default behavior to be backwards compatible?Also, i'm not sure if it is good idea to go over a wire for an arbitrary content you can give to XMLDOMParser, imo this should be disabled by default, and instructed by user explicitly instead. Don't take me wrong: i really like that now we can handle DTD stuff properly, i'm only doubting current default way of handling it. Â On 6 January 2014 12:58, monty <monty.os(a)engineer.com> wrote:You can use the DTDCachingEntityResolver to cache responses: resolver := DTDCachingEntityResolver new. then: (XMLDOMParser onFileNamed: 'lion.svg') Â externalEntityResolver: resolver; Â parseDocument. or you could just disable validation and external entity resolution altogether: (XMLDOMParser onFileNamed: 'lion.svg') Â isValidating: false; Â resolvesExternalEntities: false; Â parseDocument. if you're parsing a string or stream (and you can always create your own file stream and give it that), you can do everything with just one message: XMLDOMParser Â parse: xmlStringOrStream Â usingNamespaces: true; Â validation: false; Â externalEntities: false. This is all in the documentation for SAXHandler.Â Â ----- Original Message ----- From: J.F. RickSent: 01/06/14 04:37 AM To: Pharo Development ListSubject: Re: [Pharo-dev] XMLParser Problem with SVG Â Monty, thanks. You are right that the latest version of XMLParser fixes the parsing problem. I think you just need to upload an updated configuration to the MetaRepoForPharo30 to fix this. And, yes, I would like to know how to turn DTD parsing off or for it to cache the DTD as it takes several seconds to retrieve the DTD for SVG and that gets annoying. Cheers, Jeff On Mon, Jan 6, 2014 at 10:18 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: On 06 Jan 2014, at 10:06, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 5 January 2014 15:19, J.F. Rick <self(a)je77.com> wrote:> I am trying to use SVG with Athens; however, the XMLParser for Pharo 3.0 cannot read normal SVG files that it used to. So, the demo of "ASVGMorph fromFile: 'lion.svg'" fails in the XMLParser (i.e., before ASVGMorph really does anything to it). It seems to download the DTD file from the Internet and then cannot properly parse it. Here is my setup: > > Up-to-date Pharo 3.0. Added XMLParser from the Configuration Browser. > Example file can be found here: http://www.thetangentbundle.net/w/images/f/ff/lion.svg > The following brings up an error: XMLDOMParser parseFileNamed: 'lion.svg' >> Hmm, why it tries to parse DTD file? It looks like something has changed in XMLDOMParser, because it wasn't before, and there is no support in SVG parser > for that. Â Yes, the parsing of DTDâd is new, Monthy added it recently. He says there is a way to turn it off. >> Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > > >> -- > Best regards, > Igor Stasenko. Â Â -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- Best regards, Igor Stasenko.

1 0

printString and asString
by Otto Behrens Jan. 8, 2014

Jan. 8, 2014

Hi, I've run into one of my favorite problems in Smalltalk and decided to try the list. Please don't shoot me on this one; perhaps you've run into it yourself. If there are discussions that I should read, please send me some info. My first assumption is that the difference between printString and asString is that printString may be more elaborate than asString, but often they are the same. Do you agree? 1. In Pharo, the default implementation of asString is ^ self printString. 2. printString normally calls self printOn: aStream. (Pharo and GemStone. Yay, consistency!) 3. In Pharo, the default printOn: writes the class name prefixed with 'a' or 'an'. 4. In GemStone, the default implementation of printOn: writes self asString to the stream. My second assumption is one should never override printString. Rather override printOn:. Agreed? In Pharo, we have very few classes that overrides printString. One problem area is UUID. It overrides asString, printOn: and printString, with a similar approach to GemStone in printOn:. In GemStone, there's a big heap of inconsistency. Character also overrides all 3 methods, with an apparent awful inconsistency there! In Pharo, I get infinite recursion when I override printOn: to call asString. I get infinite recursion problems in GemStone when I override asString and call printString. So with my strategy to develop in Pharo and deploy in GemStone, we have to be very careful. Most often, overriding printString and / or asString has to do with performance. If we have a simple object, we don't want to override printOn: that creates a stream, prints an instanceVariable (already a string) to it, and then throw away the stream. My suggestion is that we should get consistency. Decide on a way and follow that. To me, this makes sense: 1. Keep the default printString that calls printOn:. 2. Override asString to return a simple representation of the object, if you have one. Don't create streams in here, or go wild with string concatenations. Practically, many objects will return a simple string, which could be one instVar. 3. Override printOn: to return a representation concatenating parts of the object as strings. Use this if you want to print a more elaborate description than asString. 4. Change Object >> asString return 'a' or 'an', class name. 5. Change Object >> printOn: to write self asString to the stream. 6. Fix printString overrides (more work in GemStone than Pharo) 7. Normally use printString, but use asString where you are concerned about performance. In some cases, you may have a longer printString... Well, thanks for reading this far. Looking forward to your answers. Otto

9 29