jolie-devel Mailing List for Jolie (Page 2)
A service-oriented programming language.
Brought to you by:
fmontesi
You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(18) |
Nov
(28) |
Dec
(36) |
2014 |
Jan
(21) |
Feb
(21) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(14) |
Sep
(14) |
Oct
(5) |
Nov
(26) |
Dec
(8) |
2015 |
Jan
(21) |
Feb
(194) |
Mar
(113) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Matthias D. W. <mat...@ya...> - 2015-03-14 21:14:38
|
I have googled around the Web and I think we are done, since this problem is due to a limitation in curl: http://curl.haxx.se/mail/lib-2009-10/0310.html. This means that it is client's responsability to escape special characters in URLs. I have done some testing in various webbrowsers and they perform the necessary conversions. Hence this issue can be considered fixed :). Cheers, Matthias Fabrizio Montesi schrieb: > 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 > > |
From: Matthias D. W. <mat...@ya...> - 2015-03-14 20:24:12
|
Okay, I will comment it better. Fabrizio Montesi schrieb: > Cool! Can you briefly explain the difference in words wrt what we were > doing before? We need to comment this code I think, chunk processing is > a bit complex. > > Ciao, > F > > On Sat, Mar 14, 2015 at 8:44 PM, Matthias Dieter Wallnöfer > <mat...@ya... <mailto:mat...@ya...>> wrote: > > Fabrizio, > > this implements now the complete HTTP chunks syntax as explained in > http://tools.ietf.org/html/rfc2616#section-3.6.1. We were missing some > important points like the additional HTTP headers (= trailer) or the > chunk parameters. > > I have tested it with the Jolie website and it definitely works. > > Now we should be one step further to the UTF-8 parsing of header > components, but I will retry keeping the scanner as it is (non UTF-8) > otherwise, when introducing the InputStreamReader, this gets messed up > and I did not manage to find a fix since the reader intercepts the > stream. > > Cheers, > Matthias > > Matthias Dieter Wallnöfer schrieb: > > As far as I see in the code we are *only* using it for header parsing, > > since the content parsing is handled directly with a low-level > > InputStream.read(). > > > > Matthias > > > > Fabrizio Montesi schrieb: > >> Hi Matthias, > >> > >> Just a quick check up question: are you sure that this will not > affect > >> content containing \r without \n (which can happen AFAIK)? I > guess not, > >> right, as we do not use the Scanner for the content parsing. > >> > >> - Fabrizio > >> > >> ---------- Forwarded message ---------- > >> From: *Repository Jolie code* <no...@co... > <mailto:no...@co...> > >> <mailto:no...@co... > <mailto:no...@co...>>> > >> Date: Sat, Mar 14, 2015 at 7:15 PM > >> Subject: [jolie:code] [r3303] - mwallnoefer2: http parsing - some > small > >> code improvements which I separately commit before the UTF-8 parsing > >> To: Repository Jolie code <no...@co... > <mailto:no...@co...> > >> <mailto:no...@co... > <mailto:no...@co...>>> > >> > >> > >> http parsing - some small code improvements which I separately commit > >> before the UTF-8 parsing http://sourceforge.net/p/jolie/code/3303/ > >> <http://sourceforge.net/p/jolie/code/3303> > >> > >> > ------------------------------------------------------------------------ > >> > >> Sent from sourceforge.net <http://sourceforge.net> > <http://sourceforge.net> because you indicated > >> interest in https://sourceforge.net/p/jolie/code/ > >> <https://sourceforge.net/p/jolie/code> > >> > >> To unsubscribe from further messages, please visit > >> https://sourceforge.net/auth/subscriptions/ > >> <https://sourceforge.net/auth/subscriptions> > >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> 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... > <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 > |
From: Fabrizio M. <fam...@gm...> - 2015-03-14 20:06:30
|
Cool! Can you briefly explain the difference in words wrt what we were doing before? We need to comment this code I think, chunk processing is a bit complex. Ciao, F On Sat, Mar 14, 2015 at 8:44 PM, Matthias Dieter Wallnöfer < mat...@ya...> wrote: > Fabrizio, > > this implements now the complete HTTP chunks syntax as explained in > http://tools.ietf.org/html/rfc2616#section-3.6.1. We were missing some > important points like the additional HTTP headers (= trailer) or the > chunk parameters. > > I have tested it with the Jolie website and it definitely works. > > Now we should be one step further to the UTF-8 parsing of header > components, but I will retry keeping the scanner as it is (non UTF-8) > otherwise, when introducing the InputStreamReader, this gets messed up > and I did not manage to find a fix since the reader intercepts the stream. > > Cheers, > Matthias > > Matthias Dieter Wallnöfer schrieb: > > As far as I see in the code we are *only* using it for header parsing, > > since the content parsing is handled directly with a low-level > > InputStream.read(). > > > > Matthias > > > > Fabrizio Montesi schrieb: > >> Hi Matthias, > >> > >> Just a quick check up question: are you sure that this will not affect > >> content containing \r without \n (which can happen AFAIK)? I guess not, > >> right, as we do not use the Scanner for the content parsing. > >> > >> - Fabrizio > >> > >> ---------- Forwarded message ---------- > >> From: *Repository Jolie code* <no...@co... > >> <mailto:no...@co...>> > >> Date: Sat, Mar 14, 2015 at 7:15 PM > >> Subject: [jolie:code] [r3303] - mwallnoefer2: http parsing - some small > >> code improvements which I separately commit before the UTF-8 parsing > >> To: Repository Jolie code <no...@co... > >> <mailto:no...@co...>> > >> > >> > >> http parsing - some small code improvements which I separately commit > >> before the UTF-8 parsing http://sourceforge.net/p/jolie/code/3303/ > >> <http://sourceforge.net/p/jolie/code/3303> > >> > >> ------------------------------------------------------------------------ > >> > >> Sent from sourceforge.net <http://sourceforge.net> because you > indicated > >> interest in https://sourceforge.net/p/jolie/code/ > >> <https://sourceforge.net/p/jolie/code> > >> > >> To unsubscribe from further messages, please visit > >> https://sourceforge.net/auth/subscriptions/ > >> <https://sourceforge.net/auth/subscriptions> > >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> 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 > > > > |
From: Matthias D. W. <mat...@ya...> - 2015-03-14 19:44:52
|
Fabrizio, this implements now the complete HTTP chunks syntax as explained in http://tools.ietf.org/html/rfc2616#section-3.6.1. We were missing some important points like the additional HTTP headers (= trailer) or the chunk parameters. I have tested it with the Jolie website and it definitely works. Now we should be one step further to the UTF-8 parsing of header components, but I will retry keeping the scanner as it is (non UTF-8) otherwise, when introducing the InputStreamReader, this gets messed up and I did not manage to find a fix since the reader intercepts the stream. Cheers, Matthias Matthias Dieter Wallnöfer schrieb: > As far as I see in the code we are *only* using it for header parsing, > since the content parsing is handled directly with a low-level > InputStream.read(). > > Matthias > > Fabrizio Montesi schrieb: >> Hi Matthias, >> >> Just a quick check up question: are you sure that this will not affect >> content containing \r without \n (which can happen AFAIK)? I guess not, >> right, as we do not use the Scanner for the content parsing. >> >> - Fabrizio >> >> ---------- Forwarded message ---------- >> From: *Repository Jolie code* <no...@co... >> <mailto:no...@co...>> >> Date: Sat, Mar 14, 2015 at 7:15 PM >> Subject: [jolie:code] [r3303] - mwallnoefer2: http parsing - some small >> code improvements which I separately commit before the UTF-8 parsing >> To: Repository Jolie code <no...@co... >> <mailto:no...@co...>> >> >> >> http parsing - some small code improvements which I separately commit >> before the UTF-8 parsing http://sourceforge.net/p/jolie/code/3303/ >> <http://sourceforge.net/p/jolie/code/3303> >> >> ------------------------------------------------------------------------ >> >> Sent from sourceforge.net <http://sourceforge.net> because you indicated >> interest in https://sourceforge.net/p/jolie/code/ >> <https://sourceforge.net/p/jolie/code> >> >> To unsubscribe from further messages, please visit >> https://sourceforge.net/auth/subscriptions/ >> <https://sourceforge.net/auth/subscriptions> >> >> >> >> >> ------------------------------------------------------------------------------ >> 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 > |
From: Claudio G. <cg...@it...> - 2015-03-14 19:33:47
|
I like the idea to have "," because it reminds me json objects even if there are no ":". The semicolon is an operator for composing processes and it is already a confusing operator because a lot of programmers think it is an end line limitator like in Java. Thus I suggest to leave semicolon with only one semantic. It is true that also protocol definition should be addressed with inline tree but I will kill you if you release a jolie version that is not compatible with old jolie files.:) The suggestion could be to add a custom production of inline tree for protocols where both , and ; are accepted. We could write on the docs that semicolons are deprecated and then in the future we could remove them. Il 14/mar/2015 17:56 "Saverio Giallorenzo" <sav...@gm...> ha scritto: > I imagine case 1) as a representations of a static tree-like structure. > The order it is "unfolded" when created does not change the final output. > An example of it are XML structures (but not JSON, in JS you can write "var > myJSON = { "a": i++, "b": i++, "c": i++ }", but JS is evil!). > > Right now the ITC is not a declaration but a procedure of creation of the > structure. That is why IMHO ITC is a constrained version of 2) > where we only support sequential composition of assignments, with the > difference that instead of writing the composition with ";" we write ",". > > Plus, since we already allow assignments to accept aliases and variables > in ITCs I do not see any easy application of static checks on this kind of > structures. > E.g., think of a variable used in the creation of the tree but also used > by one or more parallel threads (globals, parallel composition, etc.). We > cannot say anything > on the content of that tree (damn, dynamic typing :P). > > Are we sure we want to avoid option 2)? > > P.S. I realised only now that the name I used previously is ICT but the > acronym is Inline Tree Creation, my bad. > > > On 14 March 2015 at 12:53, Fabrizio Montesi <fam...@gm...> wrote: > >> I see ict as different than with, in that with is just a preprocessing >> construct, whereas ict is an expression (and hence has a runtime >> semantics). >> >> I'm scared by having ict too general, it would probably make any static >> analysis more complicated because we may have lots of side effects in an >> ict. With, instead, is completely transparent because it is just a >> preprocessor instruction so only the parser sees it. >> >> The current ict is neither option 1 or 2. >> >> You can assign generic expressions to subnodes so the order matters: >> >> x << { .x = i++, .y = i++ } >> >> I think in general we should allow also for nested deep copies and, very >> important for writing efficient code, aliases: .x -> z >> >> Ideally ict will become powerful enough that we can use it for the >> implementation of the protocol configuration block in communication ports >> (which are now implemented as a with instead, IIRC). >> >> However that will cause problems because we're using the ; there as a >> separator, so bye bye backward compatibility. >> >> My reasoning for not using ; as a separator for ict is that it may look >> like somebody can write in there a generic code block, but that's not true. >> >> Not using any separator as in types may be the best solution, but it just >> looks weird in code imho... :-/ >> >> Or, maybe you guys can convince me of using ; ;-) >> >> This is very soft ground, so please continue sharing your thoughts. Once >> the syntax is out for the first release of Jolie 1.2 I'd like it to be >> stable. >> >> Sent from my phone. >> On Mar 14, 2015 9:50 AM, "Saverio Giallorenzo" < >> sav...@gm...> wrote: >> >>> I see your point. I think it depends on which kind of construct we want >>> the inline tree creation (ICT) to be. I see two options: >>> >>> 1) ICT is used only to assign constant values. In this case it does not >>> matter the order in which the assignments are computed as they are >>> independent. That is the case to use commas "," or even nothing, like the >>> syntax of types. >>> >>> 2) ICT is "with" on steroids. The result of its evaluation returns a >>> tree but its body is a Jolie procedure, hence it can contain ";", "|" and >>> input choices to compose statements in which ".any.path" is interpreted and >>> evaluated in a similar way as "with". In that case we could have something >>> like: >>> >>> animals << { >>> .pet[ 0 ].name = "cat"; >>> getAnimal@PetShop()( .pet[ 1 ].name ); >>> { >>> .wild[ i++ ].name = "tiger" | >>> .wild[ i++ ].name = "lion" >>> } // super-dangerous non-deterministic block :) >>> } >>> >>> >>> Personally, I find the second option intriguing, but I do not have a >>> precise idea of the possibile havocs it might lead to (maybe none). >>> >>> What do you think about it? >>> >>> On 14 March 2015 at 09:17, Matthias Dieter Wallnöfer < >>> mwa...@ya...> wrote: >>> >>>> We could also try to imitate "with", which requires the semicolons, but >>>> its block content is also not limited to assignments. >>>> >>>> > with ( animals ){ >>>> > .pet[ 0 ].name = "cat"; >>>> > .pet[ 1 ].name = "dog"; >>>> > println@Console(.pet[0].name)(); >>>> > .wild[ 0 ].name = "tiger"; >>>> > .wild[ 1 ].name = "lion" >>>> > } >>>> >>>> Saverio Giallorenzo schrieb: >>>> > If I may toss an idea, what about making the syntax of inline trees as >>>> > close al possible to that of type declaration? >>>> > >>>> > E.g., we have type >>>> > >>>> > type myType: string { >>>> > .x[ 1, * ]: int >>>> > .y[ 1, 3 ]: void { >>>> > .value*: double >>>> > .comment: string >>>> > } >>>> > } >>>> > >>>> > and we write >>>> > >>>> > myTree << "Root" { >>>> > .x[0]=1 >>>> > .x[1]=2 >>>> > .y << { >>>> > .value[0]=1.1 >>>> > .value[1]=2.1 >>>> > .value[2]=3.1 >>>> > .comment = "This is a comment" >>>> > } >>>> > } >>>> > >>>> > Granted a comma does not make such a big difference, as an user I >>>> would >>>> > wander why one syntax needs the comma and the other does not. >>>> > >>>> > BTW, should the deep-copy operator work inside inline trees or shall >>>> we >>>> > allow only assignments? >>>> > >>>> > Best, >>>> > sg >>>> > >>>> > >>>> > On 12 March 2015 at 10:10, Matthias Dieter Wallnöfer >>>> > <mwa...@ya... <mailto:mwa...@ya...>> wrote: >>>> > >>>> > ";" is more about sequential execution for us, "," is our >>>> delimiter >>>> > (consider also "for") so I would stuck with ",". >>>> > >>>> > Matthias >>>> > >>>> > >>>> > Fabrizio Montesi <fam...@gm... <mailto: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... <mailto: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... >>>> > <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... >>>> > <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 > > |
From: Fabrizio M. <fam...@gm...> - 2015-03-14 19:10:49
|
On Sat, Mar 14, 2015 at 8:04 PM, Claudio Guidi <cg...@it...> wrote: > I like the idea to have "," because it reminds me json objects even if > there are no ":". The semicolon is an operator for composing processes and > it is already a confusing operator because a lot of programmers think it is > an end line limitator like in Java. Thus I suggest to leave semicolon with > only one semantic. > > It is true that also protocol definition should be addressed with inline > tree but I will kill you if you release a jolie version that is not > compatible with old jolie files.:) > Good thing, geographical distances! ;-) Anyway, that will happen sooner or later, but I would like it to happen further on in the future and for something more important than this. And when it will happen, it will be a Jolie 2.0, not a Jolie 1.X. > The suggestion could be to add a custom production of inline tree for > protocols where both , and ; are accepted. We could write on the docs that > semicolons are deprecated and then in the future we could remove them. > Good idea, I like it. If somebody else wants to step up to do this, feel free. I will not consider this a requirements for Jolie 1.2. If it happens, good, otherwise, we can postpone it for Jolie 1.x where x > 2. Cheers, Fabrizio |
From: Matthias D. W. <mat...@ya...> - 2015-03-14 18:44:34
|
As far as I see in the code we are *only* using it for header parsing, since the content parsing is handled directly with a low-level InputStream.read(). Matthias Fabrizio Montesi schrieb: > Hi Matthias, > > Just a quick check up question: are you sure that this will not affect > content containing \r without \n (which can happen AFAIK)? I guess not, > right, as we do not use the Scanner for the content parsing. > > - Fabrizio > > ---------- Forwarded message ---------- > From: *Repository Jolie code* <no...@co... > <mailto:no...@co...>> > Date: Sat, Mar 14, 2015 at 7:15 PM > Subject: [jolie:code] [r3303] - mwallnoefer2: http parsing - some small > code improvements which I separately commit before the UTF-8 parsing > To: Repository Jolie code <no...@co... > <mailto:no...@co...>> > > > http parsing - some small code improvements which I separately commit > before the UTF-8 parsing http://sourceforge.net/p/jolie/code/3303/ > <http://sourceforge.net/p/jolie/code/3303> > > ------------------------------------------------------------------------ > > Sent from sourceforge.net <http://sourceforge.net> because you indicated > interest in https://sourceforge.net/p/jolie/code/ > <https://sourceforge.net/p/jolie/code> > > To unsubscribe from further messages, please visit > https://sourceforge.net/auth/subscriptions/ > <https://sourceforge.net/auth/subscriptions> > > > > > ------------------------------------------------------------------------------ > 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 > |
From: Fabrizio M. <fam...@gm...> - 2015-03-14 18:20:50
|
Hi Matthias, Just a quick check up question: are you sure that this will not affect content containing \r without \n (which can happen AFAIK)? I guess not, right, as we do not use the Scanner for the content parsing. - Fabrizio ---------- Forwarded message ---------- From: Repository Jolie code <no...@co...> Date: Sat, Mar 14, 2015 at 7:15 PM Subject: [jolie:code] [r3303] - mwallnoefer2: http parsing - some small code improvements which I separately commit before the UTF-8 parsing To: Repository Jolie code <no...@co...> http parsing - some small code improvements which I separately commit before the UTF-8 parsing http://sourceforge.net/p/jolie/code/3303/ ------------------------------ Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jolie/code/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ |
From: Fabrizio M. <fam...@gm...> - 2015-03-14 17:01:35
|
On Sat, Mar 14, 2015 at 5:55 PM, Saverio Giallorenzo < sav...@gm...> wrote: > I imagine case 1) as a representations of a static tree-like structure. > The order it is "unfolded" when created does not change the final output. > An example of it are XML structures (but not JSON, in JS you can write "var > myJSON = { "a": i++, "b": i++, "c": i++ }", but JS is evil!). > > Right now the ITC is not a declaration but a procedure of creation of the > structure. That is why IMHO ITC is a constrained version of 2) > where we only support sequential composition of assignments, with the > difference that instead of writing the composition with ";" we write ",". > Yup. Plus, since we already allow assignments to accept aliases and variables in > ITCs I do not see any easy application of static checks on this kind of > structures. > E.g., think of a variable used in the creation of the tree but also used > by one or more parallel threads (globals, parallel composition, etc.). We > cannot say anything > on the content of that tree (damn, dynamic typing :P). > Right. I should've been more specific. I wasn't referring to statically checking variables, but communications. Right now the structure of communications is very clear from the syntax, because communications are always statements and cannot be the side-effect of anything. If we allow comms inside of ITC then we suddenly have that any expression can cause communications as side effects, which is a *big* change I'm very scared of. Imagine: send@OP( { send@OP( y )( .x ) } )( z ) Are we sure we want to avoid option 2)? > I don't see why we would keep with then, or why we would have this new option at all? Cheers, Fabrizio |
From: Saverio G. <sav...@gm...> - 2015-03-14 16:56:03
|
I imagine case 1) as a representations of a static tree-like structure. The order it is "unfolded" when created does not change the final output. An example of it are XML structures (but not JSON, in JS you can write "var myJSON = { "a": i++, "b": i++, "c": i++ }", but JS is evil!). Right now the ITC is not a declaration but a procedure of creation of the structure. That is why IMHO ITC is a constrained version of 2) where we only support sequential composition of assignments, with the difference that instead of writing the composition with ";" we write ",". Plus, since we already allow assignments to accept aliases and variables in ITCs I do not see any easy application of static checks on this kind of structures. E.g., think of a variable used in the creation of the tree but also used by one or more parallel threads (globals, parallel composition, etc.). We cannot say anything on the content of that tree (damn, dynamic typing :P). Are we sure we want to avoid option 2)? P.S. I realised only now that the name I used previously is ICT but the acronym is Inline Tree Creation, my bad. On 14 March 2015 at 12:53, Fabrizio Montesi <fam...@gm...> wrote: > I see ict as different than with, in that with is just a preprocessing > construct, whereas ict is an expression (and hence has a runtime > semantics). > > I'm scared by having ict too general, it would probably make any static > analysis more complicated because we may have lots of side effects in an > ict. With, instead, is completely transparent because it is just a > preprocessor instruction so only the parser sees it. > > The current ict is neither option 1 or 2. > > You can assign generic expressions to subnodes so the order matters: > > x << { .x = i++, .y = i++ } > > I think in general we should allow also for nested deep copies and, very > important for writing efficient code, aliases: .x -> z > > Ideally ict will become powerful enough that we can use it for the > implementation of the protocol configuration block in communication ports > (which are now implemented as a with instead, IIRC). > > However that will cause problems because we're using the ; there as a > separator, so bye bye backward compatibility. > > My reasoning for not using ; as a separator for ict is that it may look > like somebody can write in there a generic code block, but that's not true. > > Not using any separator as in types may be the best solution, but it just > looks weird in code imho... :-/ > > Or, maybe you guys can convince me of using ; ;-) > > This is very soft ground, so please continue sharing your thoughts. Once > the syntax is out for the first release of Jolie 1.2 I'd like it to be > stable. > > Sent from my phone. > On Mar 14, 2015 9:50 AM, "Saverio Giallorenzo" < > sav...@gm...> wrote: > >> I see your point. I think it depends on which kind of construct we want >> the inline tree creation (ICT) to be. I see two options: >> >> 1) ICT is used only to assign constant values. In this case it does not >> matter the order in which the assignments are computed as they are >> independent. That is the case to use commas "," or even nothing, like the >> syntax of types. >> >> 2) ICT is "with" on steroids. The result of its evaluation returns a tree >> but its body is a Jolie procedure, hence it can contain ";", "|" and input >> choices to compose statements in which ".any.path" is interpreted and >> evaluated in a similar way as "with". In that case we could have something >> like: >> >> animals << { >> .pet[ 0 ].name = "cat"; >> getAnimal@PetShop()( .pet[ 1 ].name ); >> { >> .wild[ i++ ].name = "tiger" | >> .wild[ i++ ].name = "lion" >> } // super-dangerous non-deterministic block :) >> } >> >> >> Personally, I find the second option intriguing, but I do not have a >> precise idea of the possibile havocs it might lead to (maybe none). >> >> What do you think about it? >> >> On 14 March 2015 at 09:17, Matthias Dieter Wallnöfer < >> mwa...@ya...> wrote: >> >>> We could also try to imitate "with", which requires the semicolons, but >>> its block content is also not limited to assignments. >>> >>> > with ( animals ){ >>> > .pet[ 0 ].name = "cat"; >>> > .pet[ 1 ].name = "dog"; >>> > println@Console(.pet[0].name)(); >>> > .wild[ 0 ].name = "tiger"; >>> > .wild[ 1 ].name = "lion" >>> > } >>> >>> Saverio Giallorenzo schrieb: >>> > If I may toss an idea, what about making the syntax of inline trees as >>> > close al possible to that of type declaration? >>> > >>> > E.g., we have type >>> > >>> > type myType: string { >>> > .x[ 1, * ]: int >>> > .y[ 1, 3 ]: void { >>> > .value*: double >>> > .comment: string >>> > } >>> > } >>> > >>> > and we write >>> > >>> > myTree << "Root" { >>> > .x[0]=1 >>> > .x[1]=2 >>> > .y << { >>> > .value[0]=1.1 >>> > .value[1]=2.1 >>> > .value[2]=3.1 >>> > .comment = "This is a comment" >>> > } >>> > } >>> > >>> > Granted a comma does not make such a big difference, as an user I would >>> > wander why one syntax needs the comma and the other does not. >>> > >>> > BTW, should the deep-copy operator work inside inline trees or shall we >>> > allow only assignments? >>> > >>> > Best, >>> > sg >>> > >>> > >>> > On 12 March 2015 at 10:10, Matthias Dieter Wallnöfer >>> > <mwa...@ya... <mailto:mwa...@ya...>> wrote: >>> > >>> > ";" is more about sequential execution for us, "," is our delimiter >>> > (consider also "for") so I would stuck with ",". >>> > >>> > Matthias >>> > >>> > >>> > Fabrizio Montesi <fam...@gm... <mailto: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... <mailto: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... >>> > <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... >>> > <mailto:Jol...@li...> >>> > https://lists.sourceforge.net/lists/listinfo/jolie-devel >>> > >>> > >>> >>> >> |
From: Matthias D. W. <mat...@ya...> - 2015-03-14 14:11:31
|
Ah, I was not aware of this possibility since with just including "database.iol" you are limited to one instance...would be good to have an example though. Matthias Fabrizio Montesi schrieb: > Hi Matthias, > > Why "only one instance per program" ? One could embed Database again > with a different output port (although it's longer than a simple include > "database.iol") > > Cheers, > F > > > ---------- Forwarded message ---------- > From: *Repository Jolie code* <no...@co... > <mailto:no...@co...>> > Date: Sat, Mar 14, 2015 at 1:10 PM > Subject: [jolie:code] [r3301] - mwallnoefer2: first part of DB docs > To: Repository Jolie code <no...@co... > <mailto:no...@co...>> > > > first part of DB docs http://sourceforge.net/p/jolie/code/3301/ > <http://sourceforge.net/p/jolie/code/3301> > > ------------------------------------------------------------------------ > > Sent from sourceforge.net <http://sourceforge.net> because you indicated > interest in https://sourceforge.net/p/jolie/code/ > <https://sourceforge.net/p/jolie/code> > > To unsubscribe from further messages, please visit > https://sourceforge.net/auth/subscriptions/ > <https://sourceforge.net/auth/subscriptions> > > > > > ------------------------------------------------------------------------------ > 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 > |
From: Fabrizio M. <fam...@gm...> - 2015-03-14 13:49:19
|
Hi Matthias, Why "only one instance per program" ? One could embed Database again with a different output port (although it's longer than a simple include "database.iol") Cheers, F ---------- Forwarded message ---------- From: Repository Jolie code <no...@co...> Date: Sat, Mar 14, 2015 at 1:10 PM Subject: [jolie:code] [r3301] - mwallnoefer2: first part of DB docs To: Repository Jolie code <no...@co...> first part of DB docs http://sourceforge.net/p/jolie/code/3301/ ------------------------------ Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jolie/code/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ |
From: Fabrizio M. <fam...@gm...> - 2015-03-14 11:54:05
|
I see ict as different than with, in that with is just a preprocessing construct, whereas ict is an expression (and hence has a runtime semantics). I'm scared by having ict too general, it would probably make any static analysis more complicated because we may have lots of side effects in an ict. With, instead, is completely transparent because it is just a preprocessor instruction so only the parser sees it. The current ict is neither option 1 or 2. You can assign generic expressions to subnodes so the order matters: x << { .x = i++, .y = i++ } I think in general we should allow also for nested deep copies and, very important for writing efficient code, aliases: .x -> z Ideally ict will become powerful enough that we can use it for the implementation of the protocol configuration block in communication ports (which are now implemented as a with instead, IIRC). However that will cause problems because we're using the ; there as a separator, so bye bye backward compatibility. My reasoning for not using ; as a separator for ict is that it may look like somebody can write in there a generic code block, but that's not true. Not using any separator as in types may be the best solution, but it just looks weird in code imho... :-/ Or, maybe you guys can convince me of using ; ;-) This is very soft ground, so please continue sharing your thoughts. Once the syntax is out for the first release of Jolie 1.2 I'd like it to be stable. Sent from my phone. On Mar 14, 2015 9:50 AM, "Saverio Giallorenzo" < sav...@gm...> wrote: > I see your point. I think it depends on which kind of construct we want > the inline tree creation (ICT) to be. I see two options: > > 1) ICT is used only to assign constant values. In this case it does not > matter the order in which the assignments are computed as they are > independent. That is the case to use commas "," or even nothing, like the > syntax of types. > > 2) ICT is "with" on steroids. The result of its evaluation returns a tree > but its body is a Jolie procedure, hence it can contain ";", "|" and input > choices to compose statements in which ".any.path" is interpreted and > evaluated in a similar way as "with". In that case we could have something > like: > > animals << { > .pet[ 0 ].name = "cat"; > getAnimal@PetShop()( .pet[ 1 ].name ); > { > .wild[ i++ ].name = "tiger" | > .wild[ i++ ].name = "lion" > } // super-dangerous non-deterministic block :) > } > > > Personally, I find the second option intriguing, but I do not have a > precise idea of the possibile havocs it might lead to (maybe none). > > What do you think about it? > > On 14 March 2015 at 09:17, Matthias Dieter Wallnöfer <mwa...@ya... > > wrote: > >> We could also try to imitate "with", which requires the semicolons, but >> its block content is also not limited to assignments. >> >> > with ( animals ){ >> > .pet[ 0 ].name = "cat"; >> > .pet[ 1 ].name = "dog"; >> > println@Console(.pet[0].name)(); >> > .wild[ 0 ].name = "tiger"; >> > .wild[ 1 ].name = "lion" >> > } >> >> Saverio Giallorenzo schrieb: >> > If I may toss an idea, what about making the syntax of inline trees as >> > close al possible to that of type declaration? >> > >> > E.g., we have type >> > >> > type myType: string { >> > .x[ 1, * ]: int >> > .y[ 1, 3 ]: void { >> > .value*: double >> > .comment: string >> > } >> > } >> > >> > and we write >> > >> > myTree << "Root" { >> > .x[0]=1 >> > .x[1]=2 >> > .y << { >> > .value[0]=1.1 >> > .value[1]=2.1 >> > .value[2]=3.1 >> > .comment = "This is a comment" >> > } >> > } >> > >> > Granted a comma does not make such a big difference, as an user I would >> > wander why one syntax needs the comma and the other does not. >> > >> > BTW, should the deep-copy operator work inside inline trees or shall we >> > allow only assignments? >> > >> > Best, >> > sg >> > >> > >> > On 12 March 2015 at 10:10, Matthias Dieter Wallnöfer >> > <mwa...@ya... <mailto:mwa...@ya...>> wrote: >> > >> > ";" is more about sequential execution for us, "," is our delimiter >> > (consider also "for") so I would stuck with ",". >> > >> > Matthias >> > >> > >> > Fabrizio Montesi <fam...@gm... <mailto: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... <mailto: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... >> > <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... >> > <mailto:Jol...@li...> >> > https://lists.sourceforge.net/lists/listinfo/jolie-devel >> > >> > >> >> > |
From: Saverio G. <sav...@gm...> - 2015-03-14 08:50:08
|
I see your point. I think it depends on which kind of construct we want the inline tree creation (ICT) to be. I see two options: 1) ICT is used only to assign constant values. In this case it does not matter the order in which the assignments are computed as they are independent. That is the case to use commas "," or even nothing, like the syntax of types. 2) ICT is "with" on steroids. The result of its evaluation returns a tree but its body is a Jolie procedure, hence it can contain ";", "|" and input choices to compose statements in which ".any.path" is interpreted and evaluated in a similar way as "with". In that case we could have something like: animals << { .pet[ 0 ].name = "cat"; getAnimal@PetShop()( .pet[ 1 ].name ); { .wild[ i++ ].name = "tiger" | .wild[ i++ ].name = "lion" } // super-dangerous non-deterministic block :) } Personally, I find the second option intriguing, but I do not have a precise idea of the possibile havocs it might lead to (maybe none). What do you think about it? On 14 March 2015 at 09:17, Matthias Dieter Wallnöfer <mwa...@ya...> wrote: > We could also try to imitate "with", which requires the semicolons, but > its block content is also not limited to assignments. > > > with ( animals ){ > > .pet[ 0 ].name = "cat"; > > .pet[ 1 ].name = "dog"; > > println@Console(.pet[0].name)(); > > .wild[ 0 ].name = "tiger"; > > .wild[ 1 ].name = "lion" > > } > > Saverio Giallorenzo schrieb: > > If I may toss an idea, what about making the syntax of inline trees as > > close al possible to that of type declaration? > > > > E.g., we have type > > > > type myType: string { > > .x[ 1, * ]: int > > .y[ 1, 3 ]: void { > > .value*: double > > .comment: string > > } > > } > > > > and we write > > > > myTree << "Root" { > > .x[0]=1 > > .x[1]=2 > > .y << { > > .value[0]=1.1 > > .value[1]=2.1 > > .value[2]=3.1 > > .comment = "This is a comment" > > } > > } > > > > Granted a comma does not make such a big difference, as an user I would > > wander why one syntax needs the comma and the other does not. > > > > BTW, should the deep-copy operator work inside inline trees or shall we > > allow only assignments? > > > > Best, > > sg > > > > > > On 12 March 2015 at 10:10, Matthias Dieter Wallnöfer > > <mwa...@ya... <mailto:mwa...@ya...>> wrote: > > > > ";" is more about sequential execution for us, "," is our delimiter > > (consider also "for") so I would stuck with ",". > > > > Matthias > > > > > > Fabrizio Montesi <fam...@gm... <mailto: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... <mailto: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... > > <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... > > <mailto:Jol...@li...> > > https://lists.sourceforge.net/lists/listinfo/jolie-devel > > > > > > |
From: Matthias D. W. <mwa...@ya...> - 2015-03-14 08:17:48
|
We could also try to imitate "with", which requires the semicolons, but its block content is also not limited to assignments. > with ( animals ){ > .pet[ 0 ].name = "cat"; > .pet[ 1 ].name = "dog"; > println@Console(.pet[0].name)(); > .wild[ 0 ].name = "tiger"; > .wild[ 1 ].name = "lion" > } Saverio Giallorenzo schrieb: > If I may toss an idea, what about making the syntax of inline trees as > close al possible to that of type declaration? > > E.g., we have type > > type myType: string { > .x[ 1, * ]: int > .y[ 1, 3 ]: void { > .value*: double > .comment: string > } > } > > and we write > > myTree << "Root" { > .x[0]=1 > .x[1]=2 > .y << { > .value[0]=1.1 > .value[1]=2.1 > .value[2]=3.1 > .comment = "This is a comment" > } > } > > Granted a comma does not make such a big difference, as an user I would > wander why one syntax needs the comma and the other does not. > > BTW, should the deep-copy operator work inside inline trees or shall we > allow only assignments? > > Best, > sg > > > On 12 March 2015 at 10:10, Matthias Dieter Wallnöfer > <mwa...@ya... <mailto:mwa...@ya...>> wrote: > > ";" is more about sequential execution for us, "," is our delimiter > (consider also "for") so I would stuck with ",". > > Matthias > > > Fabrizio Montesi <fam...@gm... <mailto: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... <mailto: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... > <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... > <mailto:Jol...@li...> > https://lists.sourceforge.net/lists/listinfo/jolie-devel > > |
From: Matthias D. W. <mwa...@ya...> - 2015-03-13 15:13:37
|
I will do a ant clean and a complete rebuild. This should catch every error. Fortunately we are working on Java which is strongly typed, otherwise it would be a nightmare :). Fabrizio Montesi <fam...@gm...> schrieb am 15:49 Freitag, 13.März 2015: Sounds correct, but we need to be careful. Programpath is used in a lot of places, so please open all projects inside of trunk while trying to patch and test the tools that get influenced by the modification. Which suggests that we should also have tests for tools... :-) Sent from my phone. On Mar 13, 2015 3:00 PM, "Matthias Dieter Wallnöfer" <mwa...@ya...> wrote: I have determined the correct fix: we need to convert programPath from String into File and use File.getURI() to create us correct "file:" prefixed URIs (please look at the Java API docs). This approach converts all blanks into "%20"s as required by the URI spec and Balint's problem disappears. > > >Cheers, >Matthias > > > > >Matthias Dieter Wallnöfer <mwa...@ya...> schrieb am 9:06 Freitag, 13.März 2015: >For now just revert commit r3265. The problem is that with this patch we lose our path information. > >Cheers, >Matthias > > > >Matthias Dieter Wallnöfer <mwa...@ya...> schrieb am 8:05 Freitag, 13.März 2015: > > > > >Yeah, this is related to the bugfix done for Balint some weeks ago. It affects the other tools as well. > >Matthias > > >Von Samsung Mobile gesendet > > >-------- Ursprüngliche Nachricht -------- >Von: Fabrizio Montesi >Datum:12.03.2015 18:06 (GMT+01:00) >An: Claudio Guidi >Cc: jol...@li... >Betreff: Re: [Jolie-devel] joliedoc bug > >@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 >> >> > > >------------------------------------------------------------------------------ >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 > |
From: Fabrizio M. <fam...@gm...> - 2015-03-13 14:44:40
|
Sounds correct, but we need to be careful. Programpath is used in a lot of places, so please open all projects inside of trunk while trying to patch and test the tools that get influenced by the modification. Which suggests that we should also have tests for tools... :-) Sent from my phone. On Mar 13, 2015 3:00 PM, "Matthias Dieter Wallnöfer" <mwa...@ya...> wrote: > I have determined the correct fix: we need to convert programPath from > String into File and use File.getURI() to create us correct "file:" > prefixed URIs (please look at the Java API docs). This approach converts > all blanks into "%20"s as required by the URI spec and Balint's problem > disappears. > > > Cheers, > Matthias > > > > > Matthias Dieter Wallnöfer <mwa...@ya...> schrieb am 9:06 Freitag, > 13.März 2015: > For now just revert commit r3265. The problem is that with this patch we > lose our path information. > > Cheers, > Matthias > > > > Matthias Dieter Wallnöfer <mwa...@ya...> schrieb am 8:05 Freitag, > 13.März 2015: > > > > > Yeah, this is related to the bugfix done for Balint some weeks ago. It > affects the other tools as well. > > Matthias > > > Von Samsung Mobile gesendet > > > -------- Ursprüngliche Nachricht -------- > Von: Fabrizio Montesi > Datum:12.03.2015 18:06 (GMT+01:00) > An: Claudio Guidi > Cc: jol...@li... > Betreff: Re: [Jolie-devel] joliedoc bug > > @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 > > > > > > > > ------------------------------------------------------------------------------ > 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 > |
From: Matthias D. W. <mwa...@ya...> - 2015-03-13 14:00:47
|
I have determined the correct fix: we need to convert programPath from String into File and use File.getURI() to create us correct "file:" prefixed URIs (please look at the Java API docs). This approach converts all blanks into "%20"s as required by the URI spec and Balint's problem disappears. Cheers, Matthias Matthias Dieter Wallnöfer <mwa...@ya...> schrieb am 9:06 Freitag, 13.März 2015: For now just revert commit r3265. The problem is that with this patch we lose our path information. Cheers, Matthias Matthias Dieter Wallnöfer <mwa...@ya...> schrieb am 8:05 Freitag, 13.März 2015: Yeah, this is related to the bugfix done for Balint some weeks ago. It affects the other tools as well. Matthias Von Samsung Mobile gesendet -------- Ursprüngliche Nachricht -------- Von: Fabrizio Montesi Datum:12.03.2015 18:06 (GMT+01:00) An: Claudio Guidi Cc: jol...@li... Betreff: Re: [Jolie-devel] joliedoc bug @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 > > ------------------------------------------------------------------------------ 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 |
From: Matthias D. W. <mat...@ya...> - 2015-03-13 10:34:32
|
At the moment I used just System.print.out cmds as you can see in my patch. Fabrizio Montesi <fam...@gm...> schrieb am 11:05 Freitag, 13.März 2015: Cool, how are you seeing the low-level chunks? curl? I'd like to use something that is not Jolie. - F On Fri, Mar 13, 2015 at 11:03 AM, Matthias Dieter Wallnöfer <mat...@ya...> wrote: At the moment I was just testing it with the Jolie website: http://localhost:8000/planet. > >Matthias > >Fabrizio Montesi <fam...@gm...> schrieb am 10:48 Freitag, 13.März 2015: > > >Hi Matthias, > >Maybe it's a good idea to develop the test for it first, as this is a very sensitive area (I remember being very happy the first time it worked :-P). Any ideas on how we could automate, for example, sending and receiving a file in chunks? > >Or, how are you testing chunking right now? > >Ciao, >F > > >On Thu, Mar 12, 2015 at 10:02 PM, Matthias Dieter Wallnöfer <mat...@ya...> wrote: > >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 >>> >> >> > |
From: Fabrizio M. <fam...@gm...> - 2015-03-13 10:05:15
|
Cool, how are you seeing the low-level chunks? curl? I'd like to use something that is not Jolie. - F On Fri, Mar 13, 2015 at 11:03 AM, Matthias Dieter Wallnöfer < mat...@ya...> wrote: > At the moment I was just testing it with the Jolie website: > http://localhost:8000/planet. > > Matthias > > Fabrizio Montesi <fam...@gm...> schrieb am 10:48 Freitag, 13.März > 2015: > > Hi Matthias, > > Maybe it's a good idea to develop the test for it first, as this is a very > sensitive area (I remember being very happy the first time it worked :-P). > Any ideas on how we could automate, for example, sending and receiving a > file in chunks? > > Or, how are you testing chunking right now? > > Ciao, > F > > > On Thu, Mar 12, 2015 at 10:02 PM, Matthias Dieter Wallnöfer < > mat...@ya...> wrote: > > 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 > >> > > > > > |
From: Matthias D. W. <mat...@ya...> - 2015-03-13 10:03:40
|
At the moment I was just testing it with the Jolie website: http://localhost:8000/planet. Matthias Fabrizio Montesi <fam...@gm...> schrieb am 10:48 Freitag, 13.März 2015: Hi Matthias, Maybe it's a good idea to develop the test for it first, as this is a very sensitive area (I remember being very happy the first time it worked :-P). Any ideas on how we could automate, for example, sending and receiving a file in chunks? Or, how are you testing chunking right now? Ciao, F On Thu, Mar 12, 2015 at 10:02 PM, Matthias Dieter Wallnöfer <mat...@ya...> wrote: 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 >> > > |
From: Fabrizio M. <fam...@gm...> - 2015-03-13 09:48:50
|
Hi Matthias, Maybe it's a good idea to develop the test for it first, as this is a very sensitive area (I remember being very happy the first time it worked :-P). Any ideas on how we could automate, for example, sending and receiving a file in chunks? Or, how are you testing chunking right now? Ciao, F On Thu, Mar 12, 2015 at 10:02 PM, Matthias Dieter Wallnöfer < mat...@ya...> wrote: > 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 > > > > |
From: Saverio G. <sav...@gm...> - 2015-03-13 08:35:07
|
If I may toss an idea, what about making the syntax of inline trees as close al possible to that of type declaration? E.g., we have type type myType: string { .x[ 1, * ]: int .y[ 1, 3 ]: void { .value*: double .comment: string } } and we write myTree << "Root" { .x[0]=1 .x[1]=2 .y << { .value[0]=1.1 .value[1]=2.1 .value[2]=3.1 .comment = "This is a comment" } } Granted a comma does not make such a big difference, as an user I would wander why one syntax needs the comma and the other does not. BTW, should the deep-copy operator work inside inline trees or shall we allow only assignments? Best, sg On 12 March 2015 at 10:10, Matthias Dieter Wallnöfer <mwa...@ya...> wrote: > ";" 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 > > > ------------------------------------------------------------------------------ > 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 > |
From: Matthias D. W. <mwa...@ya...> - 2015-03-13 08:06:34
|
For now just revert commit r3265. The problem is that with this patch we lose our path information. Cheers, Matthias Matthias Dieter Wallnöfer <mwa...@ya...> schrieb am 8:05 Freitag, 13.März 2015: Yeah, this is related to the bugfix done for Balint some weeks ago. It affects the other tools as well. Matthias Von Samsung Mobile gesendet -------- Ursprüngliche Nachricht -------- Von: Fabrizio Montesi Datum:12.03.2015 18:06 (GMT+01:00) An: Claudio Guidi Cc: jol...@li... Betreff: Re: [Jolie-devel] joliedoc bug @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 > > ------------------------------------------------------------------------------ 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 |
From: Matthias D. W. <mwa...@ya...> - 2015-03-13 07:05:25
|
Yeah, this is related to the bugfix done for Balint some weeks ago. It affects the other tools as well. Matthias Von Samsung Mobile gesendet <div>-------- Ursprüngliche Nachricht --------</div><div>Von: Fabrizio Montesi <fam...@gm...> </div><div>Datum:12.03.2015 18:06 (GMT+01:00) </div><div>An: Claudio Guidi <cg...@it...> </div><div>Cc: jol...@li... </div><div>Betreff: Re: [Jolie-devel] joliedoc bug </div><div> </div>@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 |