- Pharo-dev - lists.pharo.org

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

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

by Holger Hans Peter Freyther

On Sat, Aug 30, 2014 at 09:19:49AM +0200, stepharo wrote: > Hi holger Hi! thanks for the answer. > I got confused. sorry about that. > There is a problem with next: not raising error? 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. 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: | 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] ObjectLiterals thoughts....

by stepharo

For now parsetime as #() > Are you considering a form of compile-time expression or quasi-quotes? > > On 29 August 2014 11:35, stepharo <stepharo(a)free.fr> wrote: >> Hi guys >> >> we are looking at STON and ObjectLiterals with Christophe and for handling >> metadata. >> >> >> And I was brainstorming.... I was wondering if it would be possible to have >> a bit more use of self evaluating >> >> for example >> 1@3 >> #k -> 2 instead of (Association #k 123) >> >> >> my brainstorming is how could we minimize new syntactic constructs and still >> support a literal object format. >> So object literal cover that so may be this is good. >> >> 1@3 as (Point 1 3) >> and >> #k -> 123 as (Association #k 123) >> >> So I'm not clear but this is interesting to think about it. >> I would like to have also a dictionary literal syntax.... but this another >> story. >> >> Stef >> >> PS: Sven I added support for Association into the ObjectLiteral project to >> see how it works. >> >> >> >> >> >> >> >> >> >> I took Igor's initial code and created a new project: >> >> http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals/ >> >> and I added ObjectLiteralParser to convert any Character Stream or String >> into a Smalltalk Literal Array and eventually into an Object. >> >> This proof of concept moves the ObjectLiteral format/notation away from the >> Smalltalk compiler and will help us discuss more concretely the actual >> details of the specification (which is still not 100% finished). >> >> I also added 12 unit tests and cleaned up the code and comments. >> >> Please have a look at the code. >> >> This is one of the tests: >> >> ObjectLiteralParserTests>>#testMixed1 >> | input output | >> input := ' >> #(Array >> 1 >> foo >> #''foo-#bar'' >> true >> false >> nil >> 3.14159 >> -100 >> ''string'' >> (#OrderedCollection 7 8 9) >> #(Set 10) >> (Dictionary >> x 1 >> y 2) ) '. >> output := { >> 1. >> #foo. >> #'foo-#bar'. >> true. >> false. >> nil. >> 3.14159. >> -100. >> 'string'. >> OrderedCollection withAll: #(7 8 9). >> Set with: 10. >> Dictionary newFromPairs: #(x 1 y 2 ). }. >> self assert: (self parserOn: input) nextObjectLiteral equals: output >> >> I like this format, its simplicity and elegance is appealing, it offers >> distinctive advantages in the Smalltalk context while its slight readability >> disadvantage is acceptable. Like any format it is a compromise and a >> tradeoff, but a rather good one. >> >> Regards, >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> > >

Aug. 30, 2014

Re: [Pharo-dev] ObjectLiterals thoughts....

by stepharo

