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

Re: [Pharo-dev] Can we override == in Pharo ?

by Camille Teruel

On 6 janv. 2014, at 13:55, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 06 Jan 2014, at 13:43, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> So I tried and it worked. >> >> In Opal to remove the usage of #==, I removed it from the special selector array in the method: >> IRBytecodeGenerator class>>specialSelectorsArray >> ^ #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #== 1 nil 0 #blockCopy: 1 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) >> >> Then I ran: >> IRBytecodeGenerator initialize. >> OpalCompiler recompileAll. >> >> Then in my example: >> >> A>>== >> ^ true >> >> a := A new. >> b := A new. >> a == b answered true, so it worked. >> > > The only side effect it can have is that people might have written code with the knowledge that sending > #== can not lead to an interrupt check, e.g. a GC happening or process switching. Yes for example in #~~ > > Marcus

Jan. 6, 2014

Re: [Pharo-dev] Can we override == in Pharo ?

by Marcus Denker

On 06 Jan 2014, at 13:43, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > So I tried and it worked. > > In Opal to remove the usage of #==, I removed it from the special selector array in the method: > IRBytecodeGenerator class>>specialSelectorsArray > ^ #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #== 1 nil 0 #blockCopy: 1 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) > > Then I ran: > IRBytecodeGenerator initialize. > OpalCompiler recompileAll. > > Then in my example: > > A>>== > ^ true > > a := A new. > b := A new. > a == b answered true, so it worked. > The only side effect it can have is that people might have written code with the knowledge that sending #== can not lead to an interrupt check, e.g. a GC happening or process switching. Marcus

Jan. 6, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 0327dc: 30673

by Esteban Lorenzano

no cheating :) AsmJit-Tests are uncovering some weird behaviour that has to be fixedâ¦ but we cannot stop the stream in the mean time. but yesâ¦ it has to be fixed soon :) Esteban On 06 Jan 2014, at 13:46, Nicolai Hess <nicolaihess(a)web.de> wrote: > That's cheating :) > > > > 2014/1/6 Esteban Lorenzano <estebanlm(a)gmail.com> > green againâ¦ cool :) > > On 06 Jan 2014, at 10:54, GitHub <noreply(a)github.com> wrote: > > > Branch: refs/heads/3.0 > > Home: https://github.com/pharo-project/pharo-core > > Commit: 0327dcd90fc34d638a6286e0b14d64ecfa85a438 > > https://github.com/pharo-project/pharo-core/commit/0327dcd90fc34d638a6286e0… > > Author: Jenkins Build Server <board(a)pharo-project.org> > > Date: 2014-01-06 (Mon, 06 Jan 2014) > > > > Changed paths: > > A Komitter.package/extension/MCFileTreeRepository/instance/isRemote.st > > A Komitter.package/extension/MCFileTreeRepository/instance/koRemote.st > > A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script326.st > > A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30673.st > > M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > > > Log Message: > > ----------- > > 30673 > > removeMe > > > > http://files.pharo.org/image/30/30673.zip > > > > > > >

Jan. 6, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 0327dc: 30673

by Nicolai Hess

That's cheating :) 2014/1/6 Esteban Lorenzano <estebanlm(a)gmail.com> > green againâ¦ cool :) > > On 06 Jan 2014, at 10:54, GitHub <noreply(a)github.com> wrote: > > > Branch: refs/heads/3.0 > > Home: https://github.com/pharo-project/pharo-core > > Commit: 0327dcd90fc34d638a6286e0b14d64ecfa85a438 > > > https://github.com/pharo-project/pharo-core/commit/0327dcd90fc34d638a6286e0… > > Author: Jenkins Build Server <board(a)pharo-project.org> > > Date: 2014-01-06 (Mon, 06 Jan 2014) > > > > Changed paths: > > A Komitter.package/extension/MCFileTreeRepository/instance/isRemote.st > > A Komitter.package/extension/MCFileTreeRepository/instance/koRemote.st > > A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/ > script326.st > > A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/ > update30673.st > > M > ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > > > Log Message: > > ----------- > > 30673 > > removeMe > > > > http://files.pharo.org/image/30/30673.zip > > > > > > >

Jan. 6, 2014

Re: [Pharo-dev] Can we override == in Pharo ?

by ClÃ©ment Bera

So I tried and it worked. In Opal to remove the usage of #==, I removed it from the special selector array in the method: IRBytecodeGenerator class>>specialSelectorsArray ^ #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #== 1 nil 0 #blockCopy: 1 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) Then I ran: IRBytecodeGenerator initialize. OpalCompiler recompileAll. Then in my example: A>>== ^ true a := A new. b := A new. a == b answered true, so it worked. I don't like all these messages with no lookup. I don't even know if this permits to earn performance now that we have inline caches. @Frank Shearar Just a detail, #timesRepeat: is not inlined any more by default in Pharo 3.0 because there were conflicts with a stream library. Anyway it didn't provide a lot of performance (just removed 1 indirection). 2014/1/6 Frank Shearar <frank.shearar(a)gmail.com> > On 6 January 2014 11:11, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014/1/6 ClÃ©ment Bera <bera.clement(a)gmail.com> > >> > >> Hello, > >> > >> here I have a class > >> > >> A>>== > >> ^ true > >> > >> Now: > >> a := A new. > >> b := A new. > >> a == b "Answers false" > >> a perform: #== with: b "Answers true" > >> > >> Do I have to remove the usage of the byte code for #== in the compiler > to > >> be able to override == ? > >> > >> > > > > > > No, a==b should be used for "are the same Objects" (pointing to the same > > object) and not "are equal". > > Look for example at the commentn for ProtoObject>>== > > Given the kinds of things ClÃ©ment does, I suspect he knows full well > the difference between #== and #=. > > My understanding is that the compiler inlines #== sends like it does > with #timesRepeat: and ifTrue:ifFalse:. So yes, you'd need to fiddle > with the compiler for any #== overrides to actually run. > > (I'm keen for Marcus to show us how exactly to do that in Opal!) > > frank > > > Nicolai > >

