March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Some issues with UDP sockets in Pharo 1.4/Pharo 2.0

by Holger Hans Peter Freyther

On Tue, Mar 26, 2013 at 09:08:09PM +0100, Sven Van Caekenberghe wrote: > Maybe I am telling you things you already know, but TCP and UDP are fundamentally different. UDP is really one-shot, try-and-hope, completely asynchronous. In networking you generally only get a ConnectionClosed when you actually read or write (and even then ;-). Yes, but at least for the unix platform on close the aio/select handler is removing the socket from the registration. So there is no way to read the zero from the dead socket. :) > For your concrete question (2): just start a reading process, wrap it in a handler and clean up. For UDP this will never happen: you will keep on reading nothing. For TCP reading will eventually fail if the other end disappears. Do you have an example for "handler and clean up"? I resorted to code like this for now in my 'blocking' read. [self dataAvailable] whileFalse: [[self waitForDataFor: 10] on: ConnectionTimedOut do: []]. But I have not ported my client code so I don't know if the above is working or not. This way I will get the ConnectionClosed exception at least within 10 seconds. thank you holger

March 27, 2013

Re: [Pharo-project] Some issues with UDP sockets in Pharo 1.4/Pharo 2.0

by Holger Hans Peter Freyther

On Wed, Mar 27, 2013 at 12:25:20AM +0100, Sven Van Caekenberghe wrote: > I politely disagree ;-) > > But I am willing to learn: so please provide some references of such UDP usage. > > http://en.wikipedia.org/wiki/Datagram I am not sure which part you are disagreeing to. But you can definately use connect on a SOCK_DGRAM. The benefit is that you can then use read/write on filedescriptor instead of sendto/recv. An example is here[1]. holger [1] http://cgit.osmocom.org/openbsc/tree/openbsc/src/osmo-bsc_mgcp/mgcp_main.c#…

March 27, 2013

Re: [Pharo-project] Suggestion about Phexample and StateSpecs(Mocketry) integration

by Tudor Girba

