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

Having some trouble on the Pharo Contributions CI
by Sven Van Caekenberghe Aug. 31, 2014

Aug. 31, 2014

Hi, I seem to be having some trouble on the Pharo Contributions CI. I successfully created some projects before, but this time something strange is happening. It seems as if a win7 slave is doing the build instead of the linux slaves that I am used to. Has something changed ? I want to detect that I am running on the CI so that I can skip some tests that require resources not available there, but I fear the following won't work on Windows: runningOnInriaCI | platform ci | ^ [ platform := OSPlatform current. ci := platform environment at: #CI ifAbsent: [ '' ]. ci = 'ci.inria.fr' ] on: MessageNotUnderstood do: [ false ] What is the recommended way to use linux-only slaves ? Any other ideas ? Thanks, Sven

2 2

Re: [Pharo-dev] Future of Spec
by stepharo Aug. 31, 2014

Aug. 31, 2014

On 31/8/14 08:32, Martin Saurer wrote: > It's already planned ;-) :) excellent! Stef > > 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 > > > >

1 0

Glorp Login>>#encodingStrategy
by Sven Van Caekenberghe Aug. 31, 2014

Aug. 31, 2014

It seems that Glorp Login>>#encodingStrategy is not used by the NativePostgresDriver yet it is required to set it to a non nil value to get things working. This feels like a hack or something unfinished. Sven

2 3

Please add me to the PharoExtras team
by Sven Van Caekenberghe Aug. 31, 2014

Aug. 31, 2014

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

2 2

about to integrate GTools, there is a command conflict who needs attention
by Esteban Lorenzano Aug. 31, 2014

Aug. 31, 2014

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

6 9

Re: [Pharo-dev] Future of Spec
by Martin Saurer Aug. 31, 2014

Aug. 31, 2014

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

1 0

Anonymous classes in Pharo 3 - must be instances of Class, not Behavior
by Oscar Nierstrasz Aug. 30, 2014

Aug. 30, 2014

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.

4 5

>>#next: SocketStream and other oddities
by Holger Hans Peter Freyther Aug. 30, 2014

Aug. 30, 2014

Hi, while writing some SMS PDU parsing code I stumbled across an "oddity" I have not seen with GNU Smalltalk. When calling the >>#next: selector on a ReadStream and the number of elements I need are not available, Pharo will return less or an empty collection. This means I write code like this: | id len | id := stream next: 4 id size = 4 ifFalse: [^self reportError: 'Short read']. len := stream next: 4 len size = 4 ifFalse: [^self reportError: 'Len not available']. Besides the aesthetic issue it is getting worse when the SocketStream class is in use. So now >>#next: 4 can return nil as well. But naively I wrote code like this: [ | msg | msg := ThingParser parse: aSocketStream. ] on: ConnectionClosed do: [:e | self logStuff: e. self scheduleReconnect ] So to make the above code work with the SocketStream I need to write the following. I had a quick look at why the ConnectionClosed is swallowed and found the comment to allow partial reads out of a dead socket. | id len | id := stream next: 4. id ifNil: [^self reportError: 'Short read']. len := stream next: 4 len ifNil: [^self reportError: 'Short read']. len size = 4 ifFalse: [^self reportError: 'Len not available'] In GNU Smalltalk there is EndOfStream which is a subclass of Notification and the above code boils down to: [ | id len | id := stream next: 4. len := stream next: 4. ] on: EndOfStream do: [:e | self logStuff: e. self scheduleReconnect. ]. So couldn't the >>#readInto:startingAt:count: selector of SocketStream do something like GNU Smalltalk and give an EndOfStream notification? [self receiveData: anInteger] on: ConnectionClosed do:[:ex| EndOfStream signalOn: self. ex return ]. kind regards holger

4 4

ObjectLiterals thoughts....
by stepharo Aug. 30, 2014

Aug. 30, 2014

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

6 13

Re: [Pharo-dev] Future of Spec
by Martin Saurer Aug. 30, 2014

Aug. 30, 2014

Dear Stef, Dear Pharo Community, Many thanks for answering my question about the future of Spec. What I have done for the J platform, and now will try to do for Pharo is not directly comparable to Phobos (XULrunner) or Cocoa Widgets. At least I think so. If you are interested please take a look at: http://www.jsoftware.com/jwiki/Scripts/qjide The qfe (Qooxdoo Frontend Engine) which is part of the qjide on the J platform is based on the Ajax Framework "Qooxdoo" http://www.qooxdoo.org. The qfe is a JavaScript library which acts like Qt, WinForms, Cocoa, Morphic, etc. for the desktop, but lives entirely in the web browser. The web application itself is written in 100% J (now), or 100% Pharo (in the future). To build a qfe based web application, there is no need to use HTML, CSS, XULrunner, etc. The qfe may be bound to nearly any programming platform which has a web server. Pharo together with the Zinc server is a great environment for creating web applications that use a rich widget set like qfe provides. The final goal will be to create a Pharo GUI extension (probably based on Spec), where applications can be opened like MyGUIApp openInWorld. or MyGUIApp openInWeb. The first one opens a Spec (or Morphic) desktop GUI application in the Pharo window. The second one serves the same application with (nearly) the same look-and-feel as a web application. I will be happy to answer any questions on qfe. Cheers Martin

2 1