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

Re: [Pharo-dev] SqNumberParser and PGConnection in Pharo 3

by Sven Van Caekenberghe

On 30 Aug 2014, at 01:40, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > It could be #stable, I just was afraid of breaking somebody else > stuff. I'm a champion at f*king up third parties repositories. :) I'll take the risk for you then: === Name: ConfigurationOfPostgresV2-SvenVanCaekenberghe.11 Author: SvenVanCaekenberghe Time: 31 August 2014, 12:04:35.32701 pm UUID: eaf9ae38-654b-43c9-8312-2a3ce8d1d26d Ancestors: ConfigurationOfPostgresV2-EstebanMaringolo.10 Updated #stable to version 2.3 to ensure pharo 3 compatibility === > Regards! > > Esteban A. Maringolo > > ps: There is also other versions of GLORP I didn't bless as #stable. That seems a bit more complicated: the Glorp ancestry is mixed up, we should merge this carefully: you made versions 86 & 87 while those already existed, the latest 88 skips your version. in any case, 88 now works for me, but I fear it skips your code Sven

Aug. 31, 2014

Re: [Pharo-dev] Please add me to the PharoExtras team

by Sven Van Caekenberghe

Thank you. On 31 Aug 2014, at 12:20, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > done > > On 31 Aug 2014, at 12:09, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Can somebody please add me to the PharoExtras team ? >> >> http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe >> >> > >

Aug. 31, 2014

Re: [Pharo-dev] Please add me to the PharoExtras team

by Esteban Lorenzano

done On 31 Aug 2014, at 12:09, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Can somebody please add me to the PharoExtras team ? > > http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe > >

Aug. 31, 2014

Please add me to the PharoExtras team

by Sven Van Caekenberghe

Can somebody please add me to the PharoExtras team ? http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe

Aug. 31, 2014

Re: [Pharo-dev] about to integrate GTools, there is a command conflict who needs attention

by Tim Mackinnon

Anything that starts to rationalise keystrokes is definitely appreciated. Particularly with thought to similar operations using the same keystrokes in different browsers. While it's taken some effort to get used to the newer multi-key shortcuts, the fact that it allows more more-reasonably grouped keys is a win. I really want more keystrokes for refactorings and other code operations - that multi-keys makes room for. So please keep pushing on this. Tim Sent from my iPhone > On 29 Aug 2014, at 07:30 pm, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Cmd+o cannot be mapped on Cmd+s because when you are in the code editor of the inspector, you want to both be able to accept the code and open the result of a selection. > > In the moose image we remove the global bindings altogether, so I would be certainly fine with rebinding them. That is until we find a better solution :) > > Cheers, > Doru > > >> On Fri, Aug 29, 2014 at 10:54 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi guys, >> >> We are on our way to integrate (finally) GTools into Pharo. >> For now it will be the Playground and the Inspector, since the Debugger is still not ready. >> >> Now, Iâm facing a problem. The new command for playground (cmd+o) conflicts with some menyu commands: (cmd+o+[w|t|etc]). Since we cannot handle both, we need to choose one. >> I do not have a clear idea, so I want your opinions. >> So far, I think this: >> >> 1) cmd+o in playground is not so clear, maybe we could map thet to an âacceptâ (cmd+s) or an âexecureâ (cmd+e)â¦ >> 2) we could map cmd+o+etc. to something else. But I do not know to what. >> >> So, I hear opinions :) >> >> Esteban > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 31, 2014

Re: [Pharo-dev] Future of Spec

by Martin Saurer

It's already planned ;-) Martin > as far as I understand J is an APL like language so I was wondering > with you do not have J binding inside pharo :) ? > and script J from there? > > Stef

Aug. 31, 2014

Re: [Pharo-dev] background color text attribute?

by stepharo

hi doru do you mean like when we select the code? Stef On 28/8/14 07:00, Tudor Girba wrote: > Hi, > > Does any of you know if there is a way to add a background color to a > piece of text? > > Cheers, > Doru > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Aug. 30, 2014

Re: [Pharo-dev] Anonymous classes in Pharo 3 - must be instances of Class, not Behavior

by stepharo

On 29/8/14 14:01, Camille Teruel wrote: > On 29 aoÃ»t 2014, at 13:38, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: > >> Following up: >> >> Behavior new compile: 't ^ trueâ >> >> fails since #compile: is defined in TBehavior and depends on #basicLocalSelectors which is defined only in Class, MetaClass and TraitBehavior. >> >> It seems like #basicLocalSelectors should be abstract in TBehavior. >> Alternatively the implementation should be moved to TBehavior and the field localSelectors should be pushed up to Behavior. Am I missing something? > You're right, it should be possible to compile methods into an instance of behavior. > IIRW, it was possible in Pharo 2 but we didn't pay enough attention to ensure that it is always possible. So if we can make it work again we should add your test somewhere for that. > About moving localSelectors to Behavior: I'm not sure that Behavior should be aware of traits. I prefer to keep Behavior minimal (it is already too messy IMO). Yes I agree too. > Also for Pharo 4 there is other issues introduced by the integration of slots (slots are now needed by Opal for compilation): > - we should move slot API to Behavior > - make sure that iv and format ivs are consistent with each other > So there is some work to be done to make it work again... :) > >> Oscar >> >> On 29 Aug 2014, at 12:26 , Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: >> >>> Hi folks, >>> >>> I was updating my lecture on Reflection for the Software Design and Evolution course, and I see now that anonymous classes can no longer be instances of Behavior but must be instances of Class. If you try to compile a method on an instance of Behavior, it fails. (basicLocalSelectors is not understood) >>> >>> Am I missing something? >>> >>> Cheers, >>> Oscar >>> >>> testPrimitiveChangeClassTo >>> | anonClass browser | >>> >>> anonClass := Class new. âmust be Class, not Behavior" >>> anonClass superclass: Browser. >>> anonClass setFormat: Browser format. >>> >>> browser := Browser new. >>> browser primitiveChangeClassTo: anonClass new. >>> anonClass compile: 'thisIsATest ^ 2'. >>> >>> self assert: browser thisIsATest = 2. >>> self should: [Browser new thisIsATest] >>> raise: MessageNotUnderstood. >>> >>> >> > >