Perhaps Mocketry would be a good topic for a "Show us your projects" session. Then we can try to go into a couple of more details. Cheers, Doru On Mar 27, 2013, at 12:42 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Sounds good to me. > > On 26 Ð±ÐµÑ. 2013, at 23:00, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> >> On 2013-03-26, at 19:45, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >>> 2013/3/26 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> >>>> Ok, and what if we will change behavior a bit so if no definitions were >>>> found it will send the incoming message to enclosed object? This way it >>>> will work like phexample but will also allow to define some fancy DSL. >>>> >>> >>> We can copy all phexample syntax methods into single class inside >>> StateSpecs package but replace implementation with pragmas approach. So >>> anybody can browse implementors like usual and it will not required any >>> special cases. >>> >>> How I can influence your interest, guys? I can provide cleaning, comments, >>> improvements to StateSpecs. I opened for your requirements. >>> Phexample become quite popular and can be part of Pharo sometimes. >>> Mocketry/StateSpecs used by people too. >>> It would be bad if this packages can't be used together. >> >> sorry for starting the whole rant :) I am veery busy at least until tomorrow >> >> Yuriy we can discuss that after tomorrow? >> I would as well appreciate some common solution to avoid the selector clash. >> >> >> >>>> On 26 Ð±ÐµÑ. 2013, at 07:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>>> >>>> Hello >>>> 2013/3/26 Camillo Bruni <camillobruni(a)gmail.com> >>>> >>>>> Definitely StateSpec looks more mature and can be used in a more flexible >>>>> way. >>>>> But I am not a big fan of the pragma magic. Why? >>>>> It breaks all tools for me :/. If I see a message send I want to be able >>>>> to: >>>>> - browse it, so I can see who implements it? >>>>> - debug it directly to get to the real method. >>>>> >>>>> SateSpec does indeed help writing readable code by allowing almost >>>>> grammatically >>>>> correct sentences. However I don't think this is the way to program. I am >>>>> a big >>>>> fan of stupid english: >>>>> >>>>> `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` >>>>> >>>>> If I want to figure out how the first one works, I can simply browse the >>>>> implementors of #should and/or #isKindOf: where is the StateSpec version >>>>> I am >>>>> lost. I have to rely on "contains string literal" to get the sources, for >>>>> me >>>>> that is very strange. >>>>> >>>> >>>> I think main thing you want is easilly explore all available should >>>> syntax. And StateSpecs can be easilly adopted for such task. We can just >>>> move all methods with syntax pragmas to single class. So you can open this >>>> class and see what available. >>>> >>>> To get implementors of some "should expression" you should use senders >>>> search of syntax words instead of implementors. Syntax words in StateSpecs >>>> is just method literals ( <syntax: #(be an instance of:)>, #() is just >>>> array of symbols). >>>> >>>> Interesting that StateSpecs has more explicit syntax system. How you can >>>> explore in Phexample expression: >>>> >>>> object should be true >>>> ? >>>> >>>> You have separate PheMatcher>>be and PheMatcher>>true methods and there is >>>> no places in code where you can see that this messages can and should be >>>> used together. >>>> But with StateSpecs you should put pragma with explicit expression like: >>>> >>>> Equal>>true: anObject >>>> <syntax: #(be true)> >>>> ^self return: (IdentitySpec pattern: true) >>>> >>>> So with StateSpecs you have full syntax expression at one place which can >>>> be easy explored. >>>> And for example to support Phexample mesage #beTrue you should just add >>>> another pragma: >>>> >>>> Equal>>true: anObject >>>> <syntax: #(be true)> >>>> <syntax: #(beTrue)> >>>> ^self return: (IdentitySpec pattern: true) >>>> >>>> So with Phexample you can browse implementors of "single word should >>>> expressions". But with Phexample if you browse implementors of #be like >>>> messages you have no idea how it can be used. >>>> In StateSpecs you should use senders. And with StateSpecs if you browse >>>> "any syntax word implementors" by senders seach you will see all possible >>>> usage cases. And if I move all methods with syntax pragmas to single class >>>> you can easilly see all possible expressions in one place. >>>> >>>> `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` >>>>> >>>> >>>> With StateSpecs it should be >>>> >>>> foo should be a kind of: Bar >>>> >>>> And as I said before It is simple task to support all Phexample >>>> expressions by StateSpecs pragmas >>>> >>>> Best regards, >>>> Denis >>>> >>>> >>>> >> >> > > -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

March 27, 2013

Re: [Pharo-project] Some issues with UDP sockets in Pharo 1.4/Pharo 2.0

by Esteban A. Maringolo

2013/3/26 Sven Van Caekenberghe <sven(a)stfx.eu>: > I politely disagree ;-) > > But I am willing to learn: so please provide some references of such UDP usage. I can't speak about all the implementations, but several years ago I did an UDP Socket wrapper for Dolphin Smalltalk 5 which basically wrapped the Win32 API. AFAIR, there were no connection exceptions, nor state whatsoever, just open a udp socket to a destination address and send datagrams through it, hopefully they'll reach the desired destination. On the other side the server is non blocking, just listening at an address and port, but it was event-based: on each datagram received it fired an event. Regards!

March 27, 2013

Re: [Pharo-project] Suggestion about Phexample and StateSpecs(Mocketry) integration

by Yuriy Tymchuk