On 29/8/14 11:56, Sven Van Caekenberghe wrote: > Hi, > > I had a quick look at the ObjectLiterals project - I must admit that I forgot most about it ;-) me too :) Christophe was patching STON to make it less verbose when I remembered that igor sent some ideas around. > > Now that I see it again, one of the things that strikes me is that there is no such thing as a general object fallback, as far as I can see - that is a choice of course. > > Note that I did answer your earlier mail about STON > > http://forum.world.st/About-STON-td4772934.html > > Sven > > On 29 Aug 2014, at 11:35, stepharo <stepharo(a)free.fr> wrote: > >> Hi guys >> >> we are looking at STON and ObjectLiterals with Christophe and for handling metadata. >> >> >> And I was brainstorming.... I was wondering if it would be possible to have a bit more use of self evaluating >> >> for example >> 1@3 >> #k -> 2 instead of (Association #k 123) >> >> >> my brainstorming is how could we minimize new syntactic constructs and still support a literal object format. >> So object literal cover that so may be this is good. >> >> 1@3 as (Point 1 3) >> and >> #k -> 123 as (Association #k 123) >> >> So I'm not clear but this is interesting to think about it. >> I would like to have also a dictionary literal syntax.... but this another story. >> >> Stef >> >> PS: Sven I added support for Association into the ObjectLiteral project to see how it works. >> >> >> >> >> >> >> >> >> >> I took Igor's initial code and created a new project: >> >> http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals/ >> >> and I added ObjectLiteralParser to convert any Character Stream or String into a Smalltalk Literal Array and eventually into an Object. >> >> This proof of concept moves the ObjectLiteral format/notation away from the Smalltalk compiler and will help us discuss more concretely the actual details of the specification (which is still not 100% finished). >> >> I also added 12 unit tests and cleaned up the code and comments. >> >> Please have a look at the code. >> >> This is one of the tests: >> >> ObjectLiteralParserTests>>#testMixed1 >> | input output | >> input := ' >> #(Array >> 1 >> foo >> #''foo-#bar'' >> true >> false >> nil >> 3.14159 >> -100 >> ''string'' >> (#OrderedCollection 7 8 9) >> #(Set 10) >> (Dictionary >> x 1 >> y 2) ) '. >> output := { >> 1. >> #foo. >> #'foo-#bar'. >> true. >> false. >> nil. >> 3.14159. >> -100. >> 'string'. >> OrderedCollection withAll: #(7 8 9). >> Set with: 10. >> Dictionary newFromPairs: #(x 1 y 2 ). }. >> self assert: (self parserOn: input) nextObjectLiteral equals: output >> >> I like this format, its simplicity and elegance is appealing, it offers distinctive advantages in the Smalltalk context while its slight readability disadvantage is acceptable. Like any format it is a compromise and a tradeoff, but a rather good one. >> >> Regards, >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> > >

Aug. 30, 2014

Re: [Pharo-dev] ObjectLiterals thoughts....

by stepharo

>> Hey! >> >> Just for some "food for thought", you may want to read the parts under heading "Literal Smalltalk arrays" and the section following - "Sidestory: Adding literal Dictionaries to Smalltalk?" >> >> ...at: >> >> http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/ >> >> regards, GÃ¶ran > Yes, that is a good write up, touching on all kinds of aspects, balanced too. > Pretty complicated subject, right ? ;-) :) > As you mention it is quite hard to reach an agreement. > Objectives/goals are different for everybody. > > Since we had those discussions long ago, I've actually grown quite used to writing > > { #foo->1. #bar->2 } asDictionary #{ #foo->1. #bar->2 } could do it for literal ones :) > > I know it is not super efficient, or super compact, but I can certainly live with it.

Aug. 30, 2014

Re: [Pharo-dev] ObjectLiterals thoughts....

by stepharo

do you know if amber has { } because ideally I would love to have something like #() literl array ##() dynamic array why not :) #{} literal dictionary ##{} dynamic literal dictionary On 29/8/14 12:53, GÃ¶ran Krampe wrote: > Hey! > > Just for some "food for thought", you may want to read the parts under > heading "Literal Smalltalk arrays" and the section following - > "Sidestory: Adding literal Dictionaries to Smalltalk?" > > ...at: > > http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/ > > > regards, GÃ¶ran > >

Aug. 30, 2014

Re: [Pharo-dev] ObjectLiterals thoughts....

by stepharo

**thanks** I will reread it and add it to my folder. because one day I would love to have literal dictionary syntax and (I think that this is a pity that { } is already use for dynamic arrays. Stf On 29/8/14 12:53, GÃ¶ran Krampe wrote: > Hey! > > Just for some "food for thought", you may want to read the parts under > heading "Literal Smalltalk arrays" and the section following - > "Sidestory: Adding literal Dictionaries to Smalltalk?" > > ...at: > > http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/ > > > regards, GÃ¶ran > >

Aug. 30, 2014