jolie-devel — Jolie development mailing list

Re: [Jolie-devel] HTTP URI UTF-8 parsing

[Matthias D. W. <mat...@ya...>]

Next attempt to fix the chunk parsing code, does still not work (I am
following http://tools.ietf.org/html/rfc2616#section-3.6.1).

Matthias Dieter Wallnöfer schrieb:
> Just apply my patch, then start a local Leonardo on Jolie's website and
> click on Blogs and/or Tutorials. You will immediately notice that it
> gets stuck.
> 
> Considering Leonardo's stacktrace you will see that the chunk parsing
> code is the cause...
> 
> Cheers,
> Matthias
> 
> 
> Fabrizio Montesi <fam...@gm...> schrieb am 12:07 Mittwoch,
> 11.März 2015:
> 
> 
> I wrote that code in ancient times. Let me know how I can help. :-)
> 
> On Tue, Mar 10, 2015 at 10:23 PM, Matthias Dieter Wallnöfer
> <mwa...@ya... <mailto:mwa...@ya...>> wrote:
> 
>     Exactly, it works like this. Therefore readAll in HttpParser works
>     directly with the byte array deriving from the InputStream. 
> 
>     But the header needs to be parsed in UTF-8 to get Unicode-enabled
>     URIs. It would be nice if someone could help me with porting/fixing
>     the chunk parsing code. ..
> 
>     Von Samsung Mobile gesendet
> 
> 
>     -------- Ursprüngliche Nachricht --------
>     Von: Fabrizio Montesi __
>     Datum:10.03.2015 21:05 (GMT+01:00)
>     An: Matthias Dieter Wallnöfer __
>     Cc: jol...@li...
>     <mailto:jol...@li...>
>     Betreff: Re: [Jolie-devel] HTTP URI UTF-8 parsing
> 
>     Shouldn't we use UTF-8 only for the headers and then whatever is
>     dictacted by the headers for the rest?
> 
>     - F
> 
>     On Tue, Mar 10, 2015 at 7:44 PM, Matthias Dieter Wallnöfer
>     <mat...@ya... <mailto:mat...@ya...>>
>     wrote:
> 
>         Hi list,
> 
>         Jolie's HTTP module has the limitation, that it currently does not
>         recognise UTF-8 characters in HTTP URIs, which today is standard.
>         Looking at the HTTP scanner I noticed that we always parse as ASCII.
> 
>         I have tried to introduce a UTF-8 reader on top of the
>         InputStream which
>         seems to partially work: one big issue which I came across is
>         the chunk
>         parsing code.
> 
>         I know that this is a tricky part. Previously I tried a
>         reconversion in
>         the HttpParser with no success, so I think it needs to be parsed
>         correctly already at the beginning.
> 
>         > Exception in thread "main.ol-JolieThread-42"
>         java.lang.NumberFormatException: For input string: "?xml"
>         >       at
>         java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>         >       at java.lang.Integer.parseInt(Integer.java:492)
>         >       at
>         jolie.net.http.HttpParser.readContent(HttpParser.java:290)
>         >       at jolie.net.http.HttpParser.parse(HttpParser.java:352)
>         >       at
>         jolie.net.HttpProtocol.recv_internal(HttpProtocol.java:1236)
>         >       at jolie.net.HttpProtocol.recv(HttpProtocol.java:1344)
>         >       at
>         jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:94)
>         >       at jolie.net.CommChannel.recv(CommChannel.java:198)
>         >       at
>         jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:227)
>         >       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:745)
>         > Exception in thread "main.ol-JolieThread-29"
>         java.lang.IndexOutOfBoundsException
>         >       at
>         sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:92)
>         >       at
>         jolie.net.PreBufferedInputStream.read(PreBufferedInputStream.java:135)
>         >       at
>         jolie.net.http.HttpParser.blockingRead(HttpParser.java:235)
>         >       at
>         jolie.net.http.HttpParser.readContent(HttpParser.java:296)
>         >       at jolie.net.http.HttpParser.parse(HttpParser.java:352)
>         >       at
>         jolie.net.HttpProtocol.recv_internal(HttpProtocol.java:1236)
>         >       at jolie.net.HttpProtocol.recv(HttpProtocol.java:1344)
>         >       at
>         jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:94)
>         >       at jolie.net.CommChannel.recv(CommChannel.java:198)
>         >       at
>         jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:227)
>         >       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:745)
> 
>         Cheers,
>         Matthias
> 
>         ------------------------------------------------------------------------------
>         Dive into the World of Parallel Programming The Go Parallel
>         Website, sponsored
>         by Intel and developed in partnership with Slashdot Media, is
>         your hub for all
>         things parallel software development, from weekly thought
>         leadership blogs to
>         news, videos, case studies, tutorials and more. Take a look and
>         join the
>         conversation now. http://goparallel.sourceforge.net/
>         _______________________________________________
>         Jolie-devel mailing list
>         Jol...@li...
>         <mailto:Jol...@li...>
>         https://lists.sourceforge.net/lists/listinfo/jolie-devel
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> 
> 
> 
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
> 

Re: [Jolie-devel] joliedoc bug

[Fabrizio M. <fam...@gm...>]

@Claudio: can you share the path where calculator.ol is located and
calculator.ol itself?

On Thu, Mar 12, 2015 at 6:06 PM, Fabrizio Montesi <fam...@gm...>
wrote:

> @Matthias and Saverio: Could this be because of one of the patches on the
> program filename?
>
> 2015-03-12 18:03 GMT+01:00 Claudio Guidi <cg...@it...>:
>
>> Hi guys,
>>
>> I found this bug in joliedoc
>>
>> joliedoc calculator.ol
>> Exception in thread "main" java.lang.IllegalArgumentException: URI is not
>> hierarchical
>> at java.io.File.<init>(File.java:418)
>> at
>> jolie.doc.impl.html.HtmlDocumentCreator.ConvertDocument(HtmlDocumentCreator.java:69)
>> at jolie.doc.JolieDoc.main(JolieDoc.java:59)
>>
>>
>> --------------------------------------------------------------
>> Claudio Guidi Ph.D.
>> italianaSoftware s.r.l.
>> via Lasie 12/D - 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.
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Jolie-devel mailing list
>> Jol...@li...
>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>
>>
>

Re: [Jolie-devel] joliedoc bug

[Fabrizio M. <fam...@gm...>]

@Matthias and Saverio: Could this be because of one of the patches on the
program filename?

2015-03-12 18:03 GMT+01:00 Claudio Guidi <cg...@it...>:

> Hi guys,
>
> I found this bug in joliedoc
>
> joliedoc calculator.ol
> Exception in thread "main" java.lang.IllegalArgumentException: URI is not
> hierarchical
> at java.io.File.<init>(File.java:418)
> at
> jolie.doc.impl.html.HtmlDocumentCreator.ConvertDocument(HtmlDocumentCreator.java:69)
> at jolie.doc.JolieDoc.main(JolieDoc.java:59)
>
>
> --------------------------------------------------------------
> Claudio Guidi Ph.D.
> italianaSoftware s.r.l.
> via Lasie 12/D - 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.
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
>

[Jolie-devel] joliedoc bug

[Claudio G. <cg...@it...>]

Hi guys,

I found this bug in joliedoc

joliedoc calculator.ol
Exception in thread "main" java.lang.IllegalArgumentException: URI is not
hierarchical
at java.io.File.<init>(File.java:418)
at
jolie.doc.impl.html.HtmlDocumentCreator.ConvertDocument(HtmlDocumentCreator.java:69)
at jolie.doc.JolieDoc.main(JolieDoc.java:59)


--------------------------------------------------------------
Claudio Guidi Ph.D.
italianaSoftware s.r.l.
via Lasie 12/D - 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.

Re: [Jolie-devel] Jolie 1.2 - Inline trees

[Matthias D. W. <mwa...@ya...>]

";" is more about sequential execution for us, "," is our delimiter (consider also "for") so I would stuck with ",".

Matthias


Fabrizio Montesi <fam...@gm...> schrieb am 9:30 Donnerstag, 12.März 2015:



Hi all,

Any ideas on my last comment in the e-mail (comma vs semi-colon)? I'd like some feedback on that particular syntax before making it official on the docs site.

Even an "I like it" would make me feel better. Break the silence. ;-)

Cheers,
Fabrizio


On Sat, Mar 7, 2015 at 3:44 PM, Fabrizio Montesi <fam...@gm...> wrote:

Hi all,
>
>I committed a series of patches I had lingering around for a while on inline trees.
>
>Now we can write stuff like this:
>
>a.left << "Left" { .x = 1, .y = 2, .y.left = "y_l", .y.right = "y_r" };
>
>
>valueToPrettyString@StringUtils( { .x = 1, .y = 2 } )( s );
>
>
>
>
>This is obtained by introducing a new kind of expression (InlineTreeExpression) that takes a value for the root node and a series of assignments in between curly brackets { }.
>
>
>You can thus write an inline tree wherever you can write an expression.
>
>
>Let me know what you think.
>
>
>In particular, I tried to follow what they do in other language by using the comma to separate assignments, but I'm not very happy that it is inconsistent with what we do in protocol configurations where we use ; instead.
>
>
>Feedback is welcome.
>
>
>Cheers,
>Fabrizio


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/

_______________________________________________
Jolie-devel mailing list
Jol...@li...
https://lists.sourceforge.net/lists/listinfo/jolie-devel