Sounds good to me. On 26 Ð±ÐµÑ. 2013, at 23:00, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-03-26, at 19:45, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> 2013/3/26 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> >>> Ok, and what if we will change behavior a bit so if no definitions were >>> found it will send the incoming message to enclosed object? This way it >>> will work like phexample but will also allow to define some fancy DSL. >>> >> >> We can copy all phexample syntax methods into single class inside >> StateSpecs package but replace implementation with pragmas approach. So >> anybody can browse implementors like usual and it will not required any >> special cases. >> >> How I can influence your interest, guys? I can provide cleaning, comments, >> improvements to StateSpecs. I opened for your requirements. >> Phexample become quite popular and can be part of Pharo sometimes. >> Mocketry/StateSpecs used by people too. >> It would be bad if this packages can't be used together. > > sorry for starting the whole rant :) I am veery busy at least until tomorrow > > Yuriy we can discuss that after tomorrow? > I would as well appreciate some common solution to avoid the selector clash. > > > >>> On 26 Ð±ÐµÑ. 2013, at 07:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> Hello >>> 2013/3/26 Camillo Bruni <camillobruni(a)gmail.com> >>> >>>> Definitely StateSpec looks more mature and can be used in a more flexible >>>> way. >>>> But I am not a big fan of the pragma magic. Why? >>>> It breaks all tools for me :/. If I see a message send I want to be able >>>> to: >>>> - browse it, so I can see who implements it? >>>> - debug it directly to get to the real method. >>>> >>>> SateSpec does indeed help writing readable code by allowing almost >>>> grammatically >>>> correct sentences. However I don't think this is the way to program. I am >>>> a big >>>> fan of stupid english: >>>> >>>> `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` >>>> >>>> If I want to figure out how the first one works, I can simply browse the >>>> implementors of #should and/or #isKindOf: where is the StateSpec version >>>> I am >>>> lost. I have to rely on "contains string literal" to get the sources, for >>>> me >>>> that is very strange. >>>> >>> >>> I think main thing you want is easilly explore all available should >>> syntax. And StateSpecs can be easilly adopted for such task. We can just >>> move all methods with syntax pragmas to single class. So you can open this >>> class and see what available. >>> >>> To get implementors of some "should expression" you should use senders >>> search of syntax words instead of implementors. Syntax words in StateSpecs >>> is just method literals ( <syntax: #(be an instance of:)>, #() is just >>> array of symbols). >>> >>> Interesting that StateSpecs has more explicit syntax system. How you can >>> explore in Phexample expression: >>> >>> object should be true >>> ? >>> >>> You have separate PheMatcher>>be and PheMatcher>>true methods and there is >>> no places in code where you can see that this messages can and should be >>> used together. >>> But with StateSpecs you should put pragma with explicit expression like: >>> >>> Equal>>true: anObject >>> <syntax: #(be true)> >>> ^self return: (IdentitySpec pattern: true) >>> >>> So with StateSpecs you have full syntax expression at one place which can >>> be easy explored. >>> And for example to support Phexample mesage #beTrue you should just add >>> another pragma: >>> >>> Equal>>true: anObject >>> <syntax: #(be true)> >>> <syntax: #(beTrue)> >>> ^self return: (IdentitySpec pattern: true) >>> >>> So with Phexample you can browse implementors of "single word should >>> expressions". But with Phexample if you browse implementors of #be like >>> messages you have no idea how it can be used. >>> In StateSpecs you should use senders. And with StateSpecs if you browse >>> "any syntax word implementors" by senders seach you will see all possible >>> usage cases. And if I move all methods with syntax pragmas to single class >>> you can easilly see all possible expressions in one place. >>> >>> `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` >>>> >>> >>> With StateSpecs it should be >>> >>> foo should be a kind of: Bar >>> >>> And as I said before It is simple task to support all Phexample >>> expressions by StateSpecs pragmas >>> >>> Best regards, >>> Denis >>> >>> >>> > >

March 26, 2013

Re: [Pharo-project] Some issues with UDP sockets in Pharo 1.4/Pharo 2.0

by Sven Van Caekenberghe

