Hi,
John Brant created a repo on SmalltalkHub with the latest version of SmaCC.
And now, SmaCC is part of Moose 6.0.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
Great news !
There was already a Smacc repo on github managed by Thierry: https://github.com/ThierryGoubier/SmaCC
Some cooperation will happens here in order to avoid duplicate work ?
Regards
Envoyé de mon iPhone
Le 12 août 2016 à 21:41, Tudor Girba tudor@tudorgirba.com a écrit :
Hi,
John Brant created a repo on SmalltalkHub with the latest version of SmaCC.
And now, SmaCC is part of Moose 6.0.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
I know about the repo of Thierry and I hope that we will see more collaboration around SmaCC.
Some of the latest changes of John were not available publicly until now, and now he was kind enough to make them available. I hope this will be considered a good thing, and not an issue of competition.
Cheers, Doru
On Aug 12, 2016, at 10:53 PM, serge.stinckwich@gmail.com wrote:
Great news !
There was already a Smacc repo on github managed by Thierry: https://github.com/ThierryGoubier/SmaCC
Some cooperation will happens here in order to avoid duplicate work ?
Regards
Envoyé de mon iPhone
Le 12 août 2016 à 21:41, Tudor Girba tudor@tudorgirba.com a écrit :
Hi,
John Brant created a repo on SmalltalkHub with the latest version of SmaCC.
And now, SmaCC is part of Moose 6.0.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Not knowing how to do something is not an argument for how it cannot be done."
On Fri, Aug 12, 2016 at 10:57 PM, Tudor Girba tudor@tudorgirba.com wrote:
I know about the repo of Thierry and I hope that we will see more collaboration around SmaCC.
I hope so also.
Some of the latest changes of John were not available publicly until now, and now he was kind enough to make them available. I hope this will be considered a good thing, and not an issue of competition.
Thierry add some modifications like the parser generator browser.
Maybe this is nice to share the same issue tracker : https://github.com/ThierryGoubier/SmaCC/issues
Thanks Doru.
Just wondering, I always had in mind that PetitParser is a kind of ultimate framework for parsing. Why would one want to use SmaCC if PetitParser is so robust and popular?
Cheers, Alexandre
On Aug 12, 2016, at 3:41 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
John Brant created a repo on SmalltalkHub with the latest version of SmaCC.
And now, SmaCC is part of Moose 6.0.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi,
PetitParser is a dynamic parser. SmaCC is a static parser. Both have their usages, and the static parsers are significantly faster. The speed problem of PetitParser will likely be significantly improved once we get the work of Jan on compiling parsers.
One thing that SmaCC comes with is an extensive library of parsers and ASTs (e.g., JavaScript, Java, Swift) and this is very valuable in the context of Moose.
Cheers, Doru
On Aug 14, 2016, at 10:04 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Thanks Doru.
Just wondering, I always had in mind that PetitParser is a kind of ultimate framework for parsing. Why would one want to use SmaCC if PetitParser is so robust and popular?
Cheers, Alexandre
On Aug 12, 2016, at 3:41 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
John Brant created a repo on SmalltalkHub with the latest version of SmaCC.
And now, SmaCC is part of Moose 6.0.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
+1
When you have a antrl grammar, smacc is really nice.
Stef
Le 14/8/16 à 22:31, Tudor Girba a écrit :
Hi,
PetitParser is a dynamic parser. SmaCC is a static parser. Both have their usages, and the static parsers are significantly faster. The speed problem of PetitParser will likely be significantly improved once we get the work of Jan on compiling parsers.
One thing that SmaCC comes with is an extensive library of parsers and ASTs (e.g., JavaScript, Java, Swift) and this is very valuable in the context of Moose.
Cheers, Doru
On Aug 14, 2016, at 10:04 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Thanks Doru.
Just wondering, I always had in mind that PetitParser is a kind of ultimate framework for parsing. Why would one want to use SmaCC if PetitParser is so robust and popular?
Cheers, Alexandre
On Aug 12, 2016, at 3:41 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
John Brant created a repo on SmalltalkHub with the latest version of SmaCC.
And now, SmaCC is part of Moose 6.0.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
I did not read this before, but now I’m interested.
Dory, when you say that 'the static parsers are significantly faster’ can you give some numbers on that? And you know what the numbers are compared to the compiled petitparsers of Jan and Jan ? (Their compiler is really cool BTW :-) I use it for LRP )
-- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Aug 19, 2016, at 07:02, stepharo stepharo@free.fr wrote:
Le 14/8/16 à 22:31, Tudor Girba a écrit :
Hi,
PetitParser is a dynamic parser. SmaCC is a static parser. Both have their usages, and the static parsers are significantly faster. The speed problem of PetitParser will likely be significantly improved once we get the work of Jan on compiling parsers.
On the Smalltalk grammar, SmaCC is two times faster than PetitParser and Compiled PetitParser is four times faster. RBParser is like four point one times faster.
The SmaCC parsers are table driven, unless you rewrite SmaCC to produce top-down parsers, it will not reach the performance of RBParser or the parser compiled by PetitParser Compiler.
Cheers Jan
On Fri, Aug 19, 2016, 14:50 Johan Fabry jfabry@dcc.uchile.cl wrote:
I did not read this before, but now I’m interested.
Dory, when you say that 'the static parsers are significantly faster’ can you give some numbers on that? And you know what the numbers are compared to the compiled petitparsers of Jan and Jan ? (Their compiler is really cool BTW :-) I use it for LRP )
-- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Aug 19, 2016, at 07:02, stepharo stepharo@free.fr wrote:
Le 14/8/16 à 22:31, Tudor Girba a écrit :
Hi,
PetitParser is a dynamic parser. SmaCC is a static parser. Both have
their usages, and the static parsers are significantly faster. The speed problem of PetitParser will likely be significantly improved once we get the work of Jan on compiling parsers.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi Jan,
Le 20/08/2016 à 15:36, Jan Kurš a écrit :
On the Smalltalk grammar, SmaCC is two times faster than PetitParser and Compiled PetitParser is four times faster. RBParser is like four point one times faster.
Impressive results.
Are you also changing the O() characteristics of the PetitParser-based parsers (i.e. that tendency to have performance/memory behavior based on the input length and not on the tree depth) ?
The SmaCC parsers are table driven, unless you rewrite SmaCC to produce top-down parsers, it will not reach the performance of RBParser or the parser compiled by PetitParser Compiler.
No. What you have to do with SmaCC is generate(*) a recursive ascent parser[1] instead of a table-driven parser.
Regards,
Thierry
[1] https://en.wikipedia.org/wiki/Recursive_ascent_parser (*) This is an exercice left to the reader :)
Cheers Jan
On Fri, Aug 19, 2016, 14:50 Johan Fabry <jfabry@dcc.uchile.cl mailto:jfabry@dcc.uchile.cl> wrote:
I did not read this before, but now I’m interested. Dory, when you say that 'the static parsers are significantly faster’ can you give some numbers on that? And you know what the numbers are compared to the compiled petitparsers of Jan and Jan ? (Their compiler is really cool BTW :-) I use it for LRP ) -- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Aug 19, 2016, at 07:02, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote: > > Le 14/8/16 à 22:31, Tudor Girba a écrit : >> Hi, >> >> PetitParser is a dynamic parser. SmaCC is a static parser. Both have their usages, and the static parsers are significantly faster. The speed problem of PetitParser will likely be significantly improved once we get the work of Jan on compiling parsers. _______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch> https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Thanks for the numbers, Jan. And they are excellent numbers as well! :-) Congrats on the compiler, it is simply great !
-- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org http://emailcharter.org/ .
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Aug 20, 2016, at 10:36, Jan Kurš kurs.jan@gmail.com wrote:
On the Smalltalk grammar, SmaCC is two times faster than PetitParser and Compiled PetitParser is four times faster. RBParser is like four point one times faster.
The SmaCC parsers are table driven, unless you rewrite SmaCC to produce top-down parsers, it will not reach the performance of RBParser or the parser compiled by PetitParser Compiler.
Cheers Jan
I added some details to the webpage for those, who are interested: http://scg.unibe.ch/research/petitcompiler
@Thierry: Thanks! I am not changing any complexity characteristics. The speedup is gained by analyzing a grammar and optimizing some parts. E.g. replacing combinators with a while loop, or using the first-set to choose the correct branch without backtracking (if possible).
On Sat, Aug 20, 2016 at 5:12 PM Johan Fabry jfabry@dcc.uchile.cl wrote:
Thanks for the numbers, Jan. And they are excellent numbers as well! :-) Congrats on the compiler, it is simply great !
-- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Aug 20, 2016, at 10:36, Jan Kurš kurs.jan@gmail.com wrote:
On the Smalltalk grammar, SmaCC is two times faster than PetitParser and Compiled PetitParser is four times faster. RBParser is like four point one times faster.
The SmaCC parsers are table driven, unless you rewrite SmaCC to produce top-down parsers, it will not reach the performance of RBParser or the parser compiled by PetitParser Compiler.
Cheers Jan
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi Jan,
Le 21/08/2016 à 12:13, Jan Kurš a écrit :
I added some details to the webpage for those, who are interested: http://scg.unibe.ch/research/petitcompiler
Thanks.
@Thierry: Thanks! I am not changing any complexity characteristics. The speedup is gained by analyzing a grammar and optimizing some parts. E.g. replacing combinators with a while loop, or using the first-set to choose the correct branch without backtracking (if possible).
This one (avoiding backtracking) does change the complexity in a good way (reduces it). A nice optimisation.
Thierry
On Sat, Aug 20, 2016 at 5:12 PM Johan Fabry <jfabry@dcc.uchile.cl mailto:jfabry@dcc.uchile.cl> wrote:
Thanks for the numbers, Jan. And they are excellent numbers as well! :-) Congrats on the compiler, it is simply great ! -- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On Aug 20, 2016, at 10:36, Jan Kurš <kurs.jan@gmail.com <mailto:kurs.jan@gmail.com>> wrote: On the Smalltalk grammar, SmaCC is two times faster than PetitParser and Compiled PetitParser is four times faster. RBParser is like four point one times faster. The SmaCC parsers are table driven, unless you rewrite SmaCC to produce top-down parsers, it will not reach the performance of RBParser or the parser compiled by PetitParser Compiler. Cheers Jan
_______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch> https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev