- Pharo-dev - lists.pharo.org

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

by stepharo

Hi holger I got confused. There is a problem with next: not raising error? Stef On 29/8/14 09:16, Holger Hans Peter Freyther wrote: > 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 > >

Aug. 30, 2014

Re: [Pharo-dev] Future of Spec

by stepharo

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 On 29/8/14 21:15, Martin Saurer wrote: > 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 > > >

Aug. 30, 2014

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

by Esteban A. Maringolo

It could be #stable, I just was afraid of breaking somebody else stuff. I'm a champion at f*king up third parties repositories. :) Regards! Esteban A. Maringolo ps: There is also other versions of GLORP I didn't bless as #stable. 2014-08-29 17:17 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 19 May 2014, at 18:20, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> I commited PostgresV2-EstebanMaringolo.32 and >> ConfigurationOfPostgresV2-EstebanMaringolo.11 (added version 2.3) to >> SmalltalkHub. >> >> I hope it doesn't break anything. If so, please apologize. >> Esteban A. Maringolo > > Esteban, > > Is there any reason why we should not make this the #stable version, at least for Pharo ? Things do not work without your latest patch on Pharo 3. > > Sven > >> 2014-05-19 12:55 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> you are part of the team, so you have write access. >>> >>> Esteban >>> >>> On 19 May 2014, at 17:25, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> >>>> I never uploaded the PostgresV2 update. And I don't see anybody else >>>> replaced the SqNumberParser to NumberParser reference. >>>> >>>> How can I upload the package back? >>>> Can I get write access to >>>> 'http://smalltalkhub.com/mc/DBXTalk/PostgresV2Driver/main' ? >>>> >>>> Regards, >>>> Esteban A. Maringolo >>>> >>>> >>>> 2014-04-10 11:19 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>>> And you are in DBXTalk now >>>>> >>>>> On 10 Apr 2014, at 16:15, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>>> >>>>>> I'm emaringolo@* :D >>>>>> >>>>>> Regards! >>>>>> >>>>>> Esteban A. Maringolo >>>>>> >>>>>> >>>>>> 2014-04-10 11:13 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>>>>> >>>>>>> On 10 Apr 2014, at 16:08, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>>>>> >>>>>>>> Can we coordinate efforts here? >>>>>>>> Can I at least have writing rights to GlorpDBX and PostgresV2 repos? :) >>>>>>> >>>>>>> What is your StHub username ? >>>>>>> I can add you to DBXTalk I think. >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > >

Aug. 29, 2014

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

by Sven Van Caekenberghe

On 19 May 2014, at 18:20, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I commited PostgresV2-EstebanMaringolo.32 and > ConfigurationOfPostgresV2-EstebanMaringolo.11 (added version 2.3) to > SmalltalkHub. > > I hope it doesn't break anything. If so, please apologize. > Esteban A. Maringolo Esteban, Is there any reason why we should not make this the #stable version, at least for Pharo ? Things do not work without your latest patch on Pharo 3. Sven > 2014-05-19 12:55 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> you are part of the team, so you have write access. >> >> Esteban >> >> On 19 May 2014, at 17:25, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >>> I never uploaded the PostgresV2 update. And I don't see anybody else >>> replaced the SqNumberParser to NumberParser reference. >>> >>> How can I upload the package back? >>> Can I get write access to >>> 'http://smalltalkhub.com/mc/DBXTalk/PostgresV2Driver/main' ? >>> >>> Regards, >>> Esteban A. Maringolo >>> >>> >>> 2014-04-10 11:19 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> And you are in DBXTalk now >>>> >>>> On 10 Apr 2014, at 16:15, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>> >>>>> I'm emaringolo@* :D >>>>> >>>>> Regards! >>>>> >>>>> Esteban A. Maringolo >>>>> >>>>> >>>>> 2014-04-10 11:13 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>>>> >>>>>> On 10 Apr 2014, at 16:08, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>>>> >>>>>>> Can we coordinate efforts here? >>>>>>> Can I at least have writing rights to GlorpDBX and PostgresV2 repos? :) >>>>>> >>>>>> What is your StHub username ? >>>>>> I can add you to DBXTalk I think. >>>>>> >>>>> >>>> >>>> >>> >> >> >

Aug. 29, 2014

Re: [Pharo-dev] Future of Spec

by Martin Saurer

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

Aug. 29, 2014

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

by Tudor Girba

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. 29, 2014

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

by Tudor Girba

Hi, The difference is that Cmd+o will open a new pane on the result. It's like Cmd+i only it does not spawn another window. Doru On Fri, Aug 29, 2014 at 12:34 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-08-29 12:26 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > >> On 29 Aug 2014, at 12:23, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> > >> > On 29 Aug 2014, at 12:19, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> > >> >> I have no idea what current (cmd+o+[w|t|etc]) stands for, so for me >> itâs ok to trash it. >> > >> > ehhhh, we are not talking about trash itâ¦ just remapping if needed :P >> > and those are commands for opening transcript, workspace, etc. >> >> oh, then this is useful :) >> >> > >> > Esteban >> > >> >> >> >> I think that cmd+s can make sense. >> >> >> >> And as we are here, Iâd like to point out that I donât like this >> shortcut chains. Iâd prefer to have cmd+x to remove what is currently >> focused rather then >> >> cmd+c+x, cmd+m+x and so on. >> >> >> >> Uko >> >> >> >> On 29 Aug 2014, at 11:54, 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 >> >> >> >> >> > >> > >> >> >> > > What's the difference between cmd+o and cmd+d for the Playground? > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 29, 2014

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

by Esteban A. Maringolo

2014-08-29 8:16 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > On 29 Aug 2014, at 12:53, GÃ¶ran Krampe <goran(a)krampe.se> wrote: >> 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?" > Since we had those discussions long ago, I've actually grown quite used to writing > > { #foo->1. #bar->2 } asDictionary > > I know it is not super efficient, or super compact, but I can certainly live with it. Plus, It doesn't require further changes. I got used to it too. BUT... ... I'd also love to have something like #{'foo' -> 1. #bar -> false} :) Esteban A. Maringolo

Aug. 29, 2014

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

by Damien Pollet

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 > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 29, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30856 Home: https://github.com/pharo-project/pharo-core

Aug. 29, 2014