Aug. 30, 2014

Re: [Pharo-dev] >>#next: SocketStream and other oddities

by Sven Van Caekenberghe

Holger, You are right and wrong ;-) SocketStream is what it is, it is far from perfect, but it works and had been working for a very long time. There are alternatives. The well documented contract of SocketStream #next: and all its variants up to #readInto:startingAt:count: states and explains the behaviour you describe. In other words, it is by design. I don't think these calls can return nil though. That is a behaviour of #next (also far from perfect). The semantics of SocketStream are not completely identical to ReadStream in general, because so much more can go wrong. Working with an explicit EOF exception is another design approach that has pros and cons as well. An alternative is Xtreams, which can be loaded into Pharo. Here, the API is much cleaner. Sven On 30 Aug 2014, at 11:04, Ben Coman <btc(a)openInWorld.com> wrote: > > I'm not an expert on networking stuff, but I'll try (and if I'm wrong I'll learn something new)... > > Holger Hans Peter Freyther wrote: >> >> Classic ReadStream in Pharo3.0 >> >> #[] readStream next: 2 => #[] >> >> >> SocketStream: >> >> 1.) Start something that listens to 12345 >> $ nc -l -p 12345 >> >> 2.) In Pharo do >> >> | conn | >> conn := (SocketStream openConnectionToHostNamed: 'localhost' port: 12345) >> binary; >> noTimeout; >> yourself. >> [ >> (conn next: 4) inspect. >> ] on: ConnectionClosed do: [:e | "Never called" self halt ]. >> >> 3.) CTRL+C the netcat process.. >> 4.) In Pharo an inspector on an ByteArray is coming up. The >> ConnectionClosed signal is raised but swallowed by the >> SocketStream code. >> >> >> >> >> I don't know how realistic it is but I would appreciate if >> >> 1.) #[] readStream next: 4. Could raise an Error that one can >> not consume four bytes/elements. >> > > Making it an Error seems a somewhat fundamental change that could break other people's code. Would a Notification be sufficient? >> 2.) I understand that not raising "ConnectionClosed" is to allow >> a partial read from the socket. What is done in GNU Smalltalk is >> to at least signal an EndOfStream notificaton. So the socket code >> could read like: >> > > Are you implying that in the same situation GNU Smalltalk similarly does not raise ConnectionClosed, but raises EndOfStream instead? EndOfStream as a Notification seems a low impact addition that would be generally useful. Can you determine the code changes required for SocketStream? The fastest way to get what you need is to open a ticket at pharo.fogbugz.com, then also supply the required code** as a slice :). This will provide something concrete to review. > **Including tests, one test that catches your new Notification, and then a duplicate of that test that does not catch the Notification, which works the same before and after slice is applied. > > cheers -ben >> >> | conn | >> conn := (SocketStream openConnectionToHostNamed: 'localhost' port: 12345) >> binary; >> noTimeout; >> yourself. >> [ >> (conn next: 4) inspect. >> ] on: EndOfStream do: [:e | self handleClosing ]. >> >> >> >> >> is this more clear? >> >> holger >> >> >> > >

Aug. 30, 2014

Re: [Pharo-dev] >>#next: SocketStream and other oddities

by Ben Coman

I'm not an expert on networking stuff, but I'll try (and if I'm wrong I'll learn something new)... Holger Hans Peter Freyther wrote: > > Classic ReadStream in Pharo3.0 > > #[] readStream next: 2 => #[] > > > SocketStream: > > 1.) Start something that listens to 12345 > $ nc -l -p 12345 > > 2.) In Pharo do > > | conn | > conn := (SocketStream openConnectionToHostNamed: 'localhost' port: 12345) > binary; > noTimeout; > yourself. > [ > (conn next: 4) inspect. > ] on: ConnectionClosed do: [:e | "Never called" self halt ]. > > 3.) CTRL+C the netcat process.. > 4.) In Pharo an inspector on an ByteArray is coming up. The > ConnectionClosed signal is raised but swallowed by the > SocketStream code. > > > > > I don't know how realistic it is but I would appreciate if > > 1.) #[] readStream next: 4. Could raise an Error that one can > not consume four bytes/elements. > Making it an Error seems a somewhat fundamental change that could break other people's code. Would a Notification be sufficient? > 2.) I understand that not raising "ConnectionClosed" is to allow > a partial read from the socket. What is done in GNU Smalltalk is > to at least signal an EndOfStream notificaton. So the socket code > could read like: > Are you implying that in the same situation GNU Smalltalk similarly does not raise ConnectionClosed, but raises EndOfStream instead? EndOfStream as a Notification seems a low impact addition that would be generally useful. Can you determine the code changes required for SocketStream? The fastest way to get what you need is to open a ticket at pharo.fogbugz.com, then also supply the required code** as a slice :). This will provide something concrete to review. **Including tests, one test that catches your new Notification, and then a duplicate of that test that does not catch the Notification, which works the same before and after slice is applied. cheers -ben > > | conn | > conn := (SocketStream openConnectionToHostNamed: 'localhost' port: 12345) > binary; > noTimeout; > yourself. > [ > (conn next: 4) inspect. > ] on: EndOfStream do: [:e | self handleClosing ]. > > > > > is this more clear? > > holger > > >

Aug. 30, 2014