Jan. 6, 2014

Re: [Pharo-dev] [Glass] printString and asString

by Esteban A. Maringolo

2014/1/6 Otto Behrens <otto(a)finworks.biz> > This brings back a question regarding displayString, or something > similar. It seems as if many people need something like this. > > I need for example a string representation of objects generally to > display in anchors in our seaside application. We have a class > DomainObject from which most of our classes inherit, so this is > probably the place to add a 'displayString' for something like this. Not necessarily domain objects only. Some core objects (Blocks, CompiledMethods, etc.) could benefit from having a developer string representation (#printString) and a UI string representation (#displayString). Regards, Esteban A. Maringolo

Jan. 6, 2014

Re: [Pharo-dev] Can we override == in Pharo ?

by Alexandre Bergel

You may need to do this if you are using proxies. Alexandre On Jan 6, 2014, at 8:52 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 6 January 2014 10:56, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello, > > here I have a class > > A>>== > ^ true > > Now: > a := A new. > b := A new. > a == b "Answers false" > a perform: #== with: b "Answers true" > > Do I have to remove the usage of the byte code for #== in the compiler to be able to override == ? > > > may i ask why you need to override it? > > > -- > Best regards, > Igor Stasenko. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 6, 2014

Re: [Pharo-dev] Can we override == in Pharo ?

by Camille Teruel

On 6 janv. 2014, at 10:56, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello, > > here I have a class > > A>>== > ^ true > > Now: > a := A new. > b := A new. > a == b "Answers false" > a perform: #== with: b "Answers true" > > Do I have to remove the usage of the byte code for #== in the compiler to be able to override == ? Yes you have to because there is no message sent, just pointer comparison.

Jan. 6, 2014

Re: [Pharo-dev] Spotlight Demo

by Tudor Girba

I do not have a diagram now, but it is really trivial. It's not more than I said in the blog post. Is it not explicit enough? Doru On Mon, Jan 6, 2014 at 10:59 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Doru > > do you have a sketch (UML) to see how it works? > Because indeed having a pattern for the theme is definitively important > and Iâm sad that the same trick > as the settings do not work for theme. > > Stef > > On 06 Jan 2014, at 00:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi again, > > I added a first shot at theming. The idea is simple: > - we have one method in UITheme called spotterThemer that simply returns a > SpotterThemer, and > - all Spotter/Spotlight specific rendering methods are in SpotterThemer > > I think this should be the design to follow for all morphs. I blogged > about it in more details here: > > http://www.humane-assessment.com/blog/a-pharo-refactoring-story-adding-them… > > > You can get the code from here: > Gofer new > smalltalkhubUser: 'girba' project: 'GPlay'; > package: 'Spotlight'; > disablePackageCache; > load > > In summary, something like: > > SpotlightItemMorph>>onSelected > self color: (Color r: 0.2627 g: 0.4588 b: 0.9333). > > becomes: > > SpotlightItemMorph>>onSelected > self theme spotterThemer configureSelectedItemMorph: self > > And the default SpotterThemer says: > > SpotterThemer>>configureSelectedItemMorph: aMorph > aMorph color: (Color r: 0.2627 g: 0.4588 b: 0.9333) > > > What do you think? > > Cheers, > Doru > > > > > On Sun, Jan 5, 2014 at 9:26 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi Sean, >> >> I just tested it. It works just great. >> >> First, would it be Ok with you to move the project to a more public place >> (like http://www.smalltalkhub.com/#!/~PharoExtras) so that others can >> contribute easier? >> >> Second, I created a configuration with a development and stable version. >> You can find it here: >> Gofer new >> smalltalkhubUser: 'girba' project: 'GPlay'; >> package: 'ConfigurationOfSpotter'; >> load. >> (Smalltalk globals at: #ConfigurationOfSpotter) >> loadStable >> >> And in the MetaRepoForPharo30 so that you can load it from the >> Configuration Browser. Please note that I named the configuration Spotter, >> because there already exists a ConfigurationOfSpotlight for the widget of >> Esteban. Would it be Ok to change the name of the classes, too, to avoid >> confusion? >> >> Third, I think we should not mix the morph with the global shortcut. I >> understand this is convenient, but these should pretty much be different >> projects. Is that Ok with you? >> >> Fourth, I would like to theme this morph, too :). With this occasion, I >> would like to try a slightly different design for handling the theme code. >> I will follow up on this in another mail. >> >> Doru >> >> >> On Sat, Jan 4, 2014 at 5:42 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: >> >>> I'm happy for now. As a general purpose completion option, I'd say we're >>> officially at version 1.0. No obvious bugs, and provides the basic >>> features >>> I'd want. >>> >>> As for replacing the existing Spotlight, I've decided to eat my own dog >>> food >>> and use the new tool in my images: >>> *** n.b., if you load the Spotlight package now, it will override the >>> global Spotlight shortcut >>> >>> p.s. Steph, I added packages to the example for you ;) â¦ >>> < >>> http://forum.world.st/file/n4734153/Screen_Shot_2014-01-04_at_11.18.57_AM.p… >>> > >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/Spotlight-Demo-tp4733076p4734153.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 6, 2014

Re: [Pharo-dev] XMLParser Problem with SVG

by monty

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. Rick Sent: 01/06/14 04:37 AM To: Pharo Development List Subject: 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

Jan. 6, 2014