Re: [Jolie-devel] Tree manipulation primitives

[Fabrizio M. <fam...@gm...>]

PS: Yes, yes, I'll blog about it... but probably next month given my
schedule. ;-)

On Thu, Mar 12, 2015 at 9:45 AM, Fabrizio Montesi <fam...@gm...>
wrote:

> I've committed a working chat server + clients in playground, as an
> example. Both clients and server use both the new tree primitive and the
> provide-until operator.
>
> Cheers,
> Fabrizio
>
> On Thu, Mar 12, 2015 at 9:21 AM, Saverio Giallorenzo <
> sav...@gm...> wrote:
>
>> Definitely, that along with `provide-until` and optional `{nullProcess}`
>> in input choices shall be added to the documentation.
>>
>> Unfortunately I haven't had much time to experiment with these new
>> features yet. If some of you have interesting
>> examples I'd appreciate to receive your inputs to provide both a proper
>> explanation and some meaningful examples.
>>
>> Best,
>> sg
>>
>>
>> On 11 March 2015 at 20:40, Matthias Dieter Wallnöfer <
>> mat...@ya...> wrote:
>>
>>> Saverio,
>>>
>>> would you please add also an example of our new tree manipulation
>>> primitives? This could be very helpful...
>>>
>>> Cheers,
>>> Matthias
>>>
>>> Fabrizio Montesi schrieb:
>>> > Looks good, thanks Saverio. :-)
>>> >
>>> > On Mon, Feb 16, 2015 at 5:16 PM, Saverio Giallorenzo
>>> > <sav...@gm... <mailto:sav...@gm...>>
>>> > wrote:
>>> >
>>> >     For the time being I committed an example of deep copy in the docs,
>>> >     tell me if it can be enough to better explain how it works.
>>> >
>>> >
>>> >     On Monday, February 16, 2015, Fabrizio Montesi <
>>> fam...@gm...
>>> >     <mailto:fam...@gm...>> wrote:
>>> >
>>> >         On Mon, Feb 16, 2015 at 10:24 AM, Claudio Guidi
>>> >         <cg...@it...> wrote:
>>> >
>>> >
>>> >                 Hi all,
>>> >
>>> >                 Matthias and I are having a discussion which I think is
>>> >                 of interest to everybody, on data structures.
>>> >
>>> >                 Right now, doing a << b simply copies all array
>>> elements
>>> >                 from b inside of a, *without* erasing a first. So if
>>> you
>>> >                 have:
>>> >
>>> >                 a[0] = 1;
>>> >                 a[1] = 2;
>>> >                 b[0] = 3
>>> >
>>> >                 doing a << b gets you an a like this: a[0]  = 3; a[1]
>>> = 2
>>> >
>>> >
>>> >             from my point of view it is correct
>>> >
>>> >
>>> >                 Whereas one may expect simply a[0] = 1
>>> >
>>> >
>>> >             why?
>>> >
>>> >
>>> >
>>> >
>>> >                 We may want to switch << to erase the left-hand side
>>> >                 first. Would that make sense to everybody?
>>> >
>>> >
>>> >             I do not agree.
>>> >             I could easily obtain the same behaviour by using:
>>> >
>>> >             undef( a ); a << b;
>>> >
>>> >             on the contrary if you change the semantics it will be very
>>> >             difficult to copy a portion of a tree inside an existing
>>> one.
>>> >
>>> >
>>> >         I agree, that's why it works like that now. We need to fix the
>>> >         docs though maybe?
>>> >
>>> >
>>> >
>>> >             I would not change the primitives we have because they work
>>> >             fine from my point of view.
>>> >             Their semantics it is coherent with the syntax, thus I like
>>> >             them.
>>> >
>>> >             Maybe we could introduce some other primitives like, for
>>> >             example, node renaming.
>>> >             For example.
>>> >
>>> >             Ex: when you query a DB you always have a result with a
>>> list
>>> >             of rows
>>> >
>>> >             .row* {
>>> >                   all the column
>>> >             }
>>> >
>>> >             if I want to reply with a message like the following one
>>> >
>>> >             .item* {
>>> >                  all the columns
>>> >             }
>>> >
>>> >             i can:
>>> >             1) create an alias :    msg.item -> result.row
>>> >             2) make a deep copy msg.item << result.row
>>> >
>>> >
>>> >             in both cases I need to create another variable, in the
>>> >             second case there is a deep copy that
>>> >             takes more computation w.r.t. case 1.
>>> >
>>> >             This case is more difficult when the same situation has a
>>> >             node inside:
>>> >
>>> >             .row* {
>>> >                   .nodeA*: StructureType
>>> >                   other
>>> >             }
>>> >
>>> >             and I would:
>>> >
>>> >             .item* {
>>> >                  .nodeB: StructureType
>>> >                  other
>>> >             }
>>> >
>>> >             In this case nor alias or deep copy can help me.
>>> >
>>> >             But if we have a renaming primitive like for example:
>>> >
>>> >             result.row $ result.item;
>>> >             result.item.nodeA $ result.item.nodeB
>>> >
>>> >             evrything is done.
>>> >
>>> >             ( the usage of $ is just for an example, we could use
>>> >             different symbols)
>>> >
>>> >
>>> >         Interesting! It looks like it would be difficult to do even
>>> with
>>> >         inline trees, which may justify having a primitive.
>>> >
>>> >         I can only do easily the first one:
>>> >
>>> >         result << {
>>> >            .row << result.item
>>> >         }
>>> >
>>> >                 Here are a couple of things I feel we should introduce,
>>> >                 for example: inline trees.
>>> >
>>> >                 Inline trees example:
>>> >
>>> >                 send@OP( "rootString" { .x = 5, .y = 7 } )
>>> >
>>> >
>>> >             I like it
>>> >
>>> >
>>> >
>>> >                 I would also love to have pattern matching,
>>> >
>>> >
>>> >             something different from instanceof?
>>> >
>>> >
>>> >         Yes, like pattern matching in scala:
>>> >
>>> >
>>> http://docs.scala-lang.org/tutorials/tour/pattern-matching.html
>>> >
>>> >         You can match not only to types but also to values (a switch on
>>> >         super-steroids, coming from typical Functional Programming).
>>> >
>>> >         However, I don't want to introduce it now because if we extend
>>> >         our type system it may become powerful enough to recognise
>>> >         values. E.g.,
>>> >
>>> >         type MyInt: int(5)  // The type of an integer with value 5
>>> >
>>> >         Then we could just use instanceof.
>>> >
>>> >         Cheers,
>>> >         Fabrizio.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> > from Actuate! Instantly Supercharge Your Business Reports and
>>> Dashboards
>>> > with Interactivity, Sharing, Native Excel Exports, App Integration &
>>> more
>>> > Get technology previously reserved for billion-dollar corporations,
>>> FREE
>>> >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Jolie-devel mailing list
>>> > Jol...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>> >
>>>
>>>
>>
>

Re: [Jolie-devel] Tree manipulation primitives

[Fabrizio M. <fam...@gm...>]

I've committed a working chat server + clients in playground, as an
example. Both clients and server use both the new tree primitive and the
provide-until operator.

Cheers,
Fabrizio

On Thu, Mar 12, 2015 at 9:21 AM, Saverio Giallorenzo <
sav...@gm...> wrote:

> Definitely, that along with `provide-until` and optional `{nullProcess}`
> in input choices shall be added to the documentation.
>
> Unfortunately I haven't had much time to experiment with these new
> features yet. If some of you have interesting
> examples I'd appreciate to receive your inputs to provide both a proper
> explanation and some meaningful examples.
>
> Best,
> sg
>
>
> On 11 March 2015 at 20:40, Matthias Dieter Wallnöfer <
> mat...@ya...> wrote:
>
>> Saverio,
>>
>> would you please add also an example of our new tree manipulation
>> primitives? This could be very helpful...
>>
>> Cheers,
>> Matthias
>>
>> Fabrizio Montesi schrieb:
>> > Looks good, thanks Saverio. :-)
>> >
>> > On Mon, Feb 16, 2015 at 5:16 PM, Saverio Giallorenzo
>> > <sav...@gm... <mailto:sav...@gm...>>
>> > wrote:
>> >
>> >     For the time being I committed an example of deep copy in the docs,
>> >     tell me if it can be enough to better explain how it works.
>> >
>> >
>> >     On Monday, February 16, 2015, Fabrizio Montesi <fam...@gm...
>> >     <mailto:fam...@gm...>> wrote:
>> >
>> >         On Mon, Feb 16, 2015 at 10:24 AM, Claudio Guidi
>> >         <cg...@it...> wrote:
>> >
>> >
>> >                 Hi all,
>> >
>> >                 Matthias and I are having a discussion which I think is
>> >                 of interest to everybody, on data structures.
>> >
>> >                 Right now, doing a << b simply copies all array elements
>> >                 from b inside of a, *without* erasing a first. So if you
>> >                 have:
>> >
>> >                 a[0] = 1;
>> >                 a[1] = 2;
>> >                 b[0] = 3
>> >
>> >                 doing a << b gets you an a like this: a[0]  = 3; a[1] =
>> 2
>> >
>> >
>> >             from my point of view it is correct
>> >
>> >
>> >                 Whereas one may expect simply a[0] = 1
>> >
>> >
>> >             why?
>> >
>> >
>> >
>> >
>> >                 We may want to switch << to erase the left-hand side
>> >                 first. Would that make sense to everybody?
>> >
>> >
>> >             I do not agree.
>> >             I could easily obtain the same behaviour by using:
>> >
>> >             undef( a ); a << b;
>> >
>> >             on the contrary if you change the semantics it will be very
>> >             difficult to copy a portion of a tree inside an existing
>> one.
>> >
>> >
>> >         I agree, that's why it works like that now. We need to fix the
>> >         docs though maybe?
>> >
>> >
>> >
>> >             I would not change the primitives we have because they work
>> >             fine from my point of view.
>> >             Their semantics it is coherent with the syntax, thus I like
>> >             them.
>> >
>> >             Maybe we could introduce some other primitives like, for
>> >             example, node renaming.
>> >             For example.
>> >
>> >             Ex: when you query a DB you always have a result with a list
>> >             of rows
>> >
>> >             .row* {
>> >                   all the column
>> >             }
>> >
>> >             if I want to reply with a message like the following one
>> >
>> >             .item* {
>> >                  all the columns
>> >             }
>> >
>> >             i can:
>> >             1) create an alias :    msg.item -> result.row
>> >             2) make a deep copy msg.item << result.row
>> >
>> >
>> >             in both cases I need to create another variable, in the
>> >             second case there is a deep copy that
>> >             takes more computation w.r.t. case 1.
>> >
>> >             This case is more difficult when the same situation has a
>> >             node inside:
>> >
>> >             .row* {
>> >                   .nodeA*: StructureType
>> >                   other
>> >             }
>> >
>> >             and I would:
>> >
>> >             .item* {
>> >                  .nodeB: StructureType
>> >                  other
>> >             }
>> >
>> >             In this case nor alias or deep copy can help me.
>> >
>> >             But if we have a renaming primitive like for example:
>> >
>> >             result.row $ result.item;
>> >             result.item.nodeA $ result.item.nodeB
>> >
>> >             evrything is done.
>> >
>> >             ( the usage of $ is just for an example, we could use
>> >             different symbols)
>> >
>> >
>> >         Interesting! It looks like it would be difficult to do even with
>> >         inline trees, which may justify having a primitive.
>> >
>> >         I can only do easily the first one:
>> >
>> >         result << {
>> >            .row << result.item
>> >         }
>> >
>> >                 Here are a couple of things I feel we should introduce,
>> >                 for example: inline trees.
>> >
>> >                 Inline trees example:
>> >
>> >                 send@OP( "rootString" { .x = 5, .y = 7 } )
>> >
>> >
>> >             I like it
>> >
>> >
>> >
>> >                 I would also love to have pattern matching,
>> >
>> >
>> >             something different from instanceof?
>> >
>> >
>> >         Yes, like pattern matching in scala:
>> >
>> >         http://docs.scala-lang.org/tutorials/tour/pattern-matching.html
>> >
>> >         You can match not only to types but also to values (a switch on
>> >         super-steroids, coming from typical Functional Programming).
>> >
>> >         However, I don't want to introduce it now because if we extend
>> >         our type system it may become powerful enough to recognise
>> >         values. E.g.,
>> >
>> >         type MyInt: int(5)  // The type of an integer with value 5
>> >
>> >         Then we could just use instanceof.
>> >
>> >         Cheers,
>> >         Fabrizio.
>> >
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> > with Interactivity, Sharing, Native Excel Exports, App Integration &
>> more
>> > Get technology previously reserved for billion-dollar corporations, FREE
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> >
>> >
>> >
>> > _______________________________________________
>> > Jolie-devel mailing list
>> > Jol...@li...
>> > https://lists.sourceforge.net/lists/listinfo/jolie-devel
>> >
>>
>>
>

Re: [Jolie-devel] Jolie 1.2 - Inline trees

[Fabrizio M. <fam...@gm...>]

Hi all,

Any ideas on my last comment in the e-mail (comma vs semi-colon)? I'd like
some feedback on that particular syntax before making it official on the
docs site.

Even an "I like it" would make me feel better. Break the silence. ;-)

Cheers,
Fabrizio

On Sat, Mar 7, 2015 at 3:44 PM, Fabrizio Montesi <fam...@gm...>
wrote:

> Hi all,
>
> I committed a series of patches I had lingering around for a while on
> inline trees.
>
> Now we can write stuff like this:
>
> a.left << "Left" { .x = 1, .y = 2, .y.left = "y_l", .y.right = "y_r" };
>
> valueToPrettyString@StringUtils( { .x = 1, .y = 2 } )( s );
>
>
> This is obtained by introducing a new kind of expression
> (InlineTreeExpression) that takes a value for the root node and a series of
> assignments in between curly brackets { }.
>
> You can thus write an inline tree wherever you can write an expression.
>
> Let me know what you think.
>
> In particular, I tried to follow what they do in other language by using
> the comma to separate assignments, but I'm not very happy that it is
> inconsistent with what we do in protocol configurations where we use ;
> instead.
>
> Feedback is welcome.
>
> Cheers,
> Fabrizio
>

Re: [Jolie-devel] Tree manipulation primitives

[Saverio G. <sav...@gm...>]

Definitely, that along with `provide-until` and optional `{nullProcess}` in
input choices shall be added to the documentation.

Unfortunately I haven't had much time to experiment with these new features
yet. If some of you have interesting
examples I'd appreciate to receive your inputs to provide both a proper
explanation and some meaningful examples.

Best,
sg


On 11 March 2015 at 20:40, Matthias Dieter Wallnöfer <
mat...@ya...> wrote:

> Saverio,
>
> would you please add also an example of our new tree manipulation
> primitives? This could be very helpful...
>
> Cheers,
> Matthias
>
> Fabrizio Montesi schrieb:
> > Looks good, thanks Saverio. :-)
> >
> > On Mon, Feb 16, 2015 at 5:16 PM, Saverio Giallorenzo
> > <sav...@gm... <mailto:sav...@gm...>>
> > wrote:
> >
> >     For the time being I committed an example of deep copy in the docs,
> >     tell me if it can be enough to better explain how it works.
> >
> >
> >     On Monday, February 16, 2015, Fabrizio Montesi <fam...@gm...
> >     <mailto:fam...@gm...>> wrote:
> >
> >         On Mon, Feb 16, 2015 at 10:24 AM, Claudio Guidi
> >         <cg...@it...> wrote:
> >
> >
> >                 Hi all,
> >
> >                 Matthias and I are having a discussion which I think is
> >                 of interest to everybody, on data structures.
> >
> >                 Right now, doing a << b simply copies all array elements
> >                 from b inside of a, *without* erasing a first. So if you
> >                 have:
> >
> >                 a[0] = 1;
> >                 a[1] = 2;
> >                 b[0] = 3
> >
> >                 doing a << b gets you an a like this: a[0]  = 3; a[1] = 2
> >
> >
> >             from my point of view it is correct
> >
> >
> >                 Whereas one may expect simply a[0] = 1
> >
> >
> >             why?
> >
> >
> >
> >
> >                 We may want to switch << to erase the left-hand side
> >                 first. Would that make sense to everybody?
> >
> >
> >             I do not agree.
> >             I could easily obtain the same behaviour by using:
> >
> >             undef( a ); a << b;
> >
> >             on the contrary if you change the semantics it will be very
> >             difficult to copy a portion of a tree inside an existing one.
> >
> >
> >         I agree, that's why it works like that now. We need to fix the
> >         docs though maybe?
> >
> >
> >
> >             I would not change the primitives we have because they work
> >             fine from my point of view.
> >             Their semantics it is coherent with the syntax, thus I like
> >             them.
> >
> >             Maybe we could introduce some other primitives like, for
> >             example, node renaming.
> >             For example.
> >
> >             Ex: when you query a DB you always have a result with a list
> >             of rows
> >
> >             .row* {
> >                   all the column
> >             }
> >
> >             if I want to reply with a message like the following one
> >
> >             .item* {
> >                  all the columns
> >             }
> >
> >             i can:
> >             1) create an alias :    msg.item -> result.row
> >             2) make a deep copy msg.item << result.row
> >
> >
> >             in both cases I need to create another variable, in the
> >             second case there is a deep copy that
> >             takes more computation w.r.t. case 1.
> >
> >             This case is more difficult when the same situation has a
> >             node inside:
> >
> >             .row* {
> >                   .nodeA*: StructureType
> >                   other
> >             }
> >
> >             and I would:
> >
> >             .item* {
> >                  .nodeB: StructureType
> >                  other
> >             }
> >
> >             In this case nor alias or deep copy can help me.
> >
> >             But if we have a renaming primitive like for example:
> >
> >             result.row $ result.item;
> >             result.item.nodeA $ result.item.nodeB
> >
> >             evrything is done.
> >
> >             ( the usage of $ is just for an example, we could use
> >             different symbols)
> >
> >
> >         Interesting! It looks like it would be difficult to do even with
> >         inline trees, which may justify having a primitive.
> >
> >         I can only do easily the first one:
> >
> >         result << {
> >            .row << result.item
> >         }
> >
> >                 Here are a couple of things I feel we should introduce,
> >                 for example: inline trees.
> >
> >                 Inline trees example:
> >
> >                 send@OP( "rootString" { .x = 5, .y = 7 } )
> >
> >
> >             I like it
> >
> >
> >
> >                 I would also love to have pattern matching,
> >
> >
> >             something different from instanceof?
> >
> >
> >         Yes, like pattern matching in scala:
> >
> >         http://docs.scala-lang.org/tutorials/tour/pattern-matching.html
> >
> >         You can match not only to types but also to values (a switch on
> >         super-steroids, coming from typical Functional Programming).
> >
> >         However, I don't want to introduce it now because if we extend
> >         our type system it may become powerful enough to recognise
> >         values. E.g.,
> >
> >         type MyInt: int(5)  // The type of an integer with value 5
> >
> >         Then we could just use instanceof.
> >
> >         Cheers,
> >         Fabrizio.
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Jolie-devel mailing list
> > Jol...@li...
> > https://lists.sourceforge.net/lists/listinfo/jolie-devel
> >
>
>

Re: [Jolie-devel] Tree manipulation primitives

[Matthias D. W. <mat...@ya...>]

Saverio,

would you please add also an example of our new tree manipulation
primitives? This could be very helpful...

Cheers,
Matthias

Fabrizio Montesi schrieb:
> Looks good, thanks Saverio. :-)
> 
> On Mon, Feb 16, 2015 at 5:16 PM, Saverio Giallorenzo
> <sav...@gm... <mailto:sav...@gm...>>
> wrote:
> 
>     For the time being I committed an example of deep copy in the docs,
>     tell me if it can be enough to better explain how it works.
> 
> 
>     On Monday, February 16, 2015, Fabrizio Montesi <fam...@gm...
>     <mailto:fam...@gm...>> wrote:
> 
>         On Mon, Feb 16, 2015 at 10:24 AM, Claudio Guidi
>         <cg...@it...> wrote:
> 
> 
>                 Hi all,
> 
>                 Matthias and I are having a discussion which I think is
>                 of interest to everybody, on data structures.
> 
>                 Right now, doing a << b simply copies all array elements
>                 from b inside of a, *without* erasing a first. So if you
>                 have:
> 
>                 a[0] = 1;
>                 a[1] = 2;
>                 b[0] = 3
> 
>                 doing a << b gets you an a like this: a[0]  = 3; a[1] = 2
> 
> 
>             from my point of view it is correct 
> 
> 
>                 Whereas one may expect simply a[0] = 1
> 
> 
>             why?
> 
>              
> 
> 
>                 We may want to switch << to erase the left-hand side
>                 first. Would that make sense to everybody?
> 
> 
>             I do not agree. 
>             I could easily obtain the same behaviour by using:
> 
>             undef( a ); a << b;
> 
>             on the contrary if you change the semantics it will be very
>             difficult to copy a portion of a tree inside an existing one.
> 
> 
>         I agree, that's why it works like that now. We need to fix the
>         docs though maybe?
> 
>          
> 
>             I would not change the primitives we have because they work
>             fine from my point of view.
>             Their semantics it is coherent with the syntax, thus I like
>             them.
> 
>             Maybe we could introduce some other primitives like, for
>             example, node renaming.
>             For example.
> 
>             Ex: when you query a DB you always have a result with a list
>             of rows
> 
>             .row* {
>                   all the column
>             } 
> 
>             if I want to reply with a message like the following one 
> 
>             .item* {
>                  all the columns
>             }
> 
>             i can:
>             1) create an alias :    msg.item -> result.row
>             2) make a deep copy msg.item << result.row
> 
> 
>             in both cases I need to create another variable, in the
>             second case there is a deep copy that 
>             takes more computation w.r.t. case 1.
> 
>             This case is more difficult when the same situation has a
>             node inside:
> 
>             .row* {
>                   .nodeA*: StructureType
>                   other
>             } 
> 
>             and I would:
> 
>             .item* {
>                  .nodeB: StructureType
>                  other
>             }
> 
>             In this case nor alias or deep copy can help me.
> 
>             But if we have a renaming primitive like for example:
> 
>             result.row $ result.item;
>             result.item.nodeA $ result.item.nodeB
> 
>             evrything is done.
> 
>             ( the usage of $ is just for an example, we could use
>             different symbols)
> 
> 
>         Interesting! It looks like it would be difficult to do even with
>         inline trees, which may justify having a primitive.
> 
>         I can only do easily the first one:
> 
>         result << {
>            .row << result.item
>         }
> 
>                 Here are a couple of things I feel we should introduce,
>                 for example: inline trees.
> 
>                 Inline trees example:
> 
>                 send@OP( "rootString" { .x = 5, .y = 7 } )
> 
> 
>             I like it 
> 
> 
> 
>                 I would also love to have pattern matching, 
> 
> 
>             something different from instanceof?
> 
> 
>         Yes, like pattern matching in scala:
> 
>         http://docs.scala-lang.org/tutorials/tour/pattern-matching.html
> 
>         You can match not only to types but also to values (a switch on
>         super-steroids, coming from typical Functional Programming).
> 
>         However, I don't want to introduce it now because if we extend
>         our type system it may become powerful enough to recognise
>         values. E.g.,
> 
>         type MyInt: int(5)  // The type of an integer with value 5
> 
>         Then we could just use instanceof.
> 
>         Cheers,
>         Fabrizio. 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
> 

Re: [Jolie-devel] scopeStack?

[Fabrizio M. <fam...@gm...>]

Try a clean recompile. If that doesn't work, it's my bad and I'll fix it
tomorrow. :-)

Sent from my phone.
On Mar 11, 2015 8:37 PM, "Matthias Dieter Wallnöfer" <
mat...@ya...> wrote:

> Lately I get this issue in Jolie's Leonardo:
>
> > Exception in thread "leonardo.ol-JolieThread-23"
> java.lang.NoSuchFieldError: scopeStack
> >         at jolie.SessionThread.<init>(SessionThread.java:258)
> >         at jolie.Interpreter.startServiceSession(Interpreter.java:1235)
> >         at
> jolie.runtime.correlation.CorrelationEngine.onMessageReceive(CorrelationEngine.java:107)
> >         at
> jolie.net.CommCore$CommChannelHandlerRunnable.handleDirectMessage(CommCore.java:532)
> >         at
> jolie.net.CommCore$CommChannelHandlerRunnable.handleMessage(CommCore.java:566)
> >         at
> jolie.net.CommCore$CommChannelHandlerRunnable.run(CommCore.java:597)
> >         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:745)
> > Exception in thread "main.ol-JolieThread-26" java.lang.NoSuchFieldError:
> scopeStack
> >         at jolie.SessionThread.<init>(SessionThread.java:258)
> >         at jolie.Interpreter.startServiceSession(Interpreter.java:1235)
> >         at
> jolie.runtime.correlation.CorrelationEngine.onMessageReceive(CorrelationEngine.java:107)
> >         at
> jolie.net.CommCore$CommChannelHandlerRunnable.handleDirectMessage(CommCore.java:532)
> >         at
> jolie.net.CommCore$CommChannelHandlerRunnable.handleMessage(CommCore.java:566)
> >         at
> jolie.net.CommCore$CommChannelHandlerRunnable.run(CommCore.java:597)
> >         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:745)
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>

[Jolie-devel] scopeStack?

[Matthias D. W. <mat...@ya...>]

Lately I get this issue in Jolie's Leonardo:

> Exception in thread "leonardo.ol-JolieThread-23" java.lang.NoSuchFieldError: scopeStack
>         at jolie.SessionThread.<init>(SessionThread.java:258)
>         at jolie.Interpreter.startServiceSession(Interpreter.java:1235)
>         at jolie.runtime.correlation.CorrelationEngine.onMessageReceive(CorrelationEngine.java:107)
>         at jolie.net.CommCore$CommChannelHandlerRunnable.handleDirectMessage(CommCore.java:532)
>         at jolie.net.CommCore$CommChannelHandlerRunnable.handleMessage(CommCore.java:566)
>         at jolie.net.CommCore$CommChannelHandlerRunnable.run(CommCore.java:597)
>         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:745)
> Exception in thread "main.ol-JolieThread-26" java.lang.NoSuchFieldError: scopeStack
>         at jolie.SessionThread.<init>(SessionThread.java:258)
>         at jolie.Interpreter.startServiceSession(Interpreter.java:1235)
>         at jolie.runtime.correlation.CorrelationEngine.onMessageReceive(CorrelationEngine.java:107)
>         at jolie.net.CommCore$CommChannelHandlerRunnable.handleDirectMessage(CommCore.java:532)
>         at jolie.net.CommCore$CommChannelHandlerRunnable.handleMessage(CommCore.java:566)
>         at jolie.net.CommCore$CommChannelHandlerRunnable.run(CommCore.java:597)
>         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:745)

Re: [Jolie-devel] Bug in JSON error replies

[Claudio G. <cg...@it...>]

done

--------------------------------------------------------------
Claudio Guidi Ph.D.
italianaSoftware s.r.l.
via Lasie 12/D - 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.

2015-03-11 18:36 GMT+01:00 Fabrizio Montesi <fam...@gm...>:

