jolie-devel Mailing List for Jolie (Page 20)
A service-oriented programming language.
Brought to you by:
fmontesi
You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(18) |
Nov
(28) |
Dec
(36) |
2014 |
Jan
(21) |
Feb
(21) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(14) |
Sep
(14) |
Oct
(5) |
Nov
(26) |
Dec
(8) |
2015 |
Jan
(21) |
Feb
(194) |
Mar
(113) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Matthias D. W. <mwa...@ya...> - 2013-12-10 16:48:57
|
Hi, this is a first idea. There is still something missing, since server and client processes do not exit after a simple one-way communication message. Matthias Fabrizio Montesi schrieb: > Hi Matthias, > sorry for the late reply, I've been pretty busy with my PhD. > > Yes, I think that could work! > > Wanna try change SODEPProtocol? I think that a possible fix could be > to catch EOFException there in the first read (that for the message > id) and rethrow it as a ChannelClosedException. > > Cheers, > Fabrizio. > > On Fri, Nov 29, 2013 at 10:08 AM, Matthias Dieter Wallnöfer > <mwa...@ya...> wrote: >> Any news on this one? >> >> Matthias Dieter Wallnöfer schrieb: >> >>> Hi Fabrizio, >>> >>> yes, the easiest would be to extend ChannelClosedException from >>> EOFException? So very little changes would be necessary. Otherwise we >>> would need to extend each method's signature. >>> >>> Cheers, >>> Matthias >>> >>> Fabrizio Montesi schrieb: >>>> Hi Matthias, >>>> yeah, we have an annoying bug that doesn't really hurt but appears >>>> like that (just prints that on screen) depending on the underlying OS >>>> and network. It is consistent when using localhost afaik. >>>> >>>> Basically, every output port channel is handled by a separate thread, >>>> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for >>>> new messages on the channel and puts them in cache when the >>>> interpreter is ready to receive a response for an operation (in the >>>> case of one-way such responses are just ACKs that the messages have >>>> been put in the channel cache on the other side). >>>> >>>> So, you have that thread on the client waiting on the channel, and the >>>> server suddenly goes down because it terminates execution. Then, the >>>> client throws that exception. >>>> >>>> The problem in handling this gracefully is that we should >>>> differentiate between an EOFException that we get in the middle of >>>> parsing a received message in a protocol (e.g., SODEP, but more in >>>> general CommProtocol.recv()), or the same exception got when trying to >>>> receive the first bit of information (which is your case if you look >>>> at the source code at SodepProtocol.java:252). >>>> Then, the protocol could throw a custom exception that we create >>>> (ChannelClosedException?) representing a graceful channel closing and >>>> catch it from jolie.net.AbstractCommChannel$ResponseReceiver. >>>> >>>> Let me know if you'd be interested in tackling this. >>>> >>>> Cheers, >>>> Fabrizio. >>>> >>>> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer >>>> <mwa...@ya...> wrote: >>>>> Hi Fabrizio, >>>>> >>>>> this works well, but on the client side >>>>>> main >>>>>> { >>>>>> twice@TwiceService( 5 ) >>>>>> } >>>>> I get a Java EOF exception. I imagine that this could be a coordination >>>>> issue? >>>>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning >>>>>> WARNING: [client.ol] java.io.EOFException >>>>>> at java.io.DataInputStream.readFully(DataInputStream.java:197) >>>>>> at java.io.DataInputStream.readLong(DataInputStream.java:416) >>>>>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) >>>>>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) >>>>>> at >>>>>> jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) >>>>>> at jolie.net.CommChannel.recv(CommChannel.java:198) >>>>>> at >>>>>> >>>>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) >>>>>> at >>>>>> >>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>> at >>>>>> >>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>> at java.lang.Thread.run(Thread.java:724) >>>>> Cheers, >>>>> Matthias >>>>> >>>>> Fabrizio Montesi schrieb: >>>>> >>>>>> Hi Matthias, >>>>>> this: >>>>>>> twice( number ) { >>>>>>> result = number * 2; >>>>>>> println@Console( result )(); >>>>>>> } >>>>>> is not a construct in the language. Request-Response operations >>>>>> support the { block } construct because it is useful to specify >>>>>> something to happen *in-between* the request and the response. For >>>>>> one-ways this is not necessary because they just receive something. >>>>>> Hence you can just use the semicolon operator for expressing a >>>>>> sequence and obtain what you want: >>>>>> >>>>>> twice( number ); >>>>>> result = number * 2; >>>>>> println@Console( result )() >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Fabrizio. >>>>>> >>>>>> >>>>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer >>>>>> <mwa...@ya...> wrote: >>>>>>> Hi developers, >>>>>>> >>>>>>> I got another question: in >>>>>>> >>>>>>> >>>>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment >>>>>>> we have a simple client-server example: >>>>>>>> |main| >>>>>>>> |{| >>>>>>>> |||twice( number )( response ) {| >>>>>>>> |||response = number * ||2| >>>>>>>> |||}| >>>>>>>> |}| >>>>>>> But when I change it to be one-way I run into trouble: >>>>>>>> interface TwiceInterface { >>>>>>>> OneWay: twice( int ) >>>>>>>> } >>>>>>> and >>>>>>>> main >>>>>>>> { >>>>>>>> twice( number ) { >>>>>>>> result = number * 2; >>>>>>>> println@Console( result )(); >>>>>>>> } >>>>>>>> } >>>>>>> does not work. Why? >>>>>>> >>>>>>> Do I need something like this? >>>>>>>> main >>>>>>>> { >>>>>>>> [ twice( number ) ] { >>>>>>>> result = number * 2; >>>>>>>> println@Console( result )(); >>>>>>>> } >>>>>>>> } >>>>>>> Cheers, >>>>>>> Matthias >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Shape the Mobile Experience: Free Subscription >>>>>>> Software experts and developers: Be at the forefront of tech >>>>>>> innovation. >>>>>>> Intel(R) Software Adrenaline delivers strategic insight and >>>>>>> game-changing >>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign >>>>>>> up >>>>>>> now. >>>>>>> >>>>>>> >>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>>>> _______________________________________________ >>>>>>> Jolie-devel mailing list >>>>>>> Jol...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>> conversations that shape the rapidly evolving mobile landscape. Sign up >>> now. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Jolie-devel mailing list >>> Jol...@li... >>> https://lists.sourceforge.net/lists/listinfo/jolie-devel >> |
From: Fabrizio M. <fam...@gm...> - 2013-12-10 16:32:10
|
Mmh... a possible solution could be that we add a check that verifies whether we're creating a type with the same name of a predefined type in Jolie (in which case we should not create the type) or not (in which case we should create the type). What do you think? If this can work, the systematic way of doing it would be to have some constant set or enum defined somewhere which contains the names of all predefined types (I think we can reuse some predefined map from the parser). - Fabrizio On Tue, Dec 10, 2013 at 5:11 PM, Matthias Dieter Wallnöfer <mwa...@ya...> wrote: > Hi all, > > not really correct. It generates types like "type <name>:undefined", for > instance in my case: >> >> type GetWeatherInformation:undefined > > So this is required in some cases. > > Cheers, > Matthias > > Claudio Guidi schrieb: >> >> Hi all, >> >> sorry for the delay. >> >> Do you mean this line? >> >> jolieTypes.add( createAnyOrUndefined( element.getName(), complexType ) ); >> >> If I remember well it was commented because, otherwise, you will find >> >> type undefined: undefined >> >> into the generated interface. >> >> >> >> -------------------------------------------------------------- >> Claudio Guidi Ph.D. >> italianaSoftware s.r.l. >> via Coralli, 66 - 40026 Imola (BO), Italy >> http://www.italianasoftware.com/ >> http://www.jolie-lang.org <http://www.jolie-lang.org/> >> >> Phone: +39 0542 788201 >> Mobile: +39 347 0694065 >> Fax: +39 0542 628048 >> -------------------------------------------------------------- >> >> Nota di riservatezza: Il presente messaggio, corredato dei relativi >> allegati, contiene informazioni da considerarsi strettamente riservate, ed è >> destinato esclusivamente al destinatario sopra indicato, il quale è l'unico >> autorizzato ad usarlo, copiarlo e, sotto la propria >> responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per errore o >> comunque lo leggesse senza esserne legittimato è avvertito che trattenerlo, >> copiarlo,divulgarlo, distribuirlo a persone diverse dal destinatario è >> severamente proibito, ed è pregato di rinviarlo immediatamente al mittente >> distruggendone l'originale. >> >> Grazie per la collaborazione. >> >> >> 2013/12/9 Fabrizio Montesi <fam...@gm... >> <mailto:fam...@gm...>> >> >> >> Hi all, >> >> @Claudio: do you have any info on that line? >> >> Cheers, >> Fabrizio. >> >> On Wed, Dec 4, 2013 at 5:50 PM, Matthias Dieter Wallnöfer >> <mwa...@ya... <mailto:mwa...@ya...>> wrote: >> > Any news on this one (and also on the Exception thing: Re: >> [Jolie-devel] >> > OneWay messages)? >> > >> > Matthias >> > >> > Fabrizio Montesi schrieb: >> > >> >> Hi all, >> >> I'm trying to see why that line has been commented... >> especially since >> >> it has been commented without leaving any other comment >> explaining the >> >> reason in the code. Claudio, any memories? :-) >> >> >> >> I see it's commented out in many parts of the code. >> >> >> >> >> >> Cheers, >> >> Fabrizio. >> > >> > >> >> > |
From: Matthias D. W. <mwa...@ya...> - 2013-12-10 16:11:12
|
Hi all, not really correct. It generates types like "type <name>:undefined", for instance in my case: > type GetWeatherInformation:undefined So this is required in some cases. Cheers, Matthias Claudio Guidi schrieb: > Hi all, > > sorry for the delay. > > Do you mean this line? > > jolieTypes.add( createAnyOrUndefined( element.getName(), complexType ) ); > > If I remember well it was commented because, otherwise, you will find > > type undefined: undefined > > into the generated interface. > > > > -------------------------------------------------------------- > Claudio Guidi Ph.D. > italianaSoftware s.r.l. > via Coralli, 66 - 40026 Imola (BO), Italy > http://www.italianasoftware.com/ > http://www.jolie-lang.org <http://www.jolie-lang.org/> > Phone: +39 0542 788201 > Mobile: +39 347 0694065 > Fax: +39 0542 628048 > -------------------------------------------------------------- > > Nota di riservatezza: Il presente messaggio, corredato dei > relativi allegati, contiene informazioni da considerarsi strettamente > riservate, ed è destinato esclusivamente al destinatario sopra > indicato, il quale è l'unico autorizzato ad usarlo, copiarlo e, sotto > la propria responsabilità,diffonderlo. Chiunque ricevesse questo > messaggio per errore o comunque lo leggesse senza esserne legittimato > è avvertito che trattenerlo, copiarlo,divulgarlo, distribuirlo a > persone diverse dal destinatario è severamente proibito, ed è pregato > di rinviarlo immediatamente al mittente distruggendone l'originale. > > Grazie per la collaborazione. > > > 2013/12/9 Fabrizio Montesi <fam...@gm... > <mailto:fam...@gm...>> > > Hi all, > > @Claudio: do you have any info on that line? > > Cheers, > Fabrizio. > > On Wed, Dec 4, 2013 at 5:50 PM, Matthias Dieter Wallnöfer > <mwa...@ya... <mailto:mwa...@ya...>> wrote: > > Any news on this one (and also on the Exception thing: Re: > [Jolie-devel] > > OneWay messages)? > > > > Matthias > > > > Fabrizio Montesi schrieb: > > > >> Hi all, > >> I'm trying to see why that line has been commented... > especially since > >> it has been commented without leaving any other comment > explaining the > >> reason in the code. Claudio, any memories? :-) > >> > >> I see it's commented out in many parts of the code. > >> > >> > >> Cheers, > >> Fabrizio. > > > > > > |
From: Claudio G. <cg...@it...> - 2013-12-10 08:43:24
|
Hi all, sorry for the delay. Do you mean this line? jolieTypes.add( createAnyOrUndefined( element.getName(), complexType ) ); If I remember well it was commented because, otherwise, you will find type undefined: undefined into the generated interface. -------------------------------------------------------------- Claudio Guidi Ph.D. italianaSoftware s.r.l. via Coralli, 66 - 40026 Imola (BO), Italy http://www.italianasoftware.com/ http://www.jolie-lang.org Phone: +39 0542 788201 Mobile: +39 347 0694065 Fax: +39 0542 628048 -------------------------------------------------------------- Nota di riservatezza: Il presente messaggio, corredato dei relativi allegati, contiene informazioni da considerarsi strettamente riservate, ed è destinato esclusivamente al destinatario sopra indicato, il quale è l'unico autorizzato ad usarlo, copiarlo e, sotto la propria responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per errore o comunque lo leggesse senza esserne legittimato è avvertito che trattenerlo, copiarlo,divulgarlo, distribuirlo a persone diverse dal destinatario è severamente proibito, ed è pregato di rinviarlo immediatamente al mittente distruggendone l'originale. Grazie per la collaborazione. 2013/12/9 Fabrizio Montesi <fam...@gm...> > Hi all, > > @Claudio: do you have any info on that line? > > Cheers, > Fabrizio. > > On Wed, Dec 4, 2013 at 5:50 PM, Matthias Dieter Wallnöfer > <mwa...@ya...> wrote: > > Any news on this one (and also on the Exception thing: Re: [Jolie-devel] > > OneWay messages)? > > > > Matthias > > > > Fabrizio Montesi schrieb: > > > >> Hi all, > >> I'm trying to see why that line has been commented... especially since > >> it has been commented without leaving any other comment explaining the > >> reason in the code. Claudio, any memories? :-) > >> > >> I see it's commented out in many parts of the code. > >> > >> > >> Cheers, > >> Fabrizio. > > > > > |
From: Fabrizio M. <fam...@gm...> - 2013-12-09 18:26:15
|
Hi Matthias, sorry for the late reply, I've been pretty busy with my PhD. Yes, I think that could work! Wanna try change SODEPProtocol? I think that a possible fix could be to catch EOFException there in the first read (that for the message id) and rethrow it as a ChannelClosedException. Cheers, Fabrizio. On Fri, Nov 29, 2013 at 10:08 AM, Matthias Dieter Wallnöfer <mwa...@ya...> wrote: > Any news on this one? > > Matthias Dieter Wallnöfer schrieb: > >> Hi Fabrizio, >> >> yes, the easiest would be to extend ChannelClosedException from >> EOFException? So very little changes would be necessary. Otherwise we >> would need to extend each method's signature. >> >> Cheers, >> Matthias >> >> Fabrizio Montesi schrieb: >>> >>> Hi Matthias, >>> yeah, we have an annoying bug that doesn't really hurt but appears >>> like that (just prints that on screen) depending on the underlying OS >>> and network. It is consistent when using localhost afaik. >>> >>> Basically, every output port channel is handled by a separate thread, >>> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for >>> new messages on the channel and puts them in cache when the >>> interpreter is ready to receive a response for an operation (in the >>> case of one-way such responses are just ACKs that the messages have >>> been put in the channel cache on the other side). >>> >>> So, you have that thread on the client waiting on the channel, and the >>> server suddenly goes down because it terminates execution. Then, the >>> client throws that exception. >>> >>> The problem in handling this gracefully is that we should >>> differentiate between an EOFException that we get in the middle of >>> parsing a received message in a protocol (e.g., SODEP, but more in >>> general CommProtocol.recv()), or the same exception got when trying to >>> receive the first bit of information (which is your case if you look >>> at the source code at SodepProtocol.java:252). >>> Then, the protocol could throw a custom exception that we create >>> (ChannelClosedException?) representing a graceful channel closing and >>> catch it from jolie.net.AbstractCommChannel$ResponseReceiver. >>> >>> Let me know if you'd be interested in tackling this. >>> >>> Cheers, >>> Fabrizio. >>> >>> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer >>> <mwa...@ya...> wrote: >>>> >>>> Hi Fabrizio, >>>> >>>> this works well, but on the client side >>>>> >>>>> main >>>>> { >>>>> twice@TwiceService( 5 ) >>>>> } >>>> >>>> I get a Java EOF exception. I imagine that this could be a coordination >>>> issue? >>>>> >>>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning >>>>> WARNING: [client.ol] java.io.EOFException >>>>> at java.io.DataInputStream.readFully(DataInputStream.java:197) >>>>> at java.io.DataInputStream.readLong(DataInputStream.java:416) >>>>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) >>>>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) >>>>> at >>>>> jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) >>>>> at jolie.net.CommChannel.recv(CommChannel.java:198) >>>>> at >>>>> >>>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) >>>>> at >>>>> >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>> at >>>>> >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>> at java.lang.Thread.run(Thread.java:724) >>>> >>>> Cheers, >>>> Matthias >>>> >>>> Fabrizio Montesi schrieb: >>>> >>>>> Hi Matthias, >>>>> this: >>>>>> >>>>>> twice( number ) { >>>>>> result = number * 2; >>>>>> println@Console( result )(); >>>>>> } >>>>> >>>>> is not a construct in the language. Request-Response operations >>>>> support the { block } construct because it is useful to specify >>>>> something to happen *in-between* the request and the response. For >>>>> one-ways this is not necessary because they just receive something. >>>>> Hence you can just use the semicolon operator for expressing a >>>>> sequence and obtain what you want: >>>>> >>>>> twice( number ); >>>>> result = number * 2; >>>>> println@Console( result )() >>>>> >>>>> >>>>> Cheers, >>>>> Fabrizio. >>>>> >>>>> >>>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer >>>>> <mwa...@ya...> wrote: >>>>>> >>>>>> Hi developers, >>>>>> >>>>>> I got another question: in >>>>>> >>>>>> >>>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment >>>>>> we have a simple client-server example: >>>>>>> >>>>>>> |main| >>>>>>> |{| >>>>>>> |||twice( number )( response ) {| >>>>>>> |||response = number * ||2| >>>>>>> |||}| >>>>>>> |}| >>>>>> >>>>>> But when I change it to be one-way I run into trouble: >>>>>>> >>>>>>> interface TwiceInterface { >>>>>>> OneWay: twice( int ) >>>>>>> } >>>>>> >>>>>> and >>>>>>> >>>>>>> main >>>>>>> { >>>>>>> twice( number ) { >>>>>>> result = number * 2; >>>>>>> println@Console( result )(); >>>>>>> } >>>>>>> } >>>>>> >>>>>> does not work. Why? >>>>>> >>>>>> Do I need something like this? >>>>>>> >>>>>>> main >>>>>>> { >>>>>>> [ twice( number ) ] { >>>>>>> result = number * 2; >>>>>>> println@Console( result )(); >>>>>>> } >>>>>>> } >>>>>> >>>>>> Cheers, >>>>>> Matthias >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Shape the Mobile Experience: Free Subscription >>>>>> Software experts and developers: Be at the forefront of tech >>>>>> innovation. >>>>>> Intel(R) Software Adrenaline delivers strategic insight and >>>>>> game-changing >>>>>> conversations that shape the rapidly evolving mobile landscape. Sign >>>>>> up >>>>>> now. >>>>>> >>>>>> >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>>> _______________________________________________ >>>>>> Jolie-devel mailing list >>>>>> Jol...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel >> >> >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up >> now. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Jolie-devel mailing list >> Jol...@li... >> https://lists.sourceforge.net/lists/listinfo/jolie-devel > > |
From: Fabrizio M. <fam...@gm...> - 2013-12-09 18:22:33
|
Hi all, @Claudio: do you have any info on that line? Cheers, Fabrizio. On Wed, Dec 4, 2013 at 5:50 PM, Matthias Dieter Wallnöfer <mwa...@ya...> wrote: > Any news on this one (and also on the Exception thing: Re: [Jolie-devel] > OneWay messages)? > > Matthias > > Fabrizio Montesi schrieb: > >> Hi all, >> I'm trying to see why that line has been commented... especially since >> it has been commented without leaving any other comment explaining the >> reason in the code. Claudio, any memories? :-) >> >> I see it's commented out in many parts of the code. >> >> >> Cheers, >> Fabrizio. > > |
From: Matthias D. W. <mwa...@ya...> - 2013-12-04 16:50:23
|
Any news on this one (and also on the Exception thing: Re: [Jolie-devel] OneWay messages)? Matthias Fabrizio Montesi schrieb: > Hi all, > I'm trying to see why that line has been commented... especially since > it has been commented without leaving any other comment explaining the > reason in the code. Claudio, any memories? :-) > > I see it's commented out in many parts of the code. > > > Cheers, > Fabrizio. |
From: Matthias D. W. <mwa...@ya...> - 2013-11-29 09:08:29
|
Any news on this one? Matthias Dieter Wallnöfer schrieb: > Hi Fabrizio, > > yes, the easiest would be to extend ChannelClosedException from > EOFException? So very little changes would be necessary. Otherwise we > would need to extend each method's signature. > > Cheers, > Matthias > > Fabrizio Montesi schrieb: >> Hi Matthias, >> yeah, we have an annoying bug that doesn't really hurt but appears >> like that (just prints that on screen) depending on the underlying OS >> and network. It is consistent when using localhost afaik. >> >> Basically, every output port channel is handled by a separate thread, >> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for >> new messages on the channel and puts them in cache when the >> interpreter is ready to receive a response for an operation (in the >> case of one-way such responses are just ACKs that the messages have >> been put in the channel cache on the other side). >> >> So, you have that thread on the client waiting on the channel, and the >> server suddenly goes down because it terminates execution. Then, the >> client throws that exception. >> >> The problem in handling this gracefully is that we should >> differentiate between an EOFException that we get in the middle of >> parsing a received message in a protocol (e.g., SODEP, but more in >> general CommProtocol.recv()), or the same exception got when trying to >> receive the first bit of information (which is your case if you look >> at the source code at SodepProtocol.java:252). >> Then, the protocol could throw a custom exception that we create >> (ChannelClosedException?) representing a graceful channel closing and >> catch it from jolie.net.AbstractCommChannel$ResponseReceiver. >> >> Let me know if you'd be interested in tackling this. >> >> Cheers, >> Fabrizio. >> >> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer >> <mwa...@ya...> wrote: >>> Hi Fabrizio, >>> >>> this works well, but on the client side >>>> main >>>> { >>>> twice@TwiceService( 5 ) >>>> } >>> I get a Java EOF exception. I imagine that this could be a coordination >>> issue? >>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning >>>> WARNING: [client.ol] java.io.EOFException >>>> at java.io.DataInputStream.readFully(DataInputStream.java:197) >>>> at java.io.DataInputStream.readLong(DataInputStream.java:416) >>>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) >>>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) >>>> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) >>>> at jolie.net.CommChannel.recv(CommChannel.java:198) >>>> at >>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>> at java.lang.Thread.run(Thread.java:724) >>> Cheers, >>> Matthias >>> >>> Fabrizio Montesi schrieb: >>> >>>> Hi Matthias, >>>> this: >>>>> twice( number ) { >>>>> result = number * 2; >>>>> println@Console( result )(); >>>>> } >>>> is not a construct in the language. Request-Response operations >>>> support the { block } construct because it is useful to specify >>>> something to happen *in-between* the request and the response. For >>>> one-ways this is not necessary because they just receive something. >>>> Hence you can just use the semicolon operator for expressing a >>>> sequence and obtain what you want: >>>> >>>> twice( number ); >>>> result = number * 2; >>>> println@Console( result )() >>>> >>>> >>>> Cheers, >>>> Fabrizio. >>>> >>>> >>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer >>>> <mwa...@ya...> wrote: >>>>> Hi developers, >>>>> >>>>> I got another question: in >>>>> >>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment >>>>> we have a simple client-server example: >>>>>> |main| >>>>>> |{| >>>>>> |||twice( number )( response ) {| >>>>>> |||response = number * ||2| >>>>>> |||}| >>>>>> |}| >>>>> But when I change it to be one-way I run into trouble: >>>>>> interface TwiceInterface { >>>>>> OneWay: twice( int ) >>>>>> } >>>>> and >>>>>> main >>>>>> { >>>>>> twice( number ) { >>>>>> result = number * 2; >>>>>> println@Console( result )(); >>>>>> } >>>>>> } >>>>> does not work. Why? >>>>> >>>>> Do I need something like this? >>>>>> main >>>>>> { >>>>>> [ twice( number ) ] { >>>>>> result = number * 2; >>>>>> println@Console( result )(); >>>>>> } >>>>>> } >>>>> Cheers, >>>>> Matthias >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Shape the Mobile Experience: Free Subscription >>>>> Software experts and developers: Be at the forefront of tech innovation. >>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>>> conversations that shape the rapidly evolving mobile landscape. Sign up >>>>> now. >>>>> >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Jolie-devel mailing list >>>>> Jol...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Jolie-devel mailing list > Jol...@li... > https://lists.sourceforge.net/lists/listinfo/jolie-devel |
From: Fabrizio M. <fam...@gm...> - 2013-11-25 08:40:32
|
Hi all, I'm trying to see why that line has been commented... especially since it has been commented without leaving any other comment explaining the reason in the code. Claudio, any memories? :-) I see it's commented out in many parts of the code. Cheers, Fabrizio. |
From: Matthias D. W. <mwa...@ya...> - 2013-11-22 16:56:31
|
Hi Claudio, "any" does work too (beside "void"). I have made a mistake and posted the wrong error message (since I did some hack-patching before): the correct one refers to the fields and not the whole structure. Bye, Matthias Claudio Guidi schrieb: > Hi Matthias, > > the TypeChecking error you receive is about the native type of the root > GetCityWeatherByZIPResult and not about the subfields <Visibility/>< > WindChill/> and <Remarks/>. Thus I don't understand why it works if > you change > the types of those fields from string to void. > > Neverthless, at the present it is not possible to express in jolie > something like this: > > .mysubfield: string + void (which means a string or a void native type) > > We are planning to introduce such a kind of choice operator for types > in the near future. > Now, you could use native type *any* for expressing the possibility to > have both a string or a void. > > .mysubfield: any > > any means any kind of native type. > In your case it should be: > > > .WeatherID:int > > .Description?:string > > .State?:string > > .ResponseText?:string > > .RelativeHumidity?:string > > .WindChill?:any > > .Temperature?:string > > .Remarks?:any > > .Visibility?:any > > .Pressure?:string > > .Success:bool > > .WeatherStationCity?:string > > .Wind?:string > > .City?:string > > Let me know if it works, > Bye > Claudio > > > > > > > > -------------------------------------------------------------- > Claudio Guidi Ph.D. > italianaSoftware s.r.l. > via Coralli, 66 - 40026 Imola (BO), Italy > http://www.italianasoftware.com/ > http://www.jolie-lang.org <http://www.jolie-lang.org/> > Phone: +39 0542 788201 > Mobile: +39 347 0694065 > Fax: +39 0542 628048 > -------------------------------------------------------------- > > Nota di riservatezza: Il presente messaggio, corredato dei > relativi allegati, contiene informazioni da considerarsi strettamente > riservate, ed è destinato esclusivamente al destinatario sopra > indicato, il quale è l'unico autorizzato ad usarlo, copiarlo e, sotto > la propria responsabilità,diffonderlo. Chiunque ricevesse questo > messaggio per errore o comunque lo leggesse senza esserne legittimato > è avvertito che trattenerlo, copiarlo,divulgarlo, distribuirlo a > persone diverse dal destinatario è severamente proibito, ed è pregato > di rinviarlo immediatamente al mittente distruggendone l'originale. > > Grazie per la collaborazione. > > > 2013/11/22 Matthias Dieter Wallnöfer <mwa...@ya... > <mailto:mwa...@ya...>> > > Hi devs, > > I have another interesting issue in respect to SOAP. > > Webservice: http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL > > The type declaration of "WeatherReturnType" (for call > GetCityWeatherByZIP()) determined by wsdl2jolie (which is correct > if you > have a look at the WSDL file - > http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL! > <http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL%21>): > > type WeatherReturnType:void { > > .WeatherID:int > > .Description?:string > > .State?:string > > .ResponseText?:string > > .RelativeHumidity?:string > > .WindChill?:string > > .Temperature?:string > > .Remarks?:string > > .Visibility?:string > > .Pressure?:string > > .Success:bool > > .WeatherStationCity?:string > > .Wind?:string > > .City?:string > > } > A possible result of GetCityWeatherByZIP(): > > <WeatherReturn><Success>true</Success><ResponseText>City > > Found</ResponseText><State>NY</State><City>New > > York</City><WeatherStationCity>White > > > Plains</WeatherStationCity><WeatherID>14</WeatherID><Description>Cloudy</Description><Temperature>46</Temperature><RelativeHumidity>89</RelativeHumidity><Wind>S3</Wind><Pressure>30.21F</Pressure><Visibility/><WindChill/><Remarks/></WeatherReturn> > Jolie blames about the <.../> since it recognizes them as VOIDs > not strings: > > WARNING: [weatherServiceCallerNYC.ol] Received message TypeMismatch > > (GetCityWeatherByZIP@WeatherSoap): Invalid native type for node > > #Message.GetCityWeatherByZIPResult: expected VOID, found > java.lang.String > I have tried to look into the code but there does not seem to be > an easy > solution. As a workaround I can change the datatype of the "<.../>" > fields in the type stucture to VOID - then everything works. > > Does there exist something different? > > Cheers, > Matthias > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech > innovation. > Intel(R) Software Adrenaline delivers strategic insight and > game-changing > conversations that shape the rapidly evolving mobile landscape. > Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Jolie-devel mailing list > Jol...@li... > <mailto:Jol...@li...> > https://lists.sourceforge.net/lists/listinfo/jolie-devel > > |
From: Claudio G. <cg...@it...> - 2013-11-22 16:32:57
|
Hi Matthias, the TypeChecking error you receive is about the native type of the root GetCityWeatherByZIPResult and not about the subfields <Visibility/>< WindChill/> and <Remarks/>. Thus I don't understand why it works if you change the types of those fields from string to void. Neverthless, at the present it is not possible to express in jolie something like this: .mysubfield: string + void (which means a string or a void native type) We are planning to introduce such a kind of choice operator for types in the near future. Now, you could use native type *any* for expressing the possibility to have both a string or a void. .mysubfield: any any means any kind of native type. In your case it should be: > .WeatherID:int > .Description?:string > .State?:string > .ResponseText?:string > .RelativeHumidity?:string > .WindChill?:any > .Temperature?:string > .Remarks?:any > .Visibility?:any > .Pressure?:string > .Success:bool > .WeatherStationCity?:string > .Wind?:string > .City?:string Let me know if it works, Bye Claudio -------------------------------------------------------------- Claudio Guidi Ph.D. italianaSoftware s.r.l. via Coralli, 66 - 40026 Imola (BO), Italy http://www.italianasoftware.com/ http://www.jolie-lang.org Phone: +39 0542 788201 Mobile: +39 347 0694065 Fax: +39 0542 628048 -------------------------------------------------------------- Nota di riservatezza: Il presente messaggio, corredato dei relativi allegati, contiene informazioni da considerarsi strettamente riservate, ed è destinato esclusivamente al destinatario sopra indicato, il quale è l'unico autorizzato ad usarlo, copiarlo e, sotto la propria responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per errore o comunque lo leggesse senza esserne legittimato è avvertito che trattenerlo, copiarlo,divulgarlo, distribuirlo a persone diverse dal destinatario è severamente proibito, ed è pregato di rinviarlo immediatamente al mittente distruggendone l'originale. Grazie per la collaborazione. 2013/11/22 Matthias Dieter Wallnöfer <mwa...@ya...> > Hi devs, > > I have another interesting issue in respect to SOAP. > > Webservice: http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL > > The type declaration of "WeatherReturnType" (for call > GetCityWeatherByZIP()) determined by wsdl2jolie (which is correct if you > have a look at the WSDL file - > http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL!): > > type WeatherReturnType:void { > > .WeatherID:int > > .Description?:string > > .State?:string > > .ResponseText?:string > > .RelativeHumidity?:string > > .WindChill?:string > > .Temperature?:string > > .Remarks?:string > > .Visibility?:string > > .Pressure?:string > > .Success:bool > > .WeatherStationCity?:string > > .Wind?:string > > .City?:string > > } > A possible result of GetCityWeatherByZIP(): > > <WeatherReturn><Success>true</Success><ResponseText>City > > Found</ResponseText><State>NY</State><City>New > > York</City><WeatherStationCity>White > > > Plains</WeatherStationCity><WeatherID>14</WeatherID><Description>Cloudy</Description><Temperature>46</Temperature><RelativeHumidity>89</RelativeHumidity><Wind>S3</Wind><Pressure>30.21F</Pressure><Visibility/><WindChill/><Remarks/></WeatherReturn> > Jolie blames about the <.../> since it recognizes them as VOIDs not > strings: > > WARNING: [weatherServiceCallerNYC.ol] Received message TypeMismatch > > (GetCityWeatherByZIP@WeatherSoap): Invalid native type for node > > #Message.GetCityWeatherByZIPResult: expected VOID, found java.lang.String > I have tried to look into the code but there does not seem to be an easy > solution. As a workaround I can change the datatype of the "<.../>" > fields in the type stucture to VOID - then everything works. > > Does there exist something different? > > Cheers, > Matthias > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up > now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Jolie-devel mailing list > Jol...@li... > https://lists.sourceforge.net/lists/listinfo/jolie-devel > |
From: Matthias D. W. <mwa...@ya...> - 2013-11-22 15:37:34
|
Hi devs, I have another interesting issue in respect to SOAP. Webservice: http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL The type declaration of "WeatherReturnType" (for call GetCityWeatherByZIP()) determined by wsdl2jolie (which is correct if you have a look at the WSDL file - http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL!): > type WeatherReturnType:void { > .WeatherID:int > .Description?:string > .State?:string > .ResponseText?:string > .RelativeHumidity?:string > .WindChill?:string > .Temperature?:string > .Remarks?:string > .Visibility?:string > .Pressure?:string > .Success:bool > .WeatherStationCity?:string > .Wind?:string > .City?:string > } A possible result of GetCityWeatherByZIP(): > <WeatherReturn><Success>true</Success><ResponseText>City > Found</ResponseText><State>NY</State><City>New > York</City><WeatherStationCity>White > Plains</WeatherStationCity><WeatherID>14</WeatherID><Description>Cloudy</Description><Temperature>46</Temperature><RelativeHumidity>89</RelativeHumidity><Wind>S3</Wind><Pressure>30.21F</Pressure><Visibility/><WindChill/><Remarks/></WeatherReturn> Jolie blames about the <.../> since it recognizes them as VOIDs not strings: > WARNING: [weatherServiceCallerNYC.ol] Received message TypeMismatch > (GetCityWeatherByZIP@WeatherSoap): Invalid native type for node > #Message.GetCityWeatherByZIPResult: expected VOID, found java.lang.String I have tried to look into the code but there does not seem to be an easy solution. As a workaround I can change the datatype of the "<.../>" fields in the type stucture to VOID - then everything works. Does there exist something different? Cheers, Matthias |
From: Matthias D. W. <mwa...@ya...> - 2013-11-22 13:37:21
|
So what do you think about this patch? Cheers, Matthias Matthias Dieter Wallnöfer schrieb: > Sorry :-), > > Matthias > > Claudio Guidi schrieb: >> Hi All, >> >> I think that in this particular case we could assume that an element >> like: >> >> <s:element name="GetWeatherInformation"><s:complexType/></s:element> >> >> could be considered as a void in Jolie. >> >> >> >> -------------------------------------------------------------- >> Claudio Guidi Ph.D. >> italianaSoftware s.r.l. >> via Coralli, 66 - 40026 Imola (BO), Italy >> http://www.italianasoftware.com/ >> http://www.jolie-lang.org <http://www.jolie-lang.org/> >> Phone: +39 0542 788201 >> Mobile: +39 347 0694065 >> Fax: +39 0542 628048 >> -------------------------------------------------------------- >> >> Nota di riservatezza: Il presente messaggio, corredato dei relativi >> allegati, contiene informazioni da considerarsi strettamente >> riservate, ed è destinato esclusivamente al destinatario sopra >> indicato, il quale è l'unico autorizzato ad usarlo, copiarlo e, sotto >> la propria responsabilità,diffonderlo. Chiunque ricevesse questo >> messaggio per errore o comunque lo leggesse senza esserne legittimato >> è avvertito che trattenerlo, copiarlo,divulgarlo, distribuirlo a >> persone diverse dal destinatario è severamente proibito, ed è pregato >> di rinviarlo immediatamente al mittente distruggendone l'originale. >> >> Grazie per la collaborazione. >> >> >> 2013/11/20 Fabrizio Montesi <fam...@gm... >> <mailto:fam...@gm...>> >> >> Hi Matthias, >> yes, the problem is that complex types in general go out of the >> types >> supported by Jolie (since they are not structured, afaik). >> However, we >> can certainly work out some cases that we can support in our types. >> For example, an empty complex type corresponds to a void as you >> point >> out. >> >> When we are dealing with an unsupported type (as you encountered) we >> should throw an exception though... it's better than outputting >> something incorrect. >> Or, even better, when we find out something that we do not know >> how to >> deal with we should print "undefined" as type. >> >> Could I see your modification? >> >> Cheers, >> Fabrizio. >> >> On Wed, Nov 20, 2013 at 12:36 PM, Matthias Dieter Wallnöfer >> <mwa...@ya... <mailto:mwa...@ya...>> wrote: >> > Hi Fabrizio, >> > >> > when dealing with another webservice I ran into some issues using >> > wsdl2jolie. >> > >> > Address: http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL >> > >> > - At the moment the tool suppresses undefined complex types. >> This does not >> > work out with the SOAP call "GetWeatherInformation()" - since >> then it is >> > missing its input argument datatype >> > - When the same call is run by other methods (eg. HTTP) it has >> some kind of >> > empty input type associated. At the moment the tool prints a >> declaration >> > like: >> >> >> >> GetWeatherInformation()(ArrayOfWeatherDescription) >> > >> > which is denied by Jolie. With a slight change I get a "void" >> type: >> >> >> >> GetWeatherInformation(void)(ArrayOfWeatherDescription) >> > >> > >> > Cheers, >> > Matthias >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech >> innovation. >> Intel(R) Software Adrenaline delivers strategic insight and >> game-changing >> conversations that shape the rapidly evolving mobile landscape. >> Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Jolie-devel mailing list >> Jol...@li... >> <mailto:Jol...@li...> >> https://lists.sourceforge.net/lists/listinfo/jolie-devel >> >> > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > > > _______________________________________________ > Jolie-devel mailing list > Jol...@li... > https://lists.sourceforge.net/lists/listinfo/jolie-devel |
From: Matthias D. W. <mwa...@ya...> - 2013-11-21 17:19:48
|
Hi Fabrizio, yes, the easiest would be to extend ChannelClosedException from EOFException? So very little changes would be necessary. Otherwise we would need to extend each method's signature. Cheers, Matthias Fabrizio Montesi schrieb: > Hi Matthias, > yeah, we have an annoying bug that doesn't really hurt but appears > like that (just prints that on screen) depending on the underlying OS > and network. It is consistent when using localhost afaik. > > Basically, every output port channel is handled by a separate thread, > that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for > new messages on the channel and puts them in cache when the > interpreter is ready to receive a response for an operation (in the > case of one-way such responses are just ACKs that the messages have > been put in the channel cache on the other side). > > So, you have that thread on the client waiting on the channel, and the > server suddenly goes down because it terminates execution. Then, the > client throws that exception. > > The problem in handling this gracefully is that we should > differentiate between an EOFException that we get in the middle of > parsing a received message in a protocol (e.g., SODEP, but more in > general CommProtocol.recv()), or the same exception got when trying to > receive the first bit of information (which is your case if you look > at the source code at SodepProtocol.java:252). > Then, the protocol could throw a custom exception that we create > (ChannelClosedException?) representing a graceful channel closing and > catch it from jolie.net.AbstractCommChannel$ResponseReceiver. > > Let me know if you'd be interested in tackling this. > > Cheers, > Fabrizio. > > On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer > <mwa...@ya...> wrote: >> Hi Fabrizio, >> >> this works well, but on the client side >>> main >>> { >>> twice@TwiceService( 5 ) >>> } >> I get a Java EOF exception. I imagine that this could be a coordination >> issue? >>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning >>> WARNING: [client.ol] java.io.EOFException >>> at java.io.DataInputStream.readFully(DataInputStream.java:197) >>> at java.io.DataInputStream.readLong(DataInputStream.java:416) >>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) >>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) >>> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) >>> at jolie.net.CommChannel.recv(CommChannel.java:198) >>> at >>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> at java.lang.Thread.run(Thread.java:724) >> Cheers, >> Matthias >> >> Fabrizio Montesi schrieb: >> >>> Hi Matthias, >>> this: >>>> twice( number ) { >>>> result = number * 2; >>>> println@Console( result )(); >>>> } >>> is not a construct in the language. Request-Response operations >>> support the { block } construct because it is useful to specify >>> something to happen *in-between* the request and the response. For >>> one-ways this is not necessary because they just receive something. >>> Hence you can just use the semicolon operator for expressing a >>> sequence and obtain what you want: >>> >>> twice( number ); >>> result = number * 2; >>> println@Console( result )() >>> >>> >>> Cheers, >>> Fabrizio. >>> >>> >>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer >>> <mwa...@ya...> wrote: >>>> Hi developers, >>>> >>>> I got another question: in >>>> >>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment >>>> we have a simple client-server example: >>>>> |main| >>>>> |{| >>>>> |||twice( number )( response ) {| >>>>> |||response = number * ||2| >>>>> |||}| >>>>> |}| >>>> But when I change it to be one-way I run into trouble: >>>>> interface TwiceInterface { >>>>> OneWay: twice( int ) >>>>> } >>>> and >>>>> main >>>>> { >>>>> twice( number ) { >>>>> result = number * 2; >>>>> println@Console( result )(); >>>>> } >>>>> } >>>> does not work. Why? >>>> >>>> Do I need something like this? >>>>> main >>>>> { >>>>> [ twice( number ) ] { >>>>> result = number * 2; >>>>> println@Console( result )(); >>>>> } >>>>> } >>>> Cheers, >>>> Matthias >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Shape the Mobile Experience: Free Subscription >>>> Software experts and developers: Be at the forefront of tech innovation. >>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>> conversations that shape the rapidly evolving mobile landscape. Sign up >>>> now. >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Jolie-devel mailing list >>>> Jol...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel >> |
From: Matthias D. W. <mwa...@ya...> - 2013-11-21 16:54:48
|
Indeed, this would be a good idea. Cheers, Matthias Saverio Giallorenzo schrieb: > My proposal is to add a section after "Creating a communication port"[1] > that specifies how ports are used for input/output (via operations). > If you have any ideas or want to write a first draft to discuss on > you are very welcome :) > > [1] > http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=basics/communication_ports#creating-a-communication-port > > > > 2013/11/21 Saverio Giallorenzo <sav...@gm... > <mailto:sav...@gm...>> > > Ok, > I will sort out something. > > SG > > > 2013/11/21 Fabrizio Montesi <fam...@gm... > <mailto:fam...@gm...>> > > Seems OK! Saverio, is it possible to put it as an aside tip, > not to > confuse the reader? > > Also, "would be defined" => "were defined" > > > - Fabrizio > > On Thu, Nov 21, 2013 at 12:29 PM, Matthias Dieter Wallnöfer > <mwa...@ya... <mailto:mwa...@ya...>> wrote: > > Hi Fabrizio & Saverio, > > > > I would propose some doc change to clear this one - since it > did not seem > > obvious to me. > > > > Cheers, > > Matthias > > > > Matthias Dieter Wallnöfer schrieb: > >> > >> Hi Fabrizio, > >> > >> this works well, but on the client side > >>> > >>> main > >>> { > >>> twice@TwiceService( 5 ) > >>> } > >> > >> I get a Java EOF exception. I imagine that this could be a > coordination > >> issue? > >>> > >>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning > >>> WARNING: [client.ol] java.io.EOFException > >>> at > java.io.DataInputStream.readFully(DataInputStream.java:197) > >>> at > java.io.DataInputStream.readLong(DataInputStream.java:416) > >>> at > jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) > >>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) > >>> at > jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) > >>> at jolie.net.CommChannel.recv(CommChannel.java:198) > >>> at > >>> > >>> > jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) > >>> at > >>> > >>> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > >>> at > >>> > >>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > >>> at java.lang.Thread.run(Thread.java:724) > >> > >> Cheers, > >> Matthias > >> > >> Fabrizio Montesi schrieb: > >>> > >>> Hi Matthias, > >>> this: > >>>> > >>>> twice( number ) { > >>>> result = number * 2; > >>>> println@Console( result )(); > >>>> } > >>> > >>> is not a construct in the language. Request-Response > operations > >>> support the { block } construct because it is useful to > specify > >>> something to happen *in-between* the request and the > response. For > >>> one-ways this is not necessary because they just receive > something. > >>> Hence you can just use the semicolon operator for expressing a > >>> sequence and obtain what you want: > >>> > >>> twice( number ); > >>> result = number * 2; > >>> println@Console( result )() > >>> > >>> > >>> Cheers, > >>> Fabrizio. > >>> > >>> > >>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer > >>> <mwa...@ya... <mailto:mwa...@ya...>> wrote: > >>>> > >>>> Hi developers, > >>>> > >>>> I got another question: in > >>>> > >>>> > http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment > >>>> we have a simple client-server example: > >>>>> > >>>>> |main| > >>>>> |{| > >>>>> |||twice( number )( response ) {| > >>>>> |||response = number * ||2| > >>>>> |||}| > >>>>> |}| > >>>> > >>>> But when I change it to be one-way I run into trouble: > >>>>> > >>>>> interface TwiceInterface { > >>>>> OneWay: twice( int ) > >>>>> } > >>>> > >>>> and > >>>>> > >>>>> main > >>>>> { > >>>>> twice( number ) { > >>>>> result = number * 2; > >>>>> println@Console( result )(); > >>>>> } > >>>>> } > >>>> > >>>> does not work. Why? > >>>> > >>>> Do I need something like this? > >>>>> > >>>>> main > >>>>> { > >>>>> [ twice( number ) ] { > >>>>> result = number * 2; > >>>>> println@Console( result )(); > >>>>> } > >>>>> } > >>>> > >>>> Cheers, > >>>> Matthias > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> Shape the Mobile Experience: Free Subscription > >>>> Software experts and developers: Be at the forefront of > tech innovation. > >>>> Intel(R) Software Adrenaline delivers strategic insight and > >>>> game-changing > >>>> conversations that shape the rapidly evolving mobile > landscape. Sign up > >>>> now. > >>>> > >>>> > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > >>>> _______________________________________________ > >>>> Jolie-devel mailing list > >>>> Jol...@li... > <mailto:Jol...@li...> > >>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> Shape the Mobile Experience: Free Subscription > >> Software experts and developers: Be at the forefront of > tech innovation. > >> Intel(R) Software Adrenaline delivers strategic insight and > game-changing > >> conversations that shape the rapidly evolving mobile > landscape. Sign up > >> now. > >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Jolie-devel mailing list > >> Jol...@li... > <mailto:Jol...@li...> > >> https://lists.sourceforge.net/lists/listinfo/jolie-devel > > > > > > > |
From: Saverio G. <sav...@gm...> - 2013-11-21 15:10:17
|
Matthias, Fabrizio and I had a talk and sorted out that what you highlighted is an important lack in the documentation which is the description of the syntax and some examples of the usage of one-way and request-response operations. My proposal is to add a section after "Creating a communication port"[1] that specifies how ports are used for input/output (via operations). If you have any ideas or want to write a first draft to discuss on you are very welcome :) [1] http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=basics/communication_ports#creating-a-communication-port 2013/11/21 Saverio Giallorenzo <sav...@gm...> > Ok, > I will sort out something. > > SG > > > 2013/11/21 Fabrizio Montesi <fam...@gm...> > >> Seems OK! Saverio, is it possible to put it as an aside tip, not to >> confuse the reader? >> >> Also, "would be defined" => "were defined" >> >> >> - Fabrizio >> >> On Thu, Nov 21, 2013 at 12:29 PM, Matthias Dieter Wallnöfer >> <mwa...@ya...> wrote: >> > Hi Fabrizio & Saverio, >> > >> > I would propose some doc change to clear this one - since it did not >> seem >> > obvious to me. >> > >> > Cheers, >> > Matthias >> > >> > Matthias Dieter Wallnöfer schrieb: >> >> >> >> Hi Fabrizio, >> >> >> >> this works well, but on the client side >> >>> >> >>> main >> >>> { >> >>> twice@TwiceService( 5 ) >> >>> } >> >> >> >> I get a Java EOF exception. I imagine that this could be a coordination >> >> issue? >> >>> >> >>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning >> >>> WARNING: [client.ol] java.io.EOFException >> >>> at java.io.DataInputStream.readFully(DataInputStream.java:197) >> >>> at java.io.DataInputStream.readLong(DataInputStream.java:416) >> >>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) >> >>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) >> >>> at >> jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) >> >>> at jolie.net.CommChannel.recv(CommChannel.java:198) >> >>> at >> >>> >> >>> >> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) >> >>> at >> >>> >> >>> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> >>> at >> >>> >> >>> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> >>> at java.lang.Thread.run(Thread.java:724) >> >> >> >> Cheers, >> >> Matthias >> >> >> >> Fabrizio Montesi schrieb: >> >>> >> >>> Hi Matthias, >> >>> this: >> >>>> >> >>>> twice( number ) { >> >>>> result = number * 2; >> >>>> println@Console( result )(); >> >>>> } >> >>> >> >>> is not a construct in the language. Request-Response operations >> >>> support the { block } construct because it is useful to specify >> >>> something to happen *in-between* the request and the response. For >> >>> one-ways this is not necessary because they just receive something. >> >>> Hence you can just use the semicolon operator for expressing a >> >>> sequence and obtain what you want: >> >>> >> >>> twice( number ); >> >>> result = number * 2; >> >>> println@Console( result )() >> >>> >> >>> >> >>> Cheers, >> >>> Fabrizio. >> >>> >> >>> >> >>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer >> >>> <mwa...@ya...> wrote: >> >>>> >> >>>> Hi developers, >> >>>> >> >>>> I got another question: in >> >>>> >> >>>> >> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment >> >>>> we have a simple client-server example: >> >>>>> >> >>>>> |main| >> >>>>> |{| >> >>>>> |||twice( number )( response ) {| >> >>>>> |||response = number * ||2| >> >>>>> |||}| >> >>>>> |}| >> >>>> >> >>>> But when I change it to be one-way I run into trouble: >> >>>>> >> >>>>> interface TwiceInterface { >> >>>>> OneWay: twice( int ) >> >>>>> } >> >>>> >> >>>> and >> >>>>> >> >>>>> main >> >>>>> { >> >>>>> twice( number ) { >> >>>>> result = number * 2; >> >>>>> println@Console( result )(); >> >>>>> } >> >>>>> } >> >>>> >> >>>> does not work. Why? >> >>>> >> >>>> Do I need something like this? >> >>>>> >> >>>>> main >> >>>>> { >> >>>>> [ twice( number ) ] { >> >>>>> result = number * 2; >> >>>>> println@Console( result )(); >> >>>>> } >> >>>>> } >> >>>> >> >>>> Cheers, >> >>>> Matthias >> >>>> >> >>>> >> >>>> >> ------------------------------------------------------------------------------ >> >>>> Shape the Mobile Experience: Free Subscription >> >>>> Software experts and developers: Be at the forefront of tech >> innovation. >> >>>> Intel(R) Software Adrenaline delivers strategic insight and >> >>>> game-changing >> >>>> conversations that shape the rapidly evolving mobile landscape. Sign >> up >> >>>> now. >> >>>> >> >>>> >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> >>>> _______________________________________________ >> >>>> Jolie-devel mailing list >> >>>> Jol...@li... >> >>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Shape the Mobile Experience: Free Subscription >> >> Software experts and developers: Be at the forefront of tech >> innovation. >> >> Intel(R) Software Adrenaline delivers strategic insight and >> game-changing >> >> conversations that shape the rapidly evolving mobile landscape. Sign up >> >> now. >> >> >> >> >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> >> Jolie-devel mailing list >> >> Jol...@li... >> >> https://lists.sourceforge.net/lists/listinfo/jolie-devel >> > >> > >> > > |
From: Saverio G. <sav...@gm...> - 2013-11-21 13:25:08
|
Ok, I will sort out something. SG 2013/11/21 Fabrizio Montesi <fam...@gm...> > Seems OK! Saverio, is it possible to put it as an aside tip, not to > confuse the reader? > > Also, "would be defined" => "were defined" > > > - Fabrizio > > On Thu, Nov 21, 2013 at 12:29 PM, Matthias Dieter Wallnöfer > <mwa...@ya...> wrote: > > Hi Fabrizio & Saverio, > > > > I would propose some doc change to clear this one - since it did not seem > > obvious to me. > > > > Cheers, > > Matthias > > > > Matthias Dieter Wallnöfer schrieb: > >> > >> Hi Fabrizio, > >> > >> this works well, but on the client side > >>> > >>> main > >>> { > >>> twice@TwiceService( 5 ) > >>> } > >> > >> I get a Java EOF exception. I imagine that this could be a coordination > >> issue? > >>> > >>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning > >>> WARNING: [client.ol] java.io.EOFException > >>> at java.io.DataInputStream.readFully(DataInputStream.java:197) > >>> at java.io.DataInputStream.readLong(DataInputStream.java:416) > >>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) > >>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) > >>> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) > >>> at jolie.net.CommChannel.recv(CommChannel.java:198) > >>> at > >>> > >>> > jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) > >>> at > >>> > >>> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > >>> at > >>> > >>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > >>> at java.lang.Thread.run(Thread.java:724) > >> > >> Cheers, > >> Matthias > >> > >> Fabrizio Montesi schrieb: > >>> > >>> Hi Matthias, > >>> this: > >>>> > >>>> twice( number ) { > >>>> result = number * 2; > >>>> println@Console( result )(); > >>>> } > >>> > >>> is not a construct in the language. Request-Response operations > >>> support the { block } construct because it is useful to specify > >>> something to happen *in-between* the request and the response. For > >>> one-ways this is not necessary because they just receive something. > >>> Hence you can just use the semicolon operator for expressing a > >>> sequence and obtain what you want: > >>> > >>> twice( number ); > >>> result = number * 2; > >>> println@Console( result )() > >>> > >>> > >>> Cheers, > >>> Fabrizio. > >>> > >>> > >>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer > >>> <mwa...@ya...> wrote: > >>>> > >>>> Hi developers, > >>>> > >>>> I got another question: in > >>>> > >>>> > http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment > >>>> we have a simple client-server example: > >>>>> > >>>>> |main| > >>>>> |{| > >>>>> |||twice( number )( response ) {| > >>>>> |||response = number * ||2| > >>>>> |||}| > >>>>> |}| > >>>> > >>>> But when I change it to be one-way I run into trouble: > >>>>> > >>>>> interface TwiceInterface { > >>>>> OneWay: twice( int ) > >>>>> } > >>>> > >>>> and > >>>>> > >>>>> main > >>>>> { > >>>>> twice( number ) { > >>>>> result = number * 2; > >>>>> println@Console( result )(); > >>>>> } > >>>>> } > >>>> > >>>> does not work. Why? > >>>> > >>>> Do I need something like this? > >>>>> > >>>>> main > >>>>> { > >>>>> [ twice( number ) ] { > >>>>> result = number * 2; > >>>>> println@Console( result )(); > >>>>> } > >>>>> } > >>>> > >>>> Cheers, > >>>> Matthias > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> Shape the Mobile Experience: Free Subscription > >>>> Software experts and developers: Be at the forefront of tech > innovation. > >>>> Intel(R) Software Adrenaline delivers strategic insight and > >>>> game-changing > >>>> conversations that shape the rapidly evolving mobile landscape. Sign > up > >>>> now. > >>>> > >>>> > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > >>>> _______________________________________________ > >>>> Jolie-devel mailing list > >>>> Jol...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> Shape the Mobile Experience: Free Subscription > >> Software experts and developers: Be at the forefront of tech innovation. > >> Intel(R) Software Adrenaline delivers strategic insight and > game-changing > >> conversations that shape the rapidly evolving mobile landscape. Sign up > >> now. > >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Jolie-devel mailing list > >> Jol...@li... > >> https://lists.sourceforge.net/lists/listinfo/jolie-devel > > > > > |
From: Fabrizio M. <fam...@gm...> - 2013-11-21 12:25:34
|
Seems OK! Saverio, is it possible to put it as an aside tip, not to confuse the reader? Also, "would be defined" => "were defined" - Fabrizio On Thu, Nov 21, 2013 at 12:29 PM, Matthias Dieter Wallnöfer <mwa...@ya...> wrote: > Hi Fabrizio & Saverio, > > I would propose some doc change to clear this one - since it did not seem > obvious to me. > > Cheers, > Matthias > > Matthias Dieter Wallnöfer schrieb: >> >> Hi Fabrizio, >> >> this works well, but on the client side >>> >>> main >>> { >>> twice@TwiceService( 5 ) >>> } >> >> I get a Java EOF exception. I imagine that this could be a coordination >> issue? >>> >>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning >>> WARNING: [client.ol] java.io.EOFException >>> at java.io.DataInputStream.readFully(DataInputStream.java:197) >>> at java.io.DataInputStream.readLong(DataInputStream.java:416) >>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) >>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) >>> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) >>> at jolie.net.CommChannel.recv(CommChannel.java:198) >>> at >>> >>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> at java.lang.Thread.run(Thread.java:724) >> >> Cheers, >> Matthias >> >> Fabrizio Montesi schrieb: >>> >>> Hi Matthias, >>> this: >>>> >>>> twice( number ) { >>>> result = number * 2; >>>> println@Console( result )(); >>>> } >>> >>> is not a construct in the language. Request-Response operations >>> support the { block } construct because it is useful to specify >>> something to happen *in-between* the request and the response. For >>> one-ways this is not necessary because they just receive something. >>> Hence you can just use the semicolon operator for expressing a >>> sequence and obtain what you want: >>> >>> twice( number ); >>> result = number * 2; >>> println@Console( result )() >>> >>> >>> Cheers, >>> Fabrizio. >>> >>> >>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer >>> <mwa...@ya...> wrote: >>>> >>>> Hi developers, >>>> >>>> I got another question: in >>>> >>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment >>>> we have a simple client-server example: >>>>> >>>>> |main| >>>>> |{| >>>>> |||twice( number )( response ) {| >>>>> |||response = number * ||2| >>>>> |||}| >>>>> |}| >>>> >>>> But when I change it to be one-way I run into trouble: >>>>> >>>>> interface TwiceInterface { >>>>> OneWay: twice( int ) >>>>> } >>>> >>>> and >>>>> >>>>> main >>>>> { >>>>> twice( number ) { >>>>> result = number * 2; >>>>> println@Console( result )(); >>>>> } >>>>> } >>>> >>>> does not work. Why? >>>> >>>> Do I need something like this? >>>>> >>>>> main >>>>> { >>>>> [ twice( number ) ] { >>>>> result = number * 2; >>>>> println@Console( result )(); >>>>> } >>>>> } >>>> >>>> Cheers, >>>> Matthias >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Shape the Mobile Experience: Free Subscription >>>> Software experts and developers: Be at the forefront of tech innovation. >>>> Intel(R) Software Adrenaline delivers strategic insight and >>>> game-changing >>>> conversations that shape the rapidly evolving mobile landscape. Sign up >>>> now. >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Jolie-devel mailing list >>>> Jol...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel >> >> >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up >> now. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Jolie-devel mailing list >> Jol...@li... >> https://lists.sourceforge.net/lists/listinfo/jolie-devel > > |
From: Fabrizio M. <fam...@gm...> - 2013-11-21 12:23:38
|
Hi Matthias, yeah, we have an annoying bug that doesn't really hurt but appears like that (just prints that on screen) depending on the underlying OS and network. It is consistent when using localhost afaik. Basically, every output port channel is handled by a separate thread, that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for new messages on the channel and puts them in cache when the interpreter is ready to receive a response for an operation (in the case of one-way such responses are just ACKs that the messages have been put in the channel cache on the other side). So, you have that thread on the client waiting on the channel, and the server suddenly goes down because it terminates execution. Then, the client throws that exception. The problem in handling this gracefully is that we should differentiate between an EOFException that we get in the middle of parsing a received message in a protocol (e.g., SODEP, but more in general CommProtocol.recv()), or the same exception got when trying to receive the first bit of information (which is your case if you look at the source code at SodepProtocol.java:252). Then, the protocol could throw a custom exception that we create (ChannelClosedException?) representing a graceful channel closing and catch it from jolie.net.AbstractCommChannel$ResponseReceiver. Let me know if you'd be interested in tackling this. Cheers, Fabrizio. On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer <mwa...@ya...> wrote: > Hi Fabrizio, > > this works well, but on the client side >> >> main >> { >> twice@TwiceService( 5 ) >> } > > I get a Java EOF exception. I imagine that this could be a coordination > issue? >> >> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning >> WARNING: [client.ol] java.io.EOFException >> at java.io.DataInputStream.readFully(DataInputStream.java:197) >> at java.io.DataInputStream.readLong(DataInputStream.java:416) >> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) >> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) >> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) >> at jolie.net.CommChannel.recv(CommChannel.java:198) >> at >> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> at java.lang.Thread.run(Thread.java:724) > > Cheers, > Matthias > > Fabrizio Montesi schrieb: > >> Hi Matthias, >> this: >>> >>> twice( number ) { >>> result = number * 2; >>> println@Console( result )(); >>> } >> >> is not a construct in the language. Request-Response operations >> support the { block } construct because it is useful to specify >> something to happen *in-between* the request and the response. For >> one-ways this is not necessary because they just receive something. >> Hence you can just use the semicolon operator for expressing a >> sequence and obtain what you want: >> >> twice( number ); >> result = number * 2; >> println@Console( result )() >> >> >> Cheers, >> Fabrizio. >> >> >> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer >> <mwa...@ya...> wrote: >>> >>> Hi developers, >>> >>> I got another question: in >>> >>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment >>> we have a simple client-server example: >>>> >>>> |main| >>>> |{| >>>> |||twice( number )( response ) {| >>>> |||response = number * ||2| >>>> |||}| >>>> |}| >>> >>> But when I change it to be one-way I run into trouble: >>>> >>>> interface TwiceInterface { >>>> OneWay: twice( int ) >>>> } >>> >>> and >>>> >>>> main >>>> { >>>> twice( number ) { >>>> result = number * 2; >>>> println@Console( result )(); >>>> } >>>> } >>> >>> does not work. Why? >>> >>> Do I need something like this? >>>> >>>> main >>>> { >>>> [ twice( number ) ] { >>>> result = number * 2; >>>> println@Console( result )(); >>>> } >>>> } >>> >>> Cheers, >>> Matthias >>> >>> >>> ------------------------------------------------------------------------------ >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>> conversations that shape the rapidly evolving mobile landscape. Sign up >>> now. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Jolie-devel mailing list >>> Jol...@li... >>> https://lists.sourceforge.net/lists/listinfo/jolie-devel > > |
From: Matthias D. W. <mwa...@ya...> - 2013-11-21 11:30:00
|
Hi Fabrizio & Saverio, I would propose some doc change to clear this one - since it did not seem obvious to me. Cheers, Matthias Matthias Dieter Wallnöfer schrieb: > Hi Fabrizio, > > this works well, but on the client side >> main >> { >> twice@TwiceService( 5 ) >> } > I get a Java EOF exception. I imagine that this could be a coordination > issue? >> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning >> WARNING: [client.ol] java.io.EOFException >> at java.io.DataInputStream.readFully(DataInputStream.java:197) >> at java.io.DataInputStream.readLong(DataInputStream.java:416) >> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) >> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) >> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) >> at jolie.net.CommChannel.recv(CommChannel.java:198) >> at >> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> at java.lang.Thread.run(Thread.java:724) > Cheers, > Matthias > > Fabrizio Montesi schrieb: >> Hi Matthias, >> this: >>> twice( number ) { >>> result = number * 2; >>> println@Console( result )(); >>> } >> is not a construct in the language. Request-Response operations >> support the { block } construct because it is useful to specify >> something to happen *in-between* the request and the response. For >> one-ways this is not necessary because they just receive something. >> Hence you can just use the semicolon operator for expressing a >> sequence and obtain what you want: >> >> twice( number ); >> result = number * 2; >> println@Console( result )() >> >> >> Cheers, >> Fabrizio. >> >> >> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer >> <mwa...@ya...> wrote: >>> Hi developers, >>> >>> I got another question: in >>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment >>> we have a simple client-server example: >>>> |main| >>>> |{| >>>> |||twice( number )( response ) {| >>>> |||response = number * ||2| >>>> |||}| >>>> |}| >>> But when I change it to be one-way I run into trouble: >>>> interface TwiceInterface { >>>> OneWay: twice( int ) >>>> } >>> and >>>> main >>>> { >>>> twice( number ) { >>>> result = number * 2; >>>> println@Console( result )(); >>>> } >>>> } >>> does not work. Why? >>> >>> Do I need something like this? >>>> main >>>> { >>>> [ twice( number ) ] { >>>> result = number * 2; >>>> println@Console( result )(); >>>> } >>>> } >>> Cheers, >>> Matthias >>> >>> ------------------------------------------------------------------------------ >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Jolie-devel mailing list >>> Jol...@li... >>> https://lists.sourceforge.net/lists/listinfo/jolie-devel > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Jolie-devel mailing list > Jol...@li... > https://lists.sourceforge.net/lists/listinfo/jolie-devel |
From: Matthias D. W. <mwa...@ya...> - 2013-11-21 10:53:36
|
Hi Fabrizio, this works well, but on the client side > main > { > twice@TwiceService( 5 ) > } I get a Java EOF exception. I imagine that this could be a coordination issue? > Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning > WARNING: [client.ol] java.io.EOFException > at java.io.DataInputStream.readFully(DataInputStream.java:197) > at java.io.DataInputStream.readLong(DataInputStream.java:416) > at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) > at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) > at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) > at jolie.net.CommChannel.recv(CommChannel.java:198) > at > jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) Cheers, Matthias Fabrizio Montesi schrieb: > Hi Matthias, > this: >> twice( number ) { >> result = number * 2; >> println@Console( result )(); >> } > is not a construct in the language. Request-Response operations > support the { block } construct because it is useful to specify > something to happen *in-between* the request and the response. For > one-ways this is not necessary because they just receive something. > Hence you can just use the semicolon operator for expressing a > sequence and obtain what you want: > > twice( number ); > result = number * 2; > println@Console( result )() > > > Cheers, > Fabrizio. > > > On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer > <mwa...@ya...> wrote: >> Hi developers, >> >> I got another question: in >> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment >> we have a simple client-server example: >>> |main| >>> |{| >>> |||twice( number )( response ) {| >>> |||response = number * ||2| >>> |||}| >>> |}| >> But when I change it to be one-way I run into trouble: >>> interface TwiceInterface { >>> OneWay: twice( int ) >>> } >> and >>> main >>> { >>> twice( number ) { >>> result = number * 2; >>> println@Console( result )(); >>> } >>> } >> does not work. Why? >> >> Do I need something like this? >>> main >>> { >>> [ twice( number ) ] { >>> result = number * 2; >>> println@Console( result )(); >>> } >>> } >> Cheers, >> Matthias >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Jolie-devel mailing list >> Jol...@li... >> https://lists.sourceforge.net/lists/listinfo/jolie-devel |
From: Fabrizio M. <fam...@gm...> - 2013-11-21 10:22:42
|
Hi Matthias, this: > twice( number ) { > result = number * 2; > println@Console( result )(); > } is not a construct in the language. Request-Response operations support the { block } construct because it is useful to specify something to happen *in-between* the request and the response. For one-ways this is not necessary because they just receive something. Hence you can just use the semicolon operator for expressing a sequence and obtain what you want: twice( number ); result = number * 2; println@Console( result )() Cheers, Fabrizio. On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer <mwa...@ya...> wrote: > Hi developers, > > I got another question: in > http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment > we have a simple client-server example: >> |main| >> |{| >> |||twice( number )( response ) {| >> |||response = number * ||2| >> |||}| >> |}| > > But when I change it to be one-way I run into trouble: >> interface TwiceInterface { >> OneWay: twice( int ) >> } > and >> main >> { >> twice( number ) { >> result = number * 2; >> println@Console( result )(); >> } >> } > does not work. Why? > > Do I need something like this? >> main >> { >> [ twice( number ) ] { >> result = number * 2; >> println@Console( result )(); >> } >> } > > Cheers, > Matthias > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Jolie-devel mailing list > Jol...@li... > https://lists.sourceforge.net/lists/listinfo/jolie-devel |
From: Matthias D. W. <mwa...@ya...> - 2013-11-21 10:04:22
|
Hi developers, I got another question: in http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment we have a simple client-server example: > |main| > |{| > |||twice( number )( response ) {| > |||response = number * ||2| > |||}| > |}| But when I change it to be one-way I run into trouble: > interface TwiceInterface { > OneWay: twice( int ) > } and > main > { > twice( number ) { > result = number * 2; > println@Console( result )(); > } > } does not work. Why? Do I need something like this? > main > { > [ twice( number ) ] { > result = number * 2; > println@Console( result )(); > } > } Cheers, Matthias |
From: Matthias D. W. <mwa...@ya...> - 2013-11-20 12:52:58
|
Sorry :-), Matthias Claudio Guidi schrieb: > Hi All, > > I think that in this particular case we could assume that an element like: > > <s:element name="GetWeatherInformation"><s:complexType/></s:element> > > could be considered as a void in Jolie. > > > > -------------------------------------------------------------- > Claudio Guidi Ph.D. > italianaSoftware s.r.l. > via Coralli, 66 - 40026 Imola (BO), Italy > http://www.italianasoftware.com/ > http://www.jolie-lang.org <http://www.jolie-lang.org/> > Phone: +39 0542 788201 > Mobile: +39 347 0694065 > Fax: +39 0542 628048 > -------------------------------------------------------------- > > Nota di riservatezza: Il presente messaggio, corredato dei > relativi allegati, contiene informazioni da considerarsi strettamente > riservate, ed è destinato esclusivamente al destinatario sopra > indicato, il quale è l'unico autorizzato ad usarlo, copiarlo e, sotto > la propria responsabilità,diffonderlo. Chiunque ricevesse questo > messaggio per errore o comunque lo leggesse senza esserne legittimato > è avvertito che trattenerlo, copiarlo,divulgarlo, distribuirlo a > persone diverse dal destinatario è severamente proibito, ed è pregato > di rinviarlo immediatamente al mittente distruggendone l'originale. > > Grazie per la collaborazione. > > > 2013/11/20 Fabrizio Montesi <fam...@gm... > <mailto:fam...@gm...>> > > Hi Matthias, > yes, the problem is that complex types in general go out of the types > supported by Jolie (since they are not structured, afaik). However, we > can certainly work out some cases that we can support in our types. > For example, an empty complex type corresponds to a void as you point > out. > > When we are dealing with an unsupported type (as you encountered) we > should throw an exception though... it's better than outputting > something incorrect. > Or, even better, when we find out something that we do not know how to > deal with we should print "undefined" as type. > > Could I see your modification? > > Cheers, > Fabrizio. > > On Wed, Nov 20, 2013 at 12:36 PM, Matthias Dieter Wallnöfer > <mwa...@ya... <mailto:mwa...@ya...>> wrote: > > Hi Fabrizio, > > > > when dealing with another webservice I ran into some issues using > > wsdl2jolie. > > > > Address: http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL > > > > - At the moment the tool suppresses undefined complex types. > This does not > > work out with the SOAP call "GetWeatherInformation()" - since > then it is > > missing its input argument datatype > > - When the same call is run by other methods (eg. HTTP) it has > some kind of > > empty input type associated. At the moment the tool prints a > declaration > > like: > >> > >> GetWeatherInformation()(ArrayOfWeatherDescription) > > > > which is denied by Jolie. With a slight change I get a "void" type: > >> > >> GetWeatherInformation(void)(ArrayOfWeatherDescription) > > > > > > Cheers, > > Matthias > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech > innovation. > Intel(R) Software Adrenaline delivers strategic insight and > game-changing > conversations that shape the rapidly evolving mobile landscape. > Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Jolie-devel mailing list > Jol...@li... > <mailto:Jol...@li...> > https://lists.sourceforge.net/lists/listinfo/jolie-devel > > |
From: Claudio G. <cg...@it...> - 2013-11-20 12:16:51
|
Hi All, I think that in this particular case we could assume that an element like: <s:element name="GetWeatherInformation"><s:complexType/></s:element> could be considered as a void in Jolie. -------------------------------------------------------------- Claudio Guidi Ph.D. italianaSoftware s.r.l. via Coralli, 66 - 40026 Imola (BO), Italy http://www.italianasoftware.com/ http://www.jolie-lang.org Phone: +39 0542 788201 Mobile: +39 347 0694065 Fax: +39 0542 628048 -------------------------------------------------------------- Nota di riservatezza: Il presente messaggio, corredato dei relativi allegati, contiene informazioni da considerarsi strettamente riservate, ed è destinato esclusivamente al destinatario sopra indicato, il quale è l'unico autorizzato ad usarlo, copiarlo e, sotto la propria responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per errore o comunque lo leggesse senza esserne legittimato è avvertito che trattenerlo, copiarlo,divulgarlo, distribuirlo a persone diverse dal destinatario è severamente proibito, ed è pregato di rinviarlo immediatamente al mittente distruggendone l'originale. Grazie per la collaborazione. 2013/11/20 Fabrizio Montesi <fam...@gm...> > Hi Matthias, > yes, the problem is that complex types in general go out of the types > supported by Jolie (since they are not structured, afaik). However, we > can certainly work out some cases that we can support in our types. > For example, an empty complex type corresponds to a void as you point > out. > > When we are dealing with an unsupported type (as you encountered) we > should throw an exception though... it's better than outputting > something incorrect. > Or, even better, when we find out something that we do not know how to > deal with we should print "undefined" as type. > > Could I see your modification? > > Cheers, > Fabrizio. > > On Wed, Nov 20, 2013 at 12:36 PM, Matthias Dieter Wallnöfer > <mwa...@ya...> wrote: > > Hi Fabrizio, > > > > when dealing with another webservice I ran into some issues using > > wsdl2jolie. > > > > Address: http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL > > > > - At the moment the tool suppresses undefined complex types. This does > not > > work out with the SOAP call "GetWeatherInformation()" - since then it is > > missing its input argument datatype > > - When the same call is run by other methods (eg. HTTP) it has some kind > of > > empty input type associated. At the moment the tool prints a declaration > > like: > >> > >> GetWeatherInformation()(ArrayOfWeatherDescription) > > > > which is denied by Jolie. With a slight change I get a "void" type: > >> > >> GetWeatherInformation(void)(ArrayOfWeatherDescription) > > > > > > Cheers, > > Matthias > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up > now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Jolie-devel mailing list > Jol...@li... > https://lists.sourceforge.net/lists/listinfo/jolie-devel > |