On 26 Mar 2013, at 23:46, Norbert Hartl <norbert(a)hartl.name> wrote: > Am 26.03.2013 um 21:08 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> Hi Holger, >> >> On 26 Mar 2013, at 12:12, Holger Hans Peter Freyther <holger(a)freyther.de> wrote: >> >>> Hi, >>> >>> I am porting a tooling class that I wrote on GST for my SIP and MGCP code >>> to Pharo. This class will create a socket and then fork a RX and TX process. >>> I have some issues with 'stopping' the socket. I have created an example >>> that shows the issue in Pharo 2.0 and Pharo 1.4 with the pharovm (and to >>> have more debug output with a re-compiled one). >>> >>> >>> | s rx | >>> s := Socket newUDP. >>> rx := [ >>> [s waitForData. s halt] >>> on: ConnectionClosed do: [ s halt] >>> ] fork. >>> "Wait for the process to hit the readSemaphore" >>> (Delay forSeconds: 3) wait. >>> s close. >>> >>> >>> My expectation is that I will get the ConnectionClosed signal or at least >>> that >>#waitForData will return once the socket is closed. This is based >>> on reading the comment of >>#waitForData. >>> >>> >>> The Socket>>#waitForData documentation reads like this: >>> "Wait for data to arrive. This method will block until >>> data is available or the socket is closed. If the socket is closed >>> a ConnectionClosed exception will be signaled." >>> >>> >>> I had a look at the socket plugin and the following is happening. First >>> aio is disabled, the state set to ThisEndClosed, then ::close is called >>> and in the above case the result is '0' and the following code will be >>> executed: >>> >>> else if (0 == result) >>> { >>> /* close completed synchronously */ >>> SOCKETSTATE(s)= Unconnected; >>> FPRINTF((stderr, "closeConnection: disconnected\n")); >>> SOCKET(s)= -1; >>> } >>> >>> >>> this means that my 'rx' process will happily wait on the readSemaphore >>> of the Socket and will never be woken up. >>> >>> >>> My question are probably: >>> >>> 1.) Is this the intended behavior for Socket>>#close and Socket>>#waitForData? >>> 2.) How should I terminate my RX process? >>> >>> kind regards >>> holger >>> >>> PS: The issue is probably socket specific and not related to UDP. >> >> Maybe I am telling you things you already know, but TCP and UDP are fundamentally different. UDP is really one-shot, try-and-hope, completely asynchronous. In networking you generally only get a ConnectionClosed when you actually read or write (and even then ;-). >> > That's not really true. It is implementation specific. IMHO you can open a UDP socket in send and receive mode where the communication is synchronous. So your socket blocks until a datagram socket is received. This has to advantage that the underlying OS registers local and remote port and automatically and accepts only datagrams for the right ports match. As it is in a lot of use cases not preferrable to have blocking sockets while using UDP you use two sockets instead, one for sending and one for receiving. For this you need to register the listening socket for listening to everything. > Disclaimer: I took this from the back of my head and this might by outdated/inproper information. I just wanted to say that you shouldn't mix asynchronous with unidirectional :) > > Norbert I politely disagree ;-) But I am willing to learn: so please provide some references of such UDP usage. http://en.wikipedia.org/wiki/Datagram >> The Socket API has many strange methods, most of which you should not touch. You should use SocketStream. Looking in the VM code is also misleading because the 3 platforms (Mac, Win, *nix) are different. In Socket[Stream] there is lots of historic baggage. >> >> I would suggest you look at Smalltalk code that actually works (for TCP, Zinc Client and Server code would do, for UDP, ZTimestampSNTPClient for example). >> >> For your concrete question (2): just start a reading process, wrap it in a handler and clean up. For UDP this will never happen: you will keep on reading nothing. For TCP reading will eventually fail if the other end disappears. >> >> HTH, >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> > >

March 26, 2013

Re: [Pharo-project] Some issues with UDP sockets in Pharo 1.4/Pharo 2.0

by Norbert Hartl

Am 26.03.2013 um 21:08 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi Holger, > > On 26 Mar 2013, at 12:12, Holger Hans Peter Freyther <holger(a)freyther.de> wrote: > >> Hi, >> >> I am porting a tooling class that I wrote on GST for my SIP and MGCP code >> to Pharo. This class will create a socket and then fork a RX and TX process. >> I have some issues with 'stopping' the socket. I have created an example >> that shows the issue in Pharo 2.0 and Pharo 1.4 with the pharovm (and to >> have more debug output with a re-compiled one). >> >> >> | s rx | >> s := Socket newUDP. >> rx := [ >> [s waitForData. s halt] >> on: ConnectionClosed do: [ s halt] >> ] fork. >> "Wait for the process to hit the readSemaphore" >> (Delay forSeconds: 3) wait. >> s close. >> >> >> My expectation is that I will get the ConnectionClosed signal or at least >> that >>#waitForData will return once the socket is closed. This is based >> on reading the comment of >>#waitForData. >> >> >> The Socket>>#waitForData documentation reads like this: >> "Wait for data to arrive. This method will block until >> data is available or the socket is closed. If the socket is closed >> a ConnectionClosed exception will be signaled." >> >> >> I had a look at the socket plugin and the following is happening. First >> aio is disabled, the state set to ThisEndClosed, then ::close is called >> and in the above case the result is '0' and the following code will be >> executed: >> >> else if (0 == result) >> { >> /* close completed synchronously */ >> SOCKETSTATE(s)= Unconnected; >> FPRINTF((stderr, "closeConnection: disconnected\n")); >> SOCKET(s)= -1; >> } >> >> >> this means that my 'rx' process will happily wait on the readSemaphore >> of the Socket and will never be woken up. >> >> >> My question are probably: >> >> 1.) Is this the intended behavior for Socket>>#close and Socket>>#waitForData? >> 2.) How should I terminate my RX process? >> >> kind regards >> holger >> >> PS: The issue is probably socket specific and not related to UDP. > > Maybe I am telling you things you already know, but TCP and UDP are fundamentally different. UDP is really one-shot, try-and-hope, completely asynchronous. In networking you generally only get a ConnectionClosed when you actually read or write (and even then ;-). > That's not really true. It is implementation specific. IMHO you can open a UDP socket in send and receive mode where the communication is synchronous. So your socket blocks until a datagram socket is received. This has to advantage that the underlying OS registers local and remote port and automatically and accepts only datagrams for the right ports match. As it is in a lot of use cases not preferrable to have blocking sockets while using UDP you use two sockets instead, one for sending and one for receiving. For this you need to register the listening socket for listening to everything. Disclaimer: I took this from the back of my head and this might by outdated/inproper information. I just wanted to say that you shouldn't mix asynchronous with unidirectional :) Norbert > The Socket API has many strange methods, most of which you should not touch. You should use SocketStream. Looking in the VM code is also misleading because the 3 platforms (Mac, Win, *nix) are different. In Socket[Stream] there is lots of historic baggage. > > I would suggest you look at Smalltalk code that actually works (for TCP, Zinc Client and Server code would do, for UDP, ZTimestampSNTPClient for example). > > For your concrete question (2): just start a reading process, wrap it in a handler and clean up. For UDP this will never happen: you will keep on reading nothing. For TCP reading will eventually fail if the other end disappears. > > HTH, > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

March 26, 2013

Re: [Pharo-project] GSoC idea: Spec over Aida component model

by stephane ducasse

On Mar 26, 2013, at 8:56 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Thanks for the explanation :) > > My question was more > Can I be a student for project Foo and a mentor for project Bar ? yes I do not see why > > :) > > Ben > > On Mar 26, 2013, at 8:41 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > >> Hi Benjamin >> >> Dne 26. 03. 2013 16:04, piÅ¡e Benjamin: >>> Of course I could be a mentor :) >>> >>> But my question is can I be a mentor and a student ? >> >> Unfortunatelly not :( >> >>> And this proposal go in the direction I want Spec to follow: >>> platform/framework independency :) >>> I know that Nico would love to have Spec running in Amber ^^ >> >> So you'd like to run as a student for the Spec Independency project, >> which is also your proposal, so this is actually a Student proposal, >> right? :) >> >> In any case your project can be a good one in parallel to Spec over Aida >> one. And another over Amber? That way we can evolve Spec while testing >> it in many frameworks at once. But it seems that we all need to adjust a >> terminology a bit, HTML5 terms are a bit different, those ins W3C Web >> Components spec different again, etc. Then event architecture could be >> different that one in web browser's DOM tree. Then MVC, dependency >> mechanism, how ideas from JavaScript MVC frameworks like Ember.js, >> Angular.js etc, can be covered with Spec. In any case, pretty amusing >> projects indeed :) >> >> Best regards >> Janko >> >>> >>> Ben >>> >>> On Mar 26, 2013, at 3:49 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si >>> <mailto:janko.mivsek@eranova.si>> wrote: >>> >>>> Guys, would be this an interesting project to advance Smalltalk UI more >>>> toward bleeding edge again, after 30 years, when we were there already >>>> with MVC based GUI? Spec project have a potential here and Spec over web >>>> frameworks to build fully desktop-capable web apps seems to be >>>> achievable. Spec over Amber (who will propose that?), Spec over Aida, >>>> Spec over Seaside? Benjamin, would you be a co-mentor of that project? >>>> >>>> Title: Spec over Aida for desktop-capable Web Apps >>>> >>>> Level: advanced >>>> >>>> Possible mentor: Janko MivÅ¡ek >>>> >>>> Possible second mentor: Benjamin? >>>> >>>> Description >>>> >>>> Spec as a means to describe and generate GUI has a potential to help >>>> building web applications as well. And because one of Spec goals is to >>>> become a platform/framework independent, this project has a goal to >>>> extend Aida component model for building Single Page web apps to become >>>> Spec-aware >>>> >>>> >>>> Technical Details >>>> >>>> Aida has a component model for building so called Single Page web UIs, >>>> capable of composing a hierarchy of so called web widgets, which are >>>> standalone reusable components, together with hierarchical web form >>>> support. Spec as descriptor and generator of UI is therefore a natural >>>> extension of Aida component model. When a HTML5 Web Components standard >>>> will be ready, Aida component model can be easily extended to support >>>> that standard as well, together with Spec (and maybe UIBuilder too?). >>>> >>>> Benefits to the Student >>>> >>>> Student will acquire the knowledge and experience of building >>>> desktop-capable UIs on the web using HTML5 approach. >>>> >>>> Benefits to the Community >>>> >>>> Spec has a potential to become a de-facto standard way of describing >>>> User Interfaces for Smalltalk projects from desktop to web and mobile, >>>> on a dialect and web framework neutral way. This project can contribute >>>> a piece toward that goal. >>>> >>>> >>>> Best regards >>>> Janko >>>> >>>> >>>> -- >>>> Janko MivÅ¡ek >>>> Aida/Web >>>> Smalltalk Web Application Server >>>> http://www.aidaweb.si >>>> >>> >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> >

March 26, 2013

Re: [Pharo-project] [Pharo-users] More GSoC ideas wanted, 3 days left ....

by stephane ducasse

On Mar 26, 2013, at 2:36 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > Hi Stef, > > Dne 26. 03. 2013 13:35, piÅ¡e stephane ducasse: >> Janko >> >> Can you put andrei chis and nicolas passerini for Debugger improvment projects. > > Put where? As mentors? Yes they are more into it. > >> I know that alexandre should propose a couple of topics around roassal. >> >> I could come up with a couple of other topics. >> Here is one: > > Added > > Best regards > Janko >> >> >>> Ideas so far: http://gsoc2013.esug.org/ideas >>> >>> To propose an idea just respond to this post by fulfilling this idea >>> template: >>> >>> Title: >> Better rewriting rule tool >> >> >>> Level: (beginner, intermediate, advanced) >> Intermediate >> >>> Possible mentor: (if already known) >> Stephane Ducasse >> >>> Possible second mentor: (if already known) >> Andre Hora >>> >>> Description >> The refactoring browser is based on a powerful rewrite engine which transforms AST. >> However it is quite cumbersome to write rewrite rules. There is a need to build a tool to help >> programmers defining their own transformation. >> >>> Technical Details >>> >>> Benefits to the Student >> learning AST >> learning AST transofrmation >> learning AST pattern matching >> User interface definition >> >>> Benefits to the Community >> A tool that is cruelly missing. >> >> >>> >>> Best regards >>> Serge and Janko, >>> your this year GSoC admins >>> >>> >>> -- >>> Janko MivÅ¡ek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >> >> >> > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

March 26, 2013

Re: [Pharo-project] Suggestion about Phexample and StateSpecs(Mocketry) integration

by Camillo Bruni

On 2013-03-26, at 19:45, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/3/26 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > >> Ok, and what if we will change behavior a bit so if no definitions were >> found it will send the incoming message to enclosed object? This way it >> will work like phexample but will also allow to define some fancy DSL. >> > > We can copy all phexample syntax methods into single class inside > StateSpecs package but replace implementation with pragmas approach. So > anybody can browse implementors like usual and it will not required any > special cases. > > How I can influence your interest, guys? I can provide cleaning, comments, > improvements to StateSpecs. I opened for your requirements. > Phexample become quite popular and can be part of Pharo sometimes. > Mocketry/StateSpecs used by people too. > It would be bad if this packages can't be used together. sorry for starting the whole rant :) I am veery busy at least until tomorrow Yuriy we can discuss that after tomorrow? I would as well appreciate some common solution to avoid the selector clash. >> On 26 Ð±ÐµÑ. 2013, at 07:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> Hello >> 2013/3/26 Camillo Bruni <camillobruni(a)gmail.com> >> >>> Definitely StateSpec looks more mature and can be used in a more flexible >>> way. >>> But I am not a big fan of the pragma magic. Why? >>> It breaks all tools for me :/. If I see a message send I want to be able >>> to: >>> - browse it, so I can see who implements it? >>> - debug it directly to get to the real method. >>> >>> SateSpec does indeed help writing readable code by allowing almost >>> grammatically >>> correct sentences. However I don't think this is the way to program. I am >>> a big >>> fan of stupid english: >>> >>> `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` >>> >>> If I want to figure out how the first one works, I can simply browse the >>> implementors of #should and/or #isKindOf: where is the StateSpec version >>> I am >>> lost. I have to rely on "contains string literal" to get the sources, for >>> me >>> that is very strange. >>> >> >> I think main thing you want is easilly explore all available should >> syntax. And StateSpecs can be easilly adopted for such task. We can just >> move all methods with syntax pragmas to single class. So you can open this >> class and see what available. >> >> To get implementors of some "should expression" you should use senders >> search of syntax words instead of implementors. Syntax words in StateSpecs >> is just method literals ( <syntax: #(be an instance of:)>, #() is just >> array of symbols). >> >> Interesting that StateSpecs has more explicit syntax system. How you can >> explore in Phexample expression: >> >> object should be true >> ? >> >> You have separate PheMatcher>>be and PheMatcher>>true methods and there is >> no places in code where you can see that this messages can and should be >> used together. >> But with StateSpecs you should put pragma with explicit expression like: >> >> Equal>>true: anObject >> <syntax: #(be true)> >> ^self return: (IdentitySpec pattern: true) >> >> So with StateSpecs you have full syntax expression at one place which can >> be easy explored. >> And for example to support Phexample mesage #beTrue you should just add >> another pragma: >> >> Equal>>true: anObject >> <syntax: #(be true)> >> <syntax: #(beTrue)> >> ^self return: (IdentitySpec pattern: true) >> >> So with Phexample you can browse implementors of "single word should >> expressions". But with Phexample if you browse implementors of #be like >> messages you have no idea how it can be used. >> In StateSpecs you should use senders. And with StateSpecs if you browse >> "any syntax word implementors" by senders seach you will see all possible >> usage cases. And if I move all methods with syntax pragmas to single class >> you can easilly see all possible expressions in one place. >> >> `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` >>> >> >> With StateSpecs it should be >> >> foo should be a kind of: Bar >> >> And as I said before It is simple task to support all Phexample >> expressions by StateSpecs pragmas >> >> Best regards, >> Denis >> >> >>

March 26, 2013