> Well, if you are really offended by code duplication, we could define a
> static final Type object to pass to the same json encoding method so that
> it will actually know the right type to do the job correctly!
>
> @Claudio: please commit meanwhile, I feel a lot better now that I
> understand how everything works. We can polish up later.
>
> - F
>
> On Wed, Mar 11, 2015 at 3:36 PM, Matthias Dieter Wallnöfer <
> mwa...@ya...> wrote:
>
>> Yeah, I do also not really like this code duplication, but okay, if you
>> Fabrizio can live with it I may too ;).
>>
>> Cheers,
>> Matthias
>>
>>
>>   Fabrizio Montesi <fam...@gm...> schrieb am 12:00 Mittwoch,
>> 11.März 2015:
>>
>>
>> Ah, now I get why the patch is necessary: because we don't have a type
>> for the entire data structure we send over JSON for faults, but only the
>> underlying fault data we have in the message. So the algorithm does not
>> know not to produce an array at the root.
>>
>> Damn. :-\
>>
>> With your patch, we're duplicating now the logic of the data structure we
>> send both in HttpProtocol, where we set the value with the fields
>> errorCode, data, etc., and in that new method you introduce for encoding
>> faults in JSON, which has to go and fetch these things again.
>>
>> Can you remove that space before { in error: ?
>>
>> I can live with that though, unless we have a better idea.
>>
>> @Matthias: Can you give this a quick check, too? It's OK for me now.
>>
>> Cheers,
>> Fabrizio
>>
>> On Wed, Mar 11, 2015 at 8:39 AM, Claudio Guidi <
>> cg...@it...> wrote:
>>
>> You need to specify the interface:
>>
>> include "console.iol"
>> include "string_utils.iol"
>>
>> execution{ concurrent }
>>
>> type T: void {
>> .b*: int
>> }
>>
>> inputPort Porta {
>> Location: "socket://locahost:11000"
>> Protocol: http{ .format="json" }
>> RequestResponse: test( void )( T ) throws F( undefined )
>> }
>>
>> main {
>> test()( response ) {
>> // response.error.b[ 0 ] = 8
>> response.b[ 0 ] = 8
>> // throw( F, response )
>> }
>>
>> }
>>
>> I did not commit my patch so far, so faults are still bugged
>>
>> --------------------------------------------------------------
>> Claudio Guidi Ph.D.
>> italianaSoftware s.r.l.
>> via Lasie 12/D - 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.
>>
>> 2015-03-11 0:54 GMT+01:00 Fabrizio Montesi <fam...@gm...>:
>>
>> Still, in trunk, I get the same erroneous behaviour with non-faults. Try
>> the attached. If you uncomment the first line in the RR you see the same
>> kind of error. What am I missing?
>>
>> - Fabrizio
>>
>> On Tue, Mar 10, 2015 at 10:51 PM, Claudio Guidi <
>> cg...@it...> wrote:
>>
>> No, the problem affects only faults
>> Il 10/mar/2015 21:04 "Fabrizio Montesi" <fam...@gm...> ha scritto:
>>
>> Mmh could be a more general bug that applies to all values rather than
>> just faults..
>>
>> Matthias, what do you think?
>>
>> - F
>>
>> 2015-03-10 18:11 GMT+01:00 Claudio Guidi <cg...@it...>:
>>
>> Hi http guys,
>>
>> I found this bugs in JSON error messages:
>>
>> *First:*
>>
>>
>> include "console.iol"
>> include "string_utils.iol"
>>
>> execution{ concurrent }
>>
>> type TESTR: void {
>> .a*: int
>> }
>>
>> type FT: void {
>> .b*:int
>> }
>>
>> inputPort Porta {
>> Location: "socket://locahost:11000"
>> Protocol: http{ .format="json" }
>> RequestResponse: test( void )( TESTR ) throws F( FT )
>> }
>>
>> main {
>> test()( response ) {
>> response.b[ 0 ] = 8;
>> throw( F, response )
>> }
>>
>> }
>>
>> This service replies with a b inside field error.data as an object
>> instead of a vector
>>
>> *Second:*
>> include "console.iol"
>> include "string_utils.iol"
>>
>> execution{ concurrent }
>>
>> type TESTR: void {
>> .a*: int
>> }
>>
>> type FT: void {
>> .error*: void {
>> .b*:int
>> }
>> }
>>
>> inputPort Porta {
>> Location: "socket://locahost:11000"
>> Protocol: http{ .format="json" }
>> RequestResponse: test( void )( TESTR ) throws F( FT )
>> }
>>
>> main {
>> test()( response ) {
>> response.error.b[ 0 ] = 8;
>> throw( F, response )
>> }
>>
>> }
>>
>> Thi service replies with
>>
>> { error[ [{ data .... ]
>>
>> instead of
>>
>> { error: { data: { error[]
>>
>> Please find in attachment my patches.
>> Could you check them?
>>
>>
>>
>>
>> --------------------------------------------------------------
>> Claudio Guidi Ph.D.
>> italianaSoftware s.r.l.
>> via Lasie 12/D - 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.
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Jolie-devel mailing list
>> Jol...@li...
>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>>
>> _______________________________________________
>> Jolie-devel mailing list
>> Jol...@li...
>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>
>>
>>
>

Re: [Jolie-devel] Bug in JSON error replies

[Fabrizio M. <fam...@gm...>]

Well, if you are really offended by code duplication, we could define a
static final Type object to pass to the same json encoding method so that
it will actually know the right type to do the job correctly!

@Claudio: please commit meanwhile, I feel a lot better now that I
understand how everything works. We can polish up later.

- F

On Wed, Mar 11, 2015 at 3:36 PM, Matthias Dieter Wallnöfer <
mwa...@ya...> wrote:

> Yeah, I do also not really like this code duplication, but okay, if you
> Fabrizio can live with it I may too ;).
>
> Cheers,
> Matthias
>
>
>   Fabrizio Montesi <fam...@gm...> schrieb am 12:00 Mittwoch,
> 11.März 2015:
>
>
> Ah, now I get why the patch is necessary: because we don't have a type for
> the entire data structure we send over JSON for faults, but only the
> underlying fault data we have in the message. So the algorithm does not
> know not to produce an array at the root.
>
> Damn. :-\
>
> With your patch, we're duplicating now the logic of the data structure we
> send both in HttpProtocol, where we set the value with the fields
> errorCode, data, etc., and in that new method you introduce for encoding
> faults in JSON, which has to go and fetch these things again.
>
> Can you remove that space before { in error: ?
>
> I can live with that though, unless we have a better idea.
>
> @Matthias: Can you give this a quick check, too? It's OK for me now.
>
> Cheers,
> Fabrizio
>
> On Wed, Mar 11, 2015 at 8:39 AM, Claudio Guidi <
> cg...@it...> wrote:
>
> You need to specify the interface:
>
> include "console.iol"
> include "string_utils.iol"
>
> execution{ concurrent }
>
> type T: void {
> .b*: int
> }
>
> inputPort Porta {
> Location: "socket://locahost:11000"
> Protocol: http{ .format="json" }
> RequestResponse: test( void )( T ) throws F( undefined )
> }
>
> main {
> test()( response ) {
> // response.error.b[ 0 ] = 8
> response.b[ 0 ] = 8
> // throw( F, response )
> }
>
> }
>
> I did not commit my patch so far, so faults are still bugged
>
> --------------------------------------------------------------
> Claudio Guidi Ph.D.
> italianaSoftware s.r.l.
> via Lasie 12/D - 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.
>
> 2015-03-11 0:54 GMT+01:00 Fabrizio Montesi <fam...@gm...>:
>
> Still, in trunk, I get the same erroneous behaviour with non-faults. Try
> the attached. If you uncomment the first line in the RR you see the same
> kind of error. What am I missing?
>
> - Fabrizio
>
> On Tue, Mar 10, 2015 at 10:51 PM, Claudio Guidi <
> cg...@it...> wrote:
>
> No, the problem affects only faults
> Il 10/mar/2015 21:04 "Fabrizio Montesi" <fam...@gm...> ha scritto:
>
> Mmh could be a more general bug that applies to all values rather than
> just faults..
>
> Matthias, what do you think?
>
> - F
>
> 2015-03-10 18:11 GMT+01:00 Claudio Guidi <cg...@it...>:
>
> Hi http guys,
>
> I found this bugs in JSON error messages:
>
> *First:*
>
>
> include "console.iol"
> include "string_utils.iol"
>
> execution{ concurrent }
>
> type TESTR: void {
> .a*: int
> }
>
> type FT: void {
> .b*:int
> }
>
> inputPort Porta {
> Location: "socket://locahost:11000"
> Protocol: http{ .format="json" }
> RequestResponse: test( void )( TESTR ) throws F( FT )
> }
>
> main {
> test()( response ) {
> response.b[ 0 ] = 8;
> throw( F, response )
> }
>
> }
>
> This service replies with a b inside field error.data as an object instead
> of a vector
>
> *Second:*
> include "console.iol"
> include "string_utils.iol"
>
> execution{ concurrent }
>
> type TESTR: void {
> .a*: int
> }
>
> type FT: void {
> .error*: void {
> .b*:int
> }
> }
>
> inputPort Porta {
> Location: "socket://locahost:11000"
> Protocol: http{ .format="json" }
> RequestResponse: test( void )( TESTR ) throws F( FT )
> }
>
> main {
> test()( response ) {
> response.error.b[ 0 ] = 8;
> throw( F, response )
> }
>
> }
>
> Thi service replies with
>
> { error[ [{ data .... ]
>
> instead of
>
> { error: { data: { error[]
>
> Please find in attachment my patches.
> Could you check them?
>
>
>
>
> --------------------------------------------------------------
> Claudio Guidi Ph.D.
> italianaSoftware s.r.l.
> via Lasie 12/D - 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.
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
>
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
>
>

Re: [Jolie-devel] Bug in JSON error replies

[Matthias D. W. <mwa...@ya...>]

Yeah, I do also not really like this code duplication, but okay, if you Fabrizio can live with it I may too ;).
Cheers,Matthias


     Fabrizio Montesi <fam...@gm...> schrieb am 12:00 Mittwoch, 11.März 2015:
   

 Ah, now I get why the patch is necessary: because we don't have a type for the entire data structure we send over JSON for faults, but only the underlying fault data we have in the message. So the algorithm does not know not to produce an array at the root.
Damn. :-\

With your patch, we're duplicating now the logic of the data structure we send both in HttpProtocol, where we set the value with the fields errorCode, data, etc., and in that new method you introduce for encoding faults in JSON, which has to go and fetch these things again.
Can you remove that space before { in error: ? 
I can live with that though, unless we have a better idea.

@Matthias: Can you give this a quick check, too? It's OK for me now.
Cheers,Fabrizio
On Wed, Mar 11, 2015 at 8:39 AM, Claudio Guidi <cg...@it...> wrote:

You need to specify the interface:
include "console.iol"include "string_utils.iol"
execution{ concurrent }
type T: void { .b*: int}
inputPort Porta { Location: "socket://locahost:11000" Protocol: http{ .format="json" } RequestResponse: test( void )( T ) throws F( undefined )}
main {  test()( response ) { // response.error.b[ 0 ] = 8  response.b[ 0 ] = 8  // throw( F, response ) }
}

I did not commit my patch so far, so faults are still bugged
--------------------------------------------------------------
Claudio Guidi Ph.D.
italianaSoftware s.r.l. 
via Lasie 12/D - 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.
2015-03-11 0:54 GMT+01:00 Fabrizio Montesi <fam...@gm...>:

Still, in trunk, I get the same erroneous behaviour with non-faults. Try the attached. If you uncomment the first line in the RR you see the same kind of error. What am I missing?
- Fabrizio
On Tue, Mar 10, 2015 at 10:51 PM, Claudio Guidi <cg...@it...> wrote:

No, the problem affects only faultsIl 10/mar/2015 21:04 "Fabrizio Montesi" <fam...@gm...> ha scritto:

Mmh could be a more general bug that applies to all values rather than just faults..
Matthias, what do you think?
- F
2015-03-10 18:11 GMT+01:00 Claudio Guidi <cg...@it...>:

Hi http guys,

I found this bugs in JSON error messages:

First:


include "console.iol"include "string_utils.iol"
execution{ concurrent }
type TESTR: void { .a*: int}
type FT: void { .b*:int }
inputPort Porta { Location: "socket://locahost:11000" Protocol: http{ .format="json" } RequestResponse: test( void )( TESTR ) throws F( FT )}
main {  test()( response ) { response.b[ 0 ] = 8;  throw( F, response ) }
}

This service replies with a b inside field error.data as an object instead of a vector

Second:
include "console.iol"include "string_utils.iol"
execution{ concurrent }
type TESTR: void { .a*: int}
type FT: void { .error*: void { .b*:int } }
inputPort Porta { Location: "socket://locahost:11000" Protocol: http{ .format="json" } RequestResponse: test( void )( TESTR ) throws F( FT )}
main {  test()( response ) { response.error.b[ 0 ] = 8;  throw( F, response ) }
}
Thi service replies with

{ error[ [{ data .... ]

instead of 

{ error: { data: { error[] 

Please find in attachment my patches.
Could you check them?




--------------------------------------------------------------
Claudio Guidi Ph.D.
italianaSoftware s.r.l. 
via Lasie 12/D - 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.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jolie-devel mailing list
Jol...@li...
https://lists.sourceforge.net/lists/listinfo/jolie-devel











------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jolie-devel mailing list
Jol...@li...
https://lists.sourceforge.net/lists/listinfo/jolie-devel


   

Re: [Jolie-devel] Prebufferedinputstream

[Fabrizio M. <fam...@gm...>]

Sounds good! As long as that inputStream.available() does not introduce any
weird blockings in places where we do not expect them.

Cheers,
F

On Wed, Mar 11, 2015 at 3:20 PM, Matthias Dieter Wallnöfer <
mwa...@ya...> wrote:

> Patch
>
>
>   Matthias Dieter Wallnöfer <mwa...@ya...> schrieb am 14:30
> Mittwoch, 11.März 2015:
>
>
> Yeah, in theory we could return the sum of both which I had also in a
> first version of the patch: count >= 0 ? count : 0 + istream.available().
>
> @Claudio: could you try that?
>
> Cheers,
> Matthias
>
>
>   Fabrizio Montesi <fam...@gm...> schrieb am 11:56 Mittwoch,
> 11.März 2015:
>
>
> Just wondering what the expected Java semantics is.
>
> According to this:
>
>
> http://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html#available()
>
> I think that we should return the number of bytes we have in the buffer,
> if any, or available() from the underlying buffer otherwise ? We need to
> pay attention to where available() is used in our code to be sure.
>
> Cheers,
> Fabrizio
>
> On Wed, Mar 11, 2015 at 8:47 AM, Matthias Dieter Wallnöfer <
> mwa...@ya...> wrote:
>
> I could have been wrong. We had the method
>
> hasCachedData()
>
> for the buffered data, so I thought that
>
> available()
> should only work on the underlying buffer. I modeled this according to
>
> public synchronized boolean isReady()
> throws IOException
> in LocalSocketCommChannel.java which checks for hasCachedData() first and
> if unsuccessful it tries to read the InputStream's first byte (the local
> sockets do not override available(), so it returns always 0).
>
> Cheers,
> Matthias
>
>
>   Fabrizio Montesi <fam...@gm...> schrieb am 3:26 Mittwoch,
> 11.März 2015:
>
>
> Hi Matthias,
>
> What's the reasoning for having available() in PreBufferedInputStream use
> the underlying input stream without checking for data in the buffer first?
> Shouldn't we do the latter?
>
> Cheers,
> Fabrizio
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
>
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
>
>

Re: [Jolie-devel] Prebufferedinputstream

[Matthias D. W. <mwa...@ya...>]

Patch 

     Matthias Dieter Wallnöfer <mwa...@ya...> schrieb am 14:30 Mittwoch, 11.März 2015:
   

 Yeah, in theory we could return the sum of both which I had also in a first version of the patch: count >= 0 ? count : 0 + istream.available().
@Claudio: could you try that?
Cheers,Matthias


     Fabrizio Montesi <fam...@gm...> schrieb am 11:56 Mittwoch, 11.März 2015:
   

 Just wondering what the expected Java semantics is.
According to this:
http://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html#available()

I think that we should return the number of bytes we have in the buffer, if any, or available() from the underlying buffer otherwise ? We need to pay attention to where available() is used in our code to be sure.
Cheers,Fabrizio
On Wed, Mar 11, 2015 at 8:47 AM, Matthias Dieter Wallnöfer <mwa...@ya...> wrote:

I could have been wrong. We had the method 
hasCachedData()
for the buffered data, so I thought thatavailable()
should only work on the underlying buffer. I modeled this according to 
 public synchronized boolean isReady() throws IOExceptionin LocalSocketCommChannel.java which checks for hasCachedData() first and if unsuccessful it tries to read the InputStream's first byte (the local sockets do not override available(), so it returns always 0).
Cheers,Matthias
 

     Fabrizio Montesi <fam...@gm...> schrieb am 3:26 Mittwoch, 11.März 2015:
   

 Hi Matthias,
What's the reasoning for having available() in PreBufferedInputStream use the underlying input stream without checking for data in the buffer first? Shouldn't we do the latter?
Cheers,Fabrizio
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jolie-devel mailing list
Jol...@li...
https://lists.sourceforge.net/lists/listinfo/jolie-devel


    



    
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jolie-devel mailing list
Jol...@li...
https://lists.sourceforge.net/lists/listinfo/jolie-devel


   

Re: [Jolie-devel] Better document Database extension

[Matthias D. W. <mwa...@ya...>]

include "weatherService.iol"
include "string_utils.iol"
include "xml_utils.iol"
include "database.iol"
include "console.iol"

/*
 * weatherServiceCallerSql.ol - stores weather data in a HSQLDB DB
 */
 
main
{
    // fetch weather
    with( request ) {
        .CityName = City;
        .CountryName = Country
    };
    GetWeather@GlobalWeatherSoap( request )( response );
    r = response.GetWeatherResult;

    // connect to DB
    with ( connectionInfo ) {
        .username = "sa";
        .password = "";
        .host = "";
        .database = "file:weatherdb/weatherdb"; // "." for memory-only
        .driver = "hsqldb_embedded"
    };
    connect@Database( connectionInfo )( void );

    // create table if it does not exist
    scope ( createTable ) {
        install ( SQLException => println@Console("Weather table already there")() );
        updateRequest =
            "CREATE TABLE weather(city VARCHAR(50) NOT NULL, " +
            "country VARCHAR(50) NOT NULL, data VARCHAR(1024) NOT NULL, " +
            "PRIMARY KEY(city, country))";
        update@Database( updateRequest )( ret )
    };

    // insert/update current record
    scope ( update ) {
        install ( SQLException =>
            updateRequest =
                "UPDATE weather SET data = :data WHERE city = :city " +
                "AND country = :country";
            updateRequest.city = City;
            updateRequest.country = Country;
            updateRequest.data = r;
            update@Database( updateRequest )( ret )
        );
        updateRequest =
            "INSERT INTO weather(city, country, data) " +
            "VALUES (:city, :country, :data)";
        updateRequest.city = City;
        updateRequest.country = Country;
        updateRequest.data = r;
        update@Database( updateRequest )( ret )
    };

    // print inserted content
    queryRequest =
        "SELECT city, country, data FROM weather " +
        "WHERE city=:city AND country=:country";
    queryRequest.city = City;
    queryRequest.country = Country;
    query@Database( queryRequest )( queryResponse );
    
    // HSQLDB needs the attributes to be upcased when requesting content
    println@Console("City: " + queryResponse.row[0].CITY)();
    println@Console("Country: " + queryResponse.row[0].COUNTRY)();
    println@Console("Data: " + queryResponse.row[0].DATA)();
    
    // shutdown DB
    update@Database( "SHUTDOWN" )( ret )
}

Re: [Jolie-devel] Better document Database extension

[Matthias D. W. <mwa...@ya...>]

    [ retrieve(request)(response) {
        query@Database(
            "select * from Todo.TodoItem where id=:id" {
                .id = request.id
            }
        )(response);
        if (#response.row == 1) {
            response << response.row[0]
        }
    } ]    
Also in this case we could just use the -> alias syntax or am I wrong?

I programmed once something which interrogated meteorologic data and stored it into HSQLDB, let me try to look for that example...I could share this as well. 

     Fabrizio Montesi <fam...@gm...> schrieb am 14:39 Mittwoch, 11.März 2015:
   

 Cool!
Can we set it up so that it actually works with the derby backend maybe?
I've made some modifications, check if you like them. Basically I put everything inline and optimised the retrieveAll op.
Cheers,F
On Wed, Mar 11, 2015 at 2:24 PM, Matthias Dieter Wallnöfer <mwa...@ya...> wrote:

I share with you an easy example which defines a basic webservice on top of a TodoItem(id, text) relation.
Cheers,Matthias 

     Fabrizio Montesi <fam...@gm...> schrieb am 12:10 Mittwoch, 11.März 2015:
   

 I agree wholeheartedly, and I think everybody else does too.
And, now we also have a super cool syntax to show off. :-)
query@Database( "select * from users where id=:id" { .id = 5 } )( result )
How about we write a little service example at the beginning of the page to showcase the features?
Best,Fabrizio
On Wed, Mar 11, 2015 at 9:04 AM, Matthias Dieter Wallnöfer <mwa...@ya...> wrote:

Hi list,
I wonder if we could better document our Database extension. When I have to work with it, I always need to consult Jolie / Code / [r3291] /trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java in order to find out the correct driver name ("driver") or the filename of the driver JAR.
Btw, also the filenames are not always correct: my MS SQL Server driver provide sqljdbc41.jar, sqljdbc4.jar and sqljdbc.jar and not jdbc-sqlserver.jar as stated in the source code. No idea how we could address this inconsistency, for the moment I always create symbolic links.

|   |
|   |   |   |   |   |
| Jolie / Code / [r3291] /trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java/*************************************************************************** * Copyright (C) 2008-2014 by Fabrizio Montesi <fam...@gm...> *  |
|  |
| Auf sourceforge.net anzeigen | Vorschau nach Yahoo |
|  |
|   |

 The API documentation (http://docs.jolie-lang.org/#!documentation/jsl/Database.html) contains little to no real usage example (select, insert, update, delete with or without parameters).

We should definitely collect some short and simple Jolie DB examples and explain them in our docs.
Just my opinion,Matthias

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jolie-devel mailing list
Jol...@li...
https://lists.sourceforge.net/lists/listinfo/jolie-devel





    



   

Re: [Jolie-devel] Better document Database extension

[Fabrizio M. <fam...@gm...>]

Cool!

Can we set it up so that it actually works with the derby backend maybe?

I've made some modifications, check if you like them. Basically I put
everything inline and optimised the retrieveAll op.

Cheers,
F

On Wed, Mar 11, 2015 at 2:24 PM, Matthias Dieter Wallnöfer <
mwa...@ya...> wrote:

> I share with you an easy example which defines a basic webservice on top
> of a TodoItem(id, text) relation.
>
> Cheers,
> Matthias
>
>
>   Fabrizio Montesi <fam...@gm...> schrieb am 12:10 Mittwoch,
> 11.März 2015:
>
>
> I agree wholeheartedly, and I think everybody else does too.
>
> And, now we also have a super cool syntax to show off. :-)
>
> query@Database( "select * from users where id=:id" { .id = 5 } )( result )
>
> How about we write a little service example at the beginning of the page
> to showcase the features?
>
> Best,
> Fabrizio
>
> On Wed, Mar 11, 2015 at 9:04 AM, Matthias Dieter Wallnöfer <
> mwa...@ya...> wrote:
>
> Hi list,
>
> I wonder if we could better document our Database extension. When I have
> to work with it, I always need to consult Jolie / Code / [r3291]
> /trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java
> <http://sourceforge.net/p/jolie/code/HEAD/tree/trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java>
> in order to find out the correct driver name ("driver") or the filename of
> the driver JAR.
>
> Btw, also the filenames are not always correct: my MS SQL Server driver
> provide *sqljdbc41.jar*, *sqljdbc4.jar* and *sqljdbc.jar* and not
> *jdbc-sqlserver.jar* as stated in the source code. No idea how we could
> address this inconsistency, for the moment I always create symbolic links.
>
>
>
>
>
>
> Jolie / Code / [r3291]
> /trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java
> <http://sourceforge.net/p/jolie/code/HEAD/tree/trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java>
> /***************************************************************************
> * Copyright (C) 2008-2014 by Fabrizio Montesi <fam...@gm...> *
> Auf sourceforge.net anzeigen
> <http://sourceforge.net/p/jolie/code/HEAD/tree/trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java>
> Vorschau nach Yahoo
>
>
> The API documentation (
> http://docs.jolie-lang.org/#!documentation/jsl/Database.html) contains
> little to no real usage example (select, insert, update, delete with or
> without parameters).
>
> We should definitely collect some short and simple Jolie DB examples and
> explain them in our docs.
>
> Just my opinion,
> Matthias
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
>
>
>
>

Re: [Jolie-devel] Prebufferedinputstream

[Matthias D. W. <mwa...@ya...>]

Yeah, in theory we could return the sum of both which I had also in a first version of the patch: count >= 0 ? count : 0 + istream.available().
@Claudio: could you try that?
Cheers,Matthias


     Fabrizio Montesi <fam...@gm...> schrieb am 11:56 Mittwoch, 11.März 2015:
   

 Just wondering what the expected Java semantics is.
According to this:
http://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html#available()

I think that we should return the number of bytes we have in the buffer, if any, or available() from the underlying buffer otherwise ? We need to pay attention to where available() is used in our code to be sure.
Cheers,Fabrizio
On Wed, Mar 11, 2015 at 8:47 AM, Matthias Dieter Wallnöfer <mwa...@ya...> wrote:

I could have been wrong. We had the method 
hasCachedData()
for the buffered data, so I thought thatavailable()
should only work on the underlying buffer. I modeled this according to 
 public synchronized boolean isReady() throws IOExceptionin LocalSocketCommChannel.java which checks for hasCachedData() first and if unsuccessful it tries to read the InputStream's first byte (the local sockets do not override available(), so it returns always 0).
Cheers,Matthias
 

     Fabrizio Montesi <fam...@gm...> schrieb am 3:26 Mittwoch, 11.März 2015:
   

 Hi Matthias,
What's the reasoning for having available() in PreBufferedInputStream use the underlying input stream without checking for data in the buffer first? Shouldn't we do the latter?
Cheers,Fabrizio
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jolie-devel mailing list
Jol...@li...
https://lists.sourceforge.net/lists/listinfo/jolie-devel


    



   

Re: [Jolie-devel] Better document Database extension

[Matthias D. W. <mwa...@ya...>]

I share with you an easy example which defines a basic webservice on top of a TodoItem(id, text) relation.
Cheers,Matthias 

     Fabrizio Montesi <fam...@gm...> schrieb am 12:10 Mittwoch, 11.März 2015:
   

 I agree wholeheartedly, and I think everybody else does too.
And, now we also have a super cool syntax to show off. :-)
query@Database( "select * from users where id=:id" { .id = 5 } )( result )
How about we write a little service example at the beginning of the page to showcase the features?
Best,Fabrizio
On Wed, Mar 11, 2015 at 9:04 AM, Matthias Dieter Wallnöfer <mwa...@ya...> wrote:

Hi list,
I wonder if we could better document our Database extension. When I have to work with it, I always need to consult Jolie / Code / [r3291] /trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java in order to find out the correct driver name ("driver") or the filename of the driver JAR.
Btw, also the filenames are not always correct: my MS SQL Server driver provide sqljdbc41.jar, sqljdbc4.jar and sqljdbc.jar and not jdbc-sqlserver.jar as stated in the source code. No idea how we could address this inconsistency, for the moment I always create symbolic links.

|   |
|   |   |   |   |   |
| Jolie / Code / [r3291] /trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java/*************************************************************************** * Copyright (C) 2008-2014 by Fabrizio Montesi <fam...@gm...> *  |
|  |
| Auf sourceforge.net anzeigen | Vorschau nach Yahoo |
|  |
|   |

 The API documentation (http://docs.jolie-lang.org/#!documentation/jsl/Database.html) contains little to no real usage example (select, insert, update, delete with or without parameters).

We should definitely collect some short and simple Jolie DB examples and explain them in our docs.
Just my opinion,Matthias

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jolie-devel mailing list
Jol...@li...
https://lists.sourceforge.net/lists/listinfo/jolie-devel





   

Re: [Jolie-devel] HTTP URI UTF-8 parsing

[Matthias D. W. <mwa...@ya...>]

Just apply my patch, then start a local Leonardo on Jolie's website and click on Blogs and/or Tutorials. You will immediately notice that it gets stuck.
Considering Leonardo's stacktrace you will see that the chunk parsing code is the cause...
Cheers,Matthias
 

     Fabrizio Montesi <fam...@gm...> schrieb am 12:07 Mittwoch, 11.März 2015:
   

 I wrote that code in ancient times. Let me know how I can help. :-)
On Tue, Mar 10, 2015 at 10:23 PM, Matthias Dieter Wallnöfer <mwa...@ya...> wrote:

Exactly, it works like this. Therefore readAll in HttpParser works directly with the byte array deriving from the InputStream. 
But the header needs to be parsed in UTF-8 to get Unicode-enabled URIs. It would be nice if someone could help me with porting/fixing the chunk parsing code. ..
Von Samsung Mobile gesendet

-------- Ursprüngliche Nachricht --------Von: Fabrizio Montesi  Datum:10.03.2015 21:05 (GMT+01:00) An: Matthias Dieter Wallnöfer  Cc: jol...@li... Betreff: Re: [Jolie-devel] HTTP URI UTF-8 parsing 
Shouldn't we use UTF-8 only for the headers and then whatever is dictacted by the headers for the rest?
- F
On Tue, Mar 10, 2015 at 7:44 PM, Matthias Dieter Wallnöfer <mat...@ya...> wrote:

Hi list,

Jolie's HTTP module has the limitation, that it currently does not
recognise UTF-8 characters in HTTP URIs, which today is standard.
Looking at the HTTP scanner I noticed that we always parse as ASCII.

I have tried to introduce a UTF-8 reader on top of the InputStream which
seems to partially work: one big issue which I came across is the chunk
parsing code.

I know that this is a tricky part. Previously I tried a reconversion in
the HttpParser with no success, so I think it needs to be parsed
correctly already at the beginning.

> Exception in thread "main.ol-JolieThread-42" java.lang.NumberFormatException: For input string: "?xml"
>       at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>       at java.lang.Integer.parseInt(Integer.java:492)
>       at jolie.net.http.HttpParser.readContent(HttpParser.java:290)
>       at jolie.net.http.HttpParser.parse(HttpParser.java:352)
>       at jolie.net.HttpProtocol.recv_internal(HttpProtocol.java:1236)
>       at jolie.net.HttpProtocol.recv(HttpProtocol.java:1344)
>       at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:94)
>       at jolie.net.CommChannel.recv(CommChannel.java:198)
>       at jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:227)
>       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:745)
> Exception in thread "main.ol-JolieThread-29" java.lang.IndexOutOfBoundsException
>       at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:92)
>       at jolie.net.PreBufferedInputStream.read(PreBufferedInputStream.java:135)
>       at jolie.net.http.HttpParser.blockingRead(HttpParser.java:235)
>       at jolie.net.http.HttpParser.readContent(HttpParser.java:296)
>       at jolie.net.http.HttpParser.parse(HttpParser.java:352)
>       at jolie.net.HttpProtocol.recv_internal(HttpProtocol.java:1236)
>       at jolie.net.HttpProtocol.recv(HttpProtocol.java:1344)
>       at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:94)
>       at jolie.net.CommChannel.recv(CommChannel.java:198)
>       at jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:227)
>       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:745)

Cheers,
Matthias

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jolie-devel mailing list
Jol...@li...
https://lists.sourceforge.net/lists/listinfo/jolie-devel







   

Re: [Jolie-devel] Better document Database extension

[Fabrizio M. <fam...@gm...>]

I agree wholeheartedly, and I think everybody else does too.

And, now we also have a super cool syntax to show off. :-)

query@Database( "select * from users where id=:id" { .id = 5 } )( result )

How about we write a little service example at the beginning of the page to
showcase the features?

Best,
Fabrizio

On Wed, Mar 11, 2015 at 9:04 AM, Matthias Dieter Wallnöfer <
mwa...@ya...> wrote:

> Hi list,
>
> I wonder if we could better document our Database extension. When I have
> to work with it, I always need to consult Jolie / Code / [r3291]
> /trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java
> <http://sourceforge.net/p/jolie/code/HEAD/tree/trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java>
> in order to find out the correct driver name ("driver") or the filename of
> the driver JAR.
>
> Btw, also the filenames are not always correct: my MS SQL Server driver
> provide *sqljdbc41.jar*, *sqljdbc4.jar* and *sqljdbc.jar* and not
> *jdbc-sqlserver.jar* as stated in the source code. No idea how we could
> address this inconsistency, for the moment I always create symbolic links.
>
>
>
>
>
>
> Jolie / Code / [r3291]
> /trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java
> <http://sourceforge.net/p/jolie/code/HEAD/tree/trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java>
> /***************************************************************************
> * Copyright (C) 2008-2014 by Fabrizio Montesi <fam...@gm...> *
> Auf sourceforge.net anzeigen
> <http://sourceforge.net/p/jolie/code/HEAD/tree/trunk/javaServices/coreJavaServices/src/joliex/db/DatabaseService.java>
> Vorschau nach Yahoo
>
>
> The API documentation (
> http://docs.jolie-lang.org/#!documentation/jsl/Database.html) contains
> little to no real usage example (select, insert, update, delete with or
> without parameters).
>
> We should definitely collect some short and simple Jolie DB examples and
> explain them in our docs.
>
> Just my opinion,
> Matthias
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
>

Re: [Jolie-devel] HTTP URI UTF-8 parsing

[Fabrizio M. <fam...@gm...>]

I wrote that code in ancient times. Let me know how I can help. :-)

On Tue, Mar 10, 2015 at 10:23 PM, Matthias Dieter Wallnöfer <
mwa...@ya...> wrote:

> Exactly, it works like this. Therefore readAll in HttpParser works
> directly with the byte array deriving from the InputStream.
>
> But the header needs to be parsed in UTF-8 to get Unicode-enabled URIs. It
> would be nice if someone could help me with porting/fixing the chunk
> parsing code. ..
>
> Von Samsung Mobile gesendet
>
>
> -------- Ursprüngliche Nachricht --------
> Von: Fabrizio Montesi
> Datum:10.03.2015 21:05 (GMT+01:00)
> An: Matthias Dieter Wallnöfer
> Cc: jol...@li...
> Betreff: Re: [Jolie-devel] HTTP URI UTF-8 parsing
>
> Shouldn't we use UTF-8 only for the headers and then whatever is dictacted
> by the headers for the rest?
>
> - F
>
> On Tue, Mar 10, 2015 at 7:44 PM, Matthias Dieter Wallnöfer <
> mat...@ya...> wrote:
>
>> Hi list,
>>
>> Jolie's HTTP module has the limitation, that it currently does not
>> recognise UTF-8 characters in HTTP URIs, which today is standard.
>> Looking at the HTTP scanner I noticed that we always parse as ASCII.
>>
>> I have tried to introduce a UTF-8 reader on top of the InputStream which
>> seems to partially work: one big issue which I came across is the chunk
>> parsing code.
>>
>> I know that this is a tricky part. Previously I tried a reconversion in
>> the HttpParser with no success, so I think it needs to be parsed
>> correctly already at the beginning.
>>
>> > Exception in thread "main.ol-JolieThread-42"
>> java.lang.NumberFormatException: For input string: "?xml"
>> >       at
>> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>> >       at java.lang.Integer.parseInt(Integer.java:492)
>> >       at jolie.net.http.HttpParser.readContent(HttpParser.java:290)
>> >       at jolie.net.http.HttpParser.parse(HttpParser.java:352)
>> >       at jolie.net.HttpProtocol.recv_internal(HttpProtocol.java:1236)
>> >       at jolie.net.HttpProtocol.recv(HttpProtocol.java:1344)
>> >       at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:94)
>> >       at jolie.net.CommChannel.recv(CommChannel.java:198)
>> >       at
>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:227)
>> >       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:745)
>> > Exception in thread "main.ol-JolieThread-29"
>> java.lang.IndexOutOfBoundsException
>> >       at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:92)
>> >       at
>> jolie.net.PreBufferedInputStream.read(PreBufferedInputStream.java:135)
>> >       at jolie.net.http.HttpParser.blockingRead(HttpParser.java:235)
>> >       at jolie.net.http.HttpParser.readContent(HttpParser.java:296)
>> >       at jolie.net.http.HttpParser.parse(HttpParser.java:352)
>> >       at jolie.net.HttpProtocol.recv_internal(HttpProtocol.java:1236)
>> >       at jolie.net.HttpProtocol.recv(HttpProtocol.java:1344)
>> >       at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:94)
>> >       at jolie.net.CommChannel.recv(CommChannel.java:198)
>> >       at
>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:227)
>> >       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:745)
>>
>> Cheers,
>> Matthias
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Jolie-devel mailing list
>> Jol...@li...
>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>
>>
>