February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [FIX (Maybe ; ))]: Issue 14959: MC Hook for Default Credentials

by Thierry Goubier

2015-02-19 11:28 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 19 Feb 2015, at 11:20, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > .... > > Yes! I want an end to that big switch ! > > > > (I had to write an override to that to get gitfiletree:// urls to work, > as well as two or three other spots in Zn where known url protocols are > hardcoded). > > Yes, you told me that at the Pharo Days, maybe you could show me what you > had to override and what was bothering you ? > Hum: The overrides I have are: ZnUrl class>>defaultPortForScheme: (I think it appears on error paths through Zn) ZnUrl>>McRepositoryAsUser:withPassword: (Where things missing would also be the github:// and the bibucket:// urls... I believe you can't use them via Gofer because of that). and ZnUrl>>asFileReference (Where there is an assert). I believe ZnUrl>>enforceKnownScheme is also problematic. I just searched through all ZnURL methods containing #http :) Thierry

Feb. 19, 2015

Re: [Pharo-dev] Athens/Morphic

by Nicolai Hess

Most of this (without the test class (AthensTestDisplay)) is now ready for integration. A lot of changes for making Mophic and Text(Morphs) work on Athens (For testing purpose there is also the AthensWrapWorldMorph included). The Canvas wrapper (AthensCanvasWrapper) is not yet included and therefore all Morphs that do not explicit have a proper drawOnAthensCanvas method arent't drawn (or just like rectangles). Should work with any image >= 40490 Just load the latest ConfigurationOfAthens from pharo 40 inbox and load ConfigurationOfAthens loadVersion:'2.9' If this is working (or not:) ) please leave a note on fogbugz: "14954 load new configuration 2.9 (more morphic support)" nicolai 2015-01-31 11:54 GMT+01:00 Alain Plantec <alain.plantec(a)yahoo.com>: > > > Yes the HandMorph is handled like any other Morph, it draws itself and > after that it draws all its submorphs. (And actually it does not use any > caching, and it is still quite fast) > > > the same in Bloc, no caching and it works just fine :) > > But yes, it needs a special drawOnAthens method. > > >> Do you plane to make a package for it ? >> I would like to integrate it in Bloc. >> > > What would like to integrate? > > In fact I do not see any change when in Bloc. > So I guess I will have to adapt Bloc to your changes. > > I will upload the changes in Athens-Morphic package to > the Athens repository. > > > cool. > > thanks > > Alain >

Feb. 19, 2015

Re: [Pharo-dev] something else than a stupi timestamp in pane of the glamour workspace.... please

by Esteban Lorenzano

> On 19 Feb 2015, at 11:47, Norbert Hartl <norbert(a)hartl.name> wrote: > > If there is only one pane there shouldn't be a tab header at all. +1 > > Norbert > >> Am 18.02.2015 um 20:52 schrieb stepharo <stepharo(a)free.fr>: >> >> something else than a stupi timestamp in pane of the glamour workspace.... please >> please please please. >> It gives this impression that pharo is not finished at all. >> >> > >

Feb. 19, 2015

Re: [Pharo-dev] something else than a stupi timestamp in pane of the glamour workspace.... please

by Sven Van Caekenberghe

I think the idea is that each workspace, even each snapshot of it, is uniquely identified. The question remains if the label and the identifier have to be the same. > On 19 Feb 2015, at 11:47, Norbert Hartl <norbert(a)hartl.name> wrote: > > If there is only one pane there shouldn't be a tab header at all. > > Norbert > >> Am 18.02.2015 um 20:52 schrieb stepharo <stepharo(a)free.fr>: >> >> something else than a stupi timestamp in pane of the glamour workspace.... please >> please please please. >> It gives this impression that pharo is not finished at all. >> >> > >

Feb. 19, 2015

Re: [Pharo-dev] something else than a stupi timestamp in pane of the glamour workspace.... please

by Norbert Hartl

If there is only one pane there shouldn't be a tab header at all. Norbert > Am 18.02.2015 um 20:52 schrieb stepharo <stepharo(a)free.fr>: > > something else than a stupi timestamp in pane of the glamour workspace.... please > please please please. > It gives this impression that pharo is not finished at all. > >

Feb. 19, 2015

Re: [Pharo-dev] [FIX (Maybe ; ))]: Issue 14959: MC Hook for Default Credentials

by Sven Van Caekenberghe

> On 19 Feb 2015, at 11:20, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-02-19 11:11 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 19 Feb 2015, at 03:15, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > Fix in inbox: > > SLICE-Issue-14959-MC-Hook-for-Default-Credentials-SeanDeNigris.1 > > > > When creating a repo in the MC Browser, it would be great to pre-populate > > the user and password fields. > > > > Thus, we declare a CredentialSource role collaborating with MCHttpRepository > > and subclasses. The in-kernel default is a no-op Null object, but users can > > install (via MCHttpRepository class>>#credentialSource:) any object that > > responds to #defaultUserFor: and #defaultPasswordFor: > > > > I'd like to apply this to Gofer, too, but I found a big switch statement in > > ZnUrl>>#mcRepositoryAsUser:withPassword: and now my head hurts ;) > > Yes, that is not good (ahem). > > We should let the root, MCRepository, decide, probably doing a lookup through its subclasses. All subclasses should also uniformly take credentials. > > Yes! I want an end to that big switch ! > > (I had to write an override to that to get gitfiletree:// urls to work, as well as two or three other spots in Zn where known url protocols are hardcoded). Yes, you told me that at the Pharo Days, maybe you could show me what you had to override and what was bothering you ? > Thierry > > > > Anyway maybe this will spur discussion... > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials… > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > >

Feb. 19, 2015

Re: [Pharo-dev] something else than a stupi timestamp in pane of the glamour workspace.... please

by Piotr Klibert

+1 for this. The timestamp is ugly and not very readable. Actually, one of the first things I did with my image was to change GTPlayPage>>initialize to something like: initialize content := ''. title := String streamContents: [ :s | DateAndTime now printHMSOn: s. ] but 'Pane 1', 'Pane 2' etc. would work too. Best regards, Piotr Klibert 2015-02-19 9:11 GMT+01:00 stepharo <stepharo(a)free.fr>: > Do > I put 'Pane 1' instead of this timestamp and it took me around 15 s to do > it. > So I guess that this is possible to propose a simple fix, isn't > > Stef > > Le 18/2/15 21:27, Tudor Girba a Ã©crit : > > That's because this part is not finished :). It should come, hopefully > before the feature freeze. Otherwise, we can treat it as a bug :D > > Doru > > On Wed, Feb 18, 2015 at 8:52 PM, stepharo <stepharo(a)free.fr> wrote: > >> something else than a stupi timestamp in pane of the glamour >> workspace.... please >> please please please. >> It gives this impression that pharo is not finished at all. >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > >

Feb. 19, 2015

Re: [Pharo-dev] [FIX (Maybe ; ))]: Issue 14959: MC Hook for Default Credentials

by Thierry Goubier

2015-02-19 11:11 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 19 Feb 2015, at 03:15, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > > > Fix in inbox: > > SLICE-Issue-14959-MC-Hook-for-Default-Credentials-SeanDeNigris.1 > > > > When creating a repo in the MC Browser, it would be great to pre-populate > > the user and password fields. > > > > Thus, we declare a CredentialSource role collaborating with > MCHttpRepository > > and subclasses. The in-kernel default is a no-op Null object, but users > can > > install (via MCHttpRepository class>>#credentialSource:) any object that > > responds to #defaultUserFor: and #defaultPasswordFor: > > > > I'd like to apply this to Gofer, too, but I found a big switch statement > in > > ZnUrl>>#mcRepositoryAsUser:withPassword: and now my head hurts ;) > > Yes, that is not good (ahem). > > We should let the root, MCRepository, decide, probably doing a lookup > through its subclasses. All subclasses should also uniformly take > credentials. > Yes! I want an end to that big switch ! (I had to write an override to that to get gitfiletree:// urls to work, as well as two or three other spots in Zn where known url protocols are hardcoded). Thierry > > > Anyway maybe this will spur discussion... > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials… > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > >

Feb. 19, 2015

Re: [Pharo-dev] [FIX (Maybe ; ))]: Issue 14959: MC Hook for Default Credentials

by Sven Van Caekenberghe

> On 19 Feb 2015, at 03:15, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Fix in inbox: > SLICE-Issue-14959-MC-Hook-for-Default-Credentials-SeanDeNigris.1 > > When creating a repo in the MC Browser, it would be great to pre-populate > the user and password fields. > > Thus, we declare a CredentialSource role collaborating with MCHttpRepository > and subclasses. The in-kernel default is a no-op Null object, but users can > install (via MCHttpRepository class>>#credentialSource:) any object that > responds to #defaultUserFor: and #defaultPasswordFor: > > I'd like to apply this to Gofer, too, but I found a big switch statement in > ZnUrl>>#mcRepositoryAsUser:withPassword: and now my head hurts ;) Yes, that is not good (ahem). We should let the root, MCRepository, decide, probably doing a lookup through its subclasses. All subclasses should also uniformly take credentials. > Anyway maybe this will spur discussion... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 19, 2015

Re: [Pharo-dev] [Slots] Invisible Slots

by Marcus Denker

> > -> generate better byte code, the reflective read is of course slow. this is easy. What we need to do is to override #emitValue: and #emitStore: emitValue: methodBuilder methodBuilder pushInstVar: baseSlot index; pushLiteral: self name; pushLiteral: nil; send: #at:ifAbsent: for storing, the problem is that the value to be saved is on top of the stack. so we need to first save it and pop it off to be able to use #at:put:: emitStore: methodBuilder | tempName | tempName := ('0generated_',self name) asSymbol. methodBuilder addTemp: tempName; storeTemp: tempName; popTop; pushInstVar: baseSlot index; pushLiteral: self name; pushTemp: tempName; send: #at:put: if we do that and recompile the accessors, we get: [(TT new tt: 1) tt] bench none: "'408,000 per second.'" + bc for write slot: "'455,000 per second.'" + bc for read: "'487,000 per second.'" (most of the time is spend in dictionary access, of course) Marcus

Feb. 19, 2015