Re: Marpa Parser generator is awesome... yet is there a sources in C++ Java C#...?

[Durand Jean-Damien]

About other parser generators using marpa algorithm, there are bindings to 
other languages that probably have their own BNF.
There is also c-marpaESLIF  that 
implements its own BNF directly in a C library, very similar the perl's 
Marpa BNF, though not 100% compatible. The only real advantages of the 
later are its stream-ready compatible architecture, native support of 
regular expressions via an embedded version of PCRE2 
, native action scripting 
language via an emdedded Lua  interpreter.

Le dimanche 13 octobre 2019 11:28:26 UTC+2, paul.senato...@gmail.com a 
écrit :
>
> Marpa Parser generator is awesome... but it's too uncomfortable to use it 
> from PLs ala C++ Java C# . 
>
> Is there some Marpa like parser generator for C++ Java C#...?
> Is there other parser generators using ~ Marpa algorithm?
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/marpa-parser/a23fcd2a-6770-40cd-af66-cebe42186977%40googlegroups.com.

Re: Marpa Parser generator is awesome... yet is there a sources in C++ Java C#...?

[Durand Jean-Damien]

Hello,

Internally, Marpa perl packages uses the low-level libmarpa 
, which can be directly accessed 
through C++.

There is also marpaWrapper  
that is a very thin layer on top of libmarpa, more event and callback 
oriented than  native version.

Regards, Jean-Damien.

Le dimanche 13 octobre 2019 11:28:26 UTC+2, paul.senato...@gmail.com a 
écrit :
>
> Marpa Parser generator is awesome... but it's too uncomfortable to use it 
> from PLs ala C++ Java C# . 
>
> Is there some Marpa like parser generator for C++ Java C#...?
> Is there other parser generators using ~ Marpa algorithm?
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/marpa-parser/debe6753-ef9c-4466-8c62-59ad10c1fd50%40googlegroups.com.

Re: Finding where a rule matches input stream

[Durand Jean-Damien]

Your CodeProcess::do_macro_match is still wrong, please read 
https://metacpan.org/pod/distribution/Marpa-R2/pod/Scanless/R.pod#g1_location_to_span()
 
.

"Mike's" workaround is quite correct, you have to "merge" the G1 start and 
end locations.

Clearer code in attachment.

Le samedi 4 août 2018 16:24:44 UTC+2, Michael Spertus a écrit :
>
> Hi Jeffrey,
> While that works for the simple example, it seems to fail for slightly 
> more complex examples (Now I don''t feel bad about having had trouble with 
> this to begin with!)
>
> The attached a program that demonstrates the problem and the (surprisingly 
> messy) fix as shown by the following output
>
> location() is (0, 3)
>> G1 first is 1
>> G1 last is 3
>> input span starts at 0
>> span length is 7
>>
>> *Jeffrey's literal is not the entire match: #defineMike's literal is the 
>> entire match:  #define foo bar*
>>
>>
> In any case, I have a working solution now, so I'm good to go.
>
> Thanks,
>
> Mike
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
use Marpa::R2;

my $dsl = <<'END_OF_DSL';
:default ::= action => [name,values]
lexeme default = latm => 1

:start ::= matches

matches ::= match+
match ::= id | macro action => do_macro_match
macro ::= '#define' identifier identifier
id ::= identifier

identifier ~ [\w]+
:discard ~ whitespace
whitespace ~ [\s]+

END_OF_DSL


my $grammar = Marpa::R2::Scanless::G->new( { source => \$dsl } );
my $recce = Marpa::R2::Scanless::R->new(
{ grammar => $grammar, semantics_package => 'CodeProcess' } );

my $input = '#define foo bar';
my $length_read = $recce->read( \$input );

my $value_ref = $recce->value;
my $value = ${$value_ref};


sub CodeProcess::span_merge {
my ($g1_before, $g1_after) = Marpa::R2::Context::location();

my @span_first = $recce->g1_location_to_span($g1_before + 1);
my @span_last  = $recce->g1_location_to_span($g1_after);

my @starts = ($span_first[0], $span_last[0]);
my @ends   = ($span_first[0] + $span_first[1], $span_last[0] + $span_last[1]);

my $span_merge_start = ($starts[0] < $starts[1]) ? $starts[0] : $starts[1];
my $span_merge_end   = ($ends  [0] > $ends  [1]) ? $ends  [0] : $ends  [1];

return ($span_merge_start, $span_merge_end - $span_merge_start);
}

sub CodeProcess::do_macro_match {
print "Span merge's literal gives the entire match:  ".$recce->literal(CodeProcess::span_merge())."\n";
}

Re: Java 8 Parser

[Durand Jean-Damien]

Hello,

With Marpa::R2 it is possible to do exclusions at the lexeme level using 
user-defined character classes.

Such an implementation was used in ECMAScript as mentionned indeed by 
Jeffrey, c.f; 
https://github.com/jddurand/MarpaX-Languages-ECMAScript-AST/blob/master/lib/MarpaX/Languages/ECMAScript/AST/Grammar/CharacterClasses.pm
 
(which I admint is a bit hard to understand stand-alone without the grammar 
itself - but these are the lexeme implementation with... exclusions).
For example:

sub IsSourceCharacterButNotStarOrLineTerminator { return <
> Hello,
>
> I'm very new to Marpa but, from its description, it looks extremely 
> awesome. 
>
> I'm also done playing with the beginner's example of the expression 
> calculator; was also able to make small changes to it. So far, so good.
>
> However, now, I'm trying to write a Java 8 Parser using the grammar 
> published here:
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-19.html
>
> While I think I'm able to map the above Oracle grammar spec to the G1 
> rules (if I stub out some of the lexemes referenced the G1 rules) and 
> create an instance of Marpa::R2::Scanless::G, I'm having a hard time 
> writing the L0 lexer rules in SLIF for the Lexer grammar 
> .  Some 
> issues that I will need to (but don't know how to) deal with are:
>
> 1. Keyword vs Identifier: 
>
>   The Java spec defines Identifier 
>  
> thus:
> Identifier:
> IdentifierChars 
> 
>  but not a Keyword 
> 
>  or BooleanLiteral 
> 
>  or NullLiteral 
> 
> IdentifierChars:
> JavaLetter 
> 
>  {JavaLetterOrDigit 
> 
> }
> JavaLetter:
> any Unicode character that is a "Java letter"
> JavaLetterOrDigit:
> any Unicode character that is a "Java letter-or-digit"
>   *So, how do I do* the "not a Keyword or BooleanLiteral or NullLiteral" 
> part? In Perl regex, one could do a negative lookahead assertion like so...
> 
> if (m/ (?! $Keyword | $BooleanLiteral | $NullLiteral ) $IdentifierChars /x
> ) {
> # this is an Identifier
> }
>
>
> ... but only if Marpa allowed such a rich, Perl regex syntax. Which it 
> doesn't, apparently, in SLIF.
>
> 2. Comment (single- and multi-line versions)
> I could write a bunch of G1 rules to handle the multi-line Java comment, 
> but I'm seeing it becoming very verbose. Is there an easier way to handle 
> stuff like this in SLIF?
>  
> 3. Since Marpa is Perl-based, is it possible to tap the full power of Perl 
> regex engine, especially for lexing? 
>
> 4. Notice that Java 8 spec for recognizing tokens is in the form of a Lexer 
> grammar ... 
> that is written in BNF style instead of a 'flat', regex style. If I were to 
> mechanically replicate the Lexer grammar using G1 rules (instead of L0 
> rules), would it entail a performance and space overhead by creating 
> unnecessary tree nodes for what would otherwise be a flat lexeme in 
> bison/flex?
>
> 5. Would Marpa experts recommend using SLIF (internal scanner) for Java 8, 
> or should I abandon it in favor of a custom / external lexer?
>
>
> Regards,
> /Harry
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Marpa from Ruby

[Durand Jean-Damien]

Thanks - got the third edition, quite a big grammar. And for the PSL ?

Le vendredi 5 août 2016 20:07:30 UTC+2, ioba...@gmail.com a écrit :
>
> I'm using the EBNF in Ashenden's book, "Designer's Guide to VHDL."  You 
> can also get a current copy of the VHDL spec (VHDL-1076) from IEEE.
>
> - Ryan
>
> On Thursday, August 4, 2016 at 2:30:07 PM UTC-6, Durand Jean-Damien wrote:
>>
>> For curiosity, can you give a link on the reference that you are using 
>> for this language, if possible?
>> Thanks.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Marpa from Ruby

[Durand Jean-Damien]

For curiosity, can you give a link on the reference that you are using for 
this language, if possible?
Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to handle comments alongside regular code

[Durand Jean-Damien]

Usually comments are managed by a :discard rule, for example:

:discard ~ 
:discard ~ 

##
# Discard of a C++ comment
##
 ~ '//' 
 ~ [^\n]*


# Discard of a C comment, c.f. https://gist.github.com/jeffreykegler/5015057

 ~ '/*'  '*/'
 ~



 ~ [^*]*
 ~ *
 ~  [^/*] 
 ~ [*]+
 ~ [^*]*
 ~ [*]*

Regards, Jean-Damien

Le dimanche 17 avril 2016 07:12:06 UTC+2, haroldo...@gmail.com a écrit :
>
> hi, i'd like to write a parser to a DSL in which I have a lot of code 
> written. There are comments, as usual. I believe the comments are a 
> constituent part of the operational body. Should I put the comments 
> nonterminal in each G1 rule , so that I can do things with them as I do 
> things with the DSL lines ? Or should I parse twice , one with the 
> comments, and one with the code, and then link them back somehow?
>
> thanks!
> Haroldo
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Blog post: Binary parsing with Marpa: .class files

[Durand Jean-Damien]

FYI

Binary parsing with Marpa: .class files 


Regards, Jean-Damien.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: "Top-down parsing is guessing": new blog post.

[Durand Jean-Damien]

>
> Also, in this list, http://savage.net.au/Marpa.html#Perl_Packages, J 
> Durand has a number of modules, some of which likewise patch the BNF.
>


All are "hacks" in the sense that there is no meta-package describing the 
BNF itself. Once I had a look to Grammar::Formal 
 though, that looked promising in 
such direction 

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: action => ::lhs

[Durand Jean-Damien]

Yes, nice alternative.
I am using this in a framework on any BNF to automatically fill structures 
on-demand -;

https://github.com/jddurand/MarpaX-Role-Parameterized-ResourceIdentifier/blob/master/lib/MarpaX/Role/Parameterized/ResourceIdentifier/BNF.pm#L699

Le vendredi 27 novembre 2015 09:41:52 UTC+1, Cev Ing a écrit :
>
>
> Am Donnerstag, 26. November 2015 23:53:26 UTC+1 schrieb Jeffrey Kegler:
>>
>> The LHS is available to an action via context variables 
>> .
>>   
>> So you could write your own dispatcher and either make it the default 
>> action or apply it selectively.
>>
>
> Thanks. This action helps me getting warm with Marpa actions:
>
> sub lhs {
>   my ($lhs) = map {
> $Marpa::R2::Context::slg->symbol_display_form($_)
>   } $Marpa::R2::Context::slg->rule_expand($Marpa::R2::Context::rule);
>   return $lhs;
> }
>
> sub dump_and_exit
> {
>   my ($self, @args) = @_;
>   print lhs, "\n", Dumper (@args);
>   exit;
> }
>
> I use it gradually from the top to the bottom of the grammar. After 
> reaching the bottom I can go back to the top by replacing each 
> dump_and_exit by some useful code. Together with the default action 
> [name,values] I think I can finish my task pretty fast.
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PHP parser?

[Durand Jean-Damien]

rns,

Also IDL and SQL2003 -; others I do not mention until it is published on 
CPAN.

JD.

Le jeudi 28 mai 2015 13:33:43 UTC+2, rns a écrit :
>
> Hi, 
>
> Jean-Damien Durand did parsers for C, SQL, ECMAScript, m4 -- 
> https://github.com/jddurand?tab=repositories
>
> If you start with a PHP EBNF grammar, e.g. [1] -- perhaps you can find 
> useful a Lua parser I did -- I started with a similar EBNF for Lua [2], 
> converted it to Marpa SLIF (EBNF is preserved in comments, e.g. [3]). I 
> used external lexer, but you don't necessarily have to.
>
> Hope it helps.
>
> [1] http://www.icosaedro.it/articoli/php-syntax-ebnf.txt
>
> [2] http://www.lua.org/manual/5.1/manual.html#8
>
> [3] 
> https://github.com/rns/MarpaX-Languages-Lua-AST/blob/master/lib/MarpaX/Languages/Lua/AST.pm#L50
>
>
>
>
> On Thu, May 28, 2015 at 2:05 PM, Helmut Wollmersdorfer <
> helmut.wollmersdor...@gmail.com> wrote:
>
>> Hi,
>>
>> did somebody a PHP parser with Marpa, maybe unfinished?
>>
>> At the moment I adopted one using Parse::RecDescent, restricted to 
>> variables/structures. But with the time invested to get in running it would 
>> have been better to use Marpa.
>>
>> If nobody did, which implemented parser (for a similar language) can I 
>> take as a starting point?
>>
>> TIA
>>
>> Helmut Wollmersdorfer
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "marpa parser" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to marpa-parser+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PHP parser?

[Durand Jean-Damien]

Converting the EBNF grammar rns mentionned does not look that hard.
Did you managed to get on with a full Marpa version or gave up ?
Regards, Jean-Damien.

Le jeudi 28 mai 2015 13:33:43 UTC+2, rns a écrit :
>
> Hi, 
>
> Jean-Damien Durand did parsers for C, SQL, ECMAScript, m4 -- 
> https://github.com/jddurand?tab=repositories
>
> If you start with a PHP EBNF grammar, e.g. [1] -- perhaps you can find 
> useful a Lua parser I did -- I started with a similar EBNF for Lua [2], 
> converted it to Marpa SLIF (EBNF is preserved in comments, e.g. [3]). I 
> used external lexer, but you don't necessarily have to.
>
> Hope it helps.
>
> [1] http://www.icosaedro.it/articoli/php-syntax-ebnf.txt
>
> [2] http://www.lua.org/manual/5.1/manual.html#8
>
> [3] 
> https://github.com/rns/MarpaX-Languages-Lua-AST/blob/master/lib/MarpaX/Languages/Lua/AST.pm#L50
>
>
>
>
> On Thu, May 28, 2015 at 2:05 PM, Helmut Wollmersdorfer <
> helmut.wollmersdor...@gmail.com> wrote:
>
>> Hi,
>>
>> did somebody a PHP parser with Marpa, maybe unfinished?
>>
>> At the moment I adopted one using Parse::RecDescent, restricted to 
>> variables/structures. But with the time invested to get in running it would 
>> have been better to use Marpa.
>>
>> If nobody did, which implemented parser (for a similar language) can I 
>> take as a starting point?
>>
>> TIA
>>
>> Helmut Wollmersdorfer
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "marpa parser" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to marpa-parser+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

A Marpa/Moops powered M4 implementation

[Durand Jean-Damien]

FYI

c.f. this blog post 


JD.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Marpa-R2 2.103_008 -- Discard events are ready!

[Durand Jean-Damien]

This mean I'll can (a dream I had in the past!) get rid of an infamous 
hiden routine in MarpaX::Languages::C::AST: _doPreprocessing() 

  
!

This routine exists because I needed to catch the #line preprocessor 
information before the parser discard it... you see the point : there was 
valuable information in something that is orthogonal to the grammar, and 
that only :discard could catch.
An excellent timing since I planned to go back to this module soon. Will 
keep you informed.

Thanks / JD.

Le lundi 23 février 2015 02:28:47 UTC+1, Jeffrey Kegler a écrit :
>
> I have uploaded Marpa-R2 2.103_008 to CPAN.  It contains the discard 
> events, this time *with* documentation.  For the documentation coverage of 
> discard events, start here 
> ,
>  
> here 
> 
>  
> and here 
> 
> .
>
> This might be a release candidate, but I may want to wait for the work on 
> Libmarpa nits to finish, I'm not sure.  Anyway, now you really can get 
> started with discard events -- they should be 100% ready with this release.
>
> And testing is appreciated!
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFD: MIT/Lua License for Libmarpa

[Durand Jean-Damien]

Frightening -; !

Le mercredi 18 février 2015 22:33:39 UTC+1, Ron Savage a écrit :
>
> A scary article on algorithmic patenting: 
> http://yro-beta.slashdot.org/story/15/02/17/2032207/algorithmic-patenting
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MarpaX::Languages::M4

[Durand Jean-Damien]

For the curious: https://github.com/jddurand/MarpaX-Languages-M4

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

MarpaX::Languages::M4

[Durand Jean-Damien]

FYI

There a new module coming into CPAN, the M4 pre-processor. The current 
version is 0.001-TRIAL, time to check current status and fix latest gotchas.

More on my G+ 
page: https://plus.google.com/105243759955561553019/posts/9mxZnV1Vwws

What is interesting in this module is:

   - Moops oriented
   - Marpa is used to drive the context and to get parse tree values only. 
   I mean: the SLIF interface is used only the describe the grammar and get 
   pauses on every lexemes. That is, it has this very special recognizer 
   instanciation:


#
# The stream itself is of no importance.
# We use Marpa to drive the context, nothing more.
# But is it NOT a hasard that I use the constant '(':
# when doing a recursive call using
# the macroByarguments grammar, Marpa will expect this
# character at the first read, EVEN
# if we paused before it.
#
$r->read( \'(' );


I'll blog on it also / JD.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Announce Text::Balanced::Marpa V 1.00

[Durand Jean-Damien]

Ok,
This role underneath is a Log::Any thingy as you know, and I want to say 
that Log::Any has a very nice feature that I use often: being able to dump 
anything with a single "printf" like method, extremey useful for debugging 
and/or showing everything, e.g.:

perl -MLog::Handler -MLog::Any::Adapter -e '
my $lh = Log::Handler->new(screen => {log_to => "STDOUT"});
Log::Any::Adapter->set("Handler", logger => $lh);
my $log = Log::Any->get_logger();

my $anything = {hash => [ { again => "x" }, "y" ]};
$log->warnf("===> Dumped: %s", $anything);
'
janv. 22 06:14:15 [WARNING] ===> Dumped: {hash => [{again => "x"},"y"]}

JD.

Le jeudi 22 janvier 2015 03:11:19 UTC+1, Ron Savage a écrit :
>
> Ah. It has an adapter for Log::Handler. Let me think about it.
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Announce Text::Balanced::Marpa V 1.00

[Durand Jean-Damien]

Since this is Moo based, what about MooX::Role::Logger ?

Le lundi 19 janvier 2015 00:10:38 UTC+1, Ron Savage a écrit :
>
> I've released V 1.06.
>
> The most noticeable change is that parse() now takes a hash, whose keys 
> can be any of length, pos, options or text.
>
> Also, the constant 'debug' is now called 'print_debugs'.
>
> Lastly, errors are no longer printed by default. You can turn on the new 
> constant 'print_errors' to get them.
>
> This makes the code quieter (if you have errors), but matches the design 
> of X500::DN::Marpa, and is my new policy on constants and printing errors.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Discard events -- a design document

[Durand Jean-Damien]

Jeffrey,

Very good. This will adress Zeev's need. I'll probably reinsert comments in 
the AST as an post-value processing.

Many thanks, JD.

Le lundi 12 janvier 2015 03:49:46 UTC+1, Jeffrey Kegler a écrit :
>
> I've written a design document for "discard events 
> " 
> -- events generated when a token is discarded.  These come out of a 
> discussion on this group, and on the IRC channel.  Your feedback and input 
> is appreciated.
>
> -- jeffrey
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overriding error handlers

[Durand Jean-Damien]

Oups... copy/paste problems, sorry.


>- For comments on general, you might want to join the IRC channel 
>#marpa on irc.freenode.net, c.f. 
>https://groups.google.com/d/msg/marpa-parser/ZIZ003_GUig/3ti4II8HRrgJ
>
>
Should read http://irclog.perlgeek.de/marpa/2015-01-08#i_9906680


>- For the particular "TOP 5" case, this is just a grammar extension 
>like GNU or MS did to the C language.
>   - What about adding this explicitely to the grammar, then? If you 
>   are ready to fork the repo on github, try, and confirm this is ok, I 
> can 
>   release that. Perhaps with a special flag... ?
>   - From 
>   https://groups.google.com/d/msg/marpa-parser/ZIZ003_GUig/3ti4II8HRrgJ
>
> Should read http://www.w3schools.com/sql/sql_top.asp 

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overriding error handlers

[Durand Jean-Damien]

Zeev,


   - For comments on general, you might want to join the IRC channel #marpa 
   on irc.freenode.net, 
   c.f. https://groups.google.com/d/msg/marpa-parser/ZIZ003_GUig/3ti4II8HRrgJ
   - For the particular "TOP 5" case, this is just a grammar extension like 
   GNU or MS did to the C language.
  - What about adding this explicitely to the grammar, then? If you are 
  ready to fork the repo on github, try, and confirm this is ok, I can 
  release that. Perhaps with a special flag... ?
  - From 
https://groups.google.com/d/msg/marpa-parser/ZIZ003_GUig/3ti4II8HRrgJ 
  I see this can differ between multiple SQL implementations. So suppose I 
  add parameters like:
 - -- extension top (in the command-line)
 - extension => {top => 1} (in the API)
  
... wil that be ok for you ?

Le jeudi 8 janvier 2015 20:25:25 UTC+1, Zeev Atlas a écrit :
>
> The most important case that I have in mind is the SQL Server 'SELECT TOP 
> 5 col1, col2, ...'.  Wouldn't the Pre-lexeme event be better then the 
> Rejection in that particular case?  I am reading the documentation as is 
> written now [
> http://search.cpan.org/~jkegl/Marpa-R2-2.101_000/pod/Event.pod#The_life_cycle_of_events].
>   
> The events and their use is not always clear from the documentation.  
> You've mentioned that what I want to achieve could be done in various ways 
> and I assume that you meant by judicious use of the events.  I need a bit 
> of help here, like better, less formal and more example oriented 
> explanation of the events.
> Thank you
> ZA
>
>
> On Wednesday, December 31, 2014 12:24:58 PM UTC-5, Jeffrey Kegler wrote:
>
>> Zeev -- the sort of thing you suggest can be done, in various ways.  You 
>> can pause the parse, switch to manual parsing, and resume the input at an 
>> input location of your choice.
>>
>> As an example of this sort of thing, I recently did my own example of 
>> delimiter handling 
>> 
>>  
>> which, when it encounters a missing delimiter, supplies it.
>>
>> The reason I think you see the others (and myself) preferring a direct, 
>> rule-based, approach is that it makes for simpler, faster and more 
>> maintainable code, when it is possible.  And what with the wide variety of 
>> grammars that Marpa can parse, plus various tricks such as ranking rules, 
>> it often is possible.
>>
>> On Wed, Dec 31, 2014 at 4:37 AM, Zeev Atlas  wrote:
>>
>>> As I read more and begin to grasp the complexity of Marpa solution, and 
>>> the desire to work all issues from within the context of grammar, actions 
>>> (evemts, etc.) I can see why you guys want to insist on using rules and 
>>> only rules, whether positive or negative, to parse the subject.  Let me 
>>> please givee you a counter argument:
>>> I am not a native English speaker.  When I learned the language, till 
>>> today, when reading and parsing text, i may and do encounter words that I 
>>> do not know.  Instead of going to the dictionary, I encapsulate such words 
>>> and substitite them with either a context based approximation or with null 
>>> and try to continue parsing.  Rarely, indeed very rarely, I cannot proceed.
>>> What I would want is something similar, in which Marpa would tell me 
>>> that it have encountered such an element and allow me to advise it to 
>>> substitute it with something else or nullify it and continue.
>>> I do not know how hard is that to implement, but I suspect that it 
>>> should not be that hard.  And the practical benefits would be enormous
>>> ZA
>>>
>>> --
>>> You received this message because you are subscribed to the Google 
>>> Groups "marpa parser" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to marpa-parser...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Comments in SQL

[Durand Jean-Damien]

Zeev,

Comments is an orthogonal rule, that have no place in the BNF except in the 
discarded thing, and per def discarded things are not part of the final AST.
In conclusion, this is not supported.

Regards, Jean-Damien.

Le jeudi 8 janvier 2015 04:11:32 UTC+1, Zeev Atlas a écrit :
>
> I had a chance to feed some SQL statements of varied complexity to 
> MarpaX::Languages::SQL2003::AST.  I do not yet look into error capturing, 
> so all the SQL statements that I use are absolutely valid.  My current task 
> is to review and understand the produced XML.
> I've noticed that while the parser recognizes comments as such and 
> correctly ignores them, it does not produce them in the XML output.  Would 
> it be that hard to produce a valid XML comment:
> 
> Or is that already a supported option?
> Thanks
> ZA
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overriding error handlers

[Durand Jean-Damien]

Le mardi 30 décembre 2014 23:32:26 UTC+1, Ron Savage a écrit :
>
> o Change the grammar.
>
> If choosing the 2nd, I'd subclass MarpaX::Languages::SQL2003::AST and 
> commit myself to adding as much MS-specific code to the grammar as needed 
> to make the project work. The advantage is that you can get help here on 
> the syntax for such grammar extensions. And it's immeasurably better if 1 
> module does this than if everyone tries to do it in parallel, since we all 
> then have access to a new custom module.
>

This is a bit like the C grammar. By itself, it will never parse a 
preprocessed output of GNU CC nor MS cl. So extensions are added 
explicitely in the grammar.
Extending and/or subclassing the grammar is one nice way, 'error rules' is 
another very nice way -; 

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ideas for parsing with error messages and diagnostics

[Durand Jean-Damien]

Yes, very nice idea.
Wondering if that could not be a builtin L1 alternative -;

Le mercredi 31 décembre 2014 07:08:01 UTC+1, Ron Savage a écrit :
>
> This sounds very interesting.
>
> For instance, you don't even need to think of one as a 'error grammar'. 
> Consider: SQL2003 and SQL Server's dialect and Pg's dialect /all in the 
> same BNF/!
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Valid BNF question

[Durand Jean-Damien]

Zeev,

It is not a hasard that I provided the XML stuff. Searching in XML using 
XPath and nagivating in an XML is far easier that with Perl's blessed 
structures.

   - printout the ast using  
   MarpaX::Languages::SQL2003::AST->new()->asXML($input)->toString(1) instead 
   of trying to digest the grammar
   - you will see the hierarchy of what you are looking for
   - use XPath
   
Example in attachement on how to find the table names.

If you insist on the blessed mode, perl people would suggest modules like 
Data::Find or Data::Walk, I'd personnaly revisit 
MarpaX::Languages::C::AST::Util::Data::Find 
<https://github.com/jddurand/MarpaX-Languages-C-AST/blob/master/lib/MarpaX/Languages/C/AST/Util/Data/Find.pm>,
 
taking into account that with MarpaX::Languages::SQL2003::AST, a lexeme is 
a blessed hash that is guaranteed to have keys "start", "length", "text" 
and "value", when an lhs is blessed array.

Jean-Damien.

Le jeudi 18 décembre 2014 16:11:37 UTC+1, Zeev Atlas a écrit :
>
> Thank you again for advice and support
> Is there any 'accessor' or a template for such an accessor for the blessed 
> structure that is available anywhere in the Marpa world?  (before I code 
> such an accessor myself and risk being incompatible with next version.)
> ZA
>
> On Tuesday, December 16, 2014 12:39:00 PM UTC-5, Durand Jean-Damien wrote:
>
>> Ok, so I do nothing / JD.
>>
>> Le mardi 16 décembre 2014 07:16:38 UTC+1, toratea...@gmail.com a écrit :
>>>
>>> Thank you... regardless, I tried your suggestion and will move to 
>>> strawberry anyway, since I can install XML::LibXML and I guess anything else
>>> In any case, for my purpose, the AST is all what I need.  I intend to 
>>> write an application that analyze SQL statements and deduce source tables 
>>> and where/join-on clauses, basically find the flow of data and put it in 
>>> csv/excel format.
>>> ZA
>>>
>>> On Monday, December 15, 2014 11:30:00 PM UTC-5, Durand Jean-Damien wrote:
>>>>
>>>> Yes, this is easy... will keep you informed
>>>>
>>>> Le mardi 16 décembre 2014 04:46:43 UTC+1, Zeev Atlas a écrit :
>>>>>
>>>>> XML::LibXML is not available (yet) for ActiveState Perl 5.16 and above 
>>>>> and I use 5.18.  Is it possible to create a package that produces AST 
>>>>> version only and does not have 'use XML::LibXML;' at all.  I do not have 
>>>>> too much experience with Linux (barely have one machine with Ubuntu).  I 
>>>>> will go for strawberry only if I have no other choice (because it 
>>>>> resembles 
>>>>> the Linux environment)
>>>>> Thanks
>>>>> ZA
>>>>>
>>>>> On Sunday, December 14, 2014 10:48:22 AM UTC-5, Durand Jean-Damien 
>>>>> wrote:
>>>>>>
>>>>>> ActiveState will certainly work on that, I bet users of this 
>>>>>> dsitribution can't stand without XML::LibXML for a while, usual bribes 
>>>>>> or 
>>>>>> whatever PPDs can perhaps help, although I guess you (perhaps) already 
>>>>>> tried.
>>>>>> I personnaly stopped using this distribution in favour of strawberry, 
>>>>>> that has both the advantage and drawback that it is not using nmake/cl.
>>>>>>
>>>>>> http://code.activestate.com/ppm/XML-LibXML/
>>>>>>
>>>>>> JD.
>>>>>>
>>>>>> Le dimanche 14 décembre 2014 02:00:20 UTC+1, Zeev Atlas a écrit :
>>>>>>>
>>>>>>> Thanks again... I work on a Windows platform (active state Perl) and 
>>>>>>> there is no XML::LibXML.  I'll have to make some adjustments in the 
>>>>>>> next 
>>>>>>> few days or just look at the module and do my own.  
>>>>>>>
>>>>>>> On Saturday, December 13, 2014 9:40:54 AM UTC-5, Durand Jean-Damien 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Zeev,
>>>>>>>>
>>>>>>>> Instead I invite you to try the sql2003toxml binary distributed 
>>>>>>>> with MarpaX::Languages::SQL2003::AST, c.f. my g+ post 
>>>>>>>> <https://plus.google.com/105243759955561553019/posts/Mn7DQSJuKc8>.
>>>>>>>>
>>>>>>>> Jean-Damien.
>>>>>>>>
>>>>>

Re: Valid BNF question

[Durand Jean-Damien]

Ok, so I do nothing / JD.

Le mardi 16 décembre 2014 07:16:38 UTC+1, toratea...@gmail.com a écrit :
>
> Thank you... regardless, I tried your suggestion and will move to 
> strawberry anyway, since I can install XML::LibXML and I guess anything else
> In any case, for my purpose, the AST is all what I need.  I intend to 
> write an application that analyze SQL statements and deduce source tables 
> and where/join-on clauses, basically find the flow of data and put it in 
> csv/excel format.
> ZA
>
> On Monday, December 15, 2014 11:30:00 PM UTC-5, Durand Jean-Damien wrote:
>>
>> Yes, this is easy... will keep you informed
>>
>> Le mardi 16 décembre 2014 04:46:43 UTC+1, Zeev Atlas a écrit :
>>>
>>> XML::LibXML is not available (yet) for ActiveState Perl 5.16 and above 
>>> and I use 5.18.  Is it possible to create a package that produces AST 
>>> version only and does not have 'use XML::LibXML;' at all.  I do not have 
>>> too much experience with Linux (barely have one machine with Ubuntu).  I 
>>> will go for strawberry only if I have no other choice (because it resembles 
>>> the Linux environment)
>>> Thanks
>>> ZA
>>>
>>> On Sunday, December 14, 2014 10:48:22 AM UTC-5, Durand Jean-Damien wrote:
>>>>
>>>> ActiveState will certainly work on that, I bet users of this 
>>>> dsitribution can't stand without XML::LibXML for a while, usual bribes or 
>>>> whatever PPDs can perhaps help, although I guess you (perhaps) already 
>>>> tried.
>>>> I personnaly stopped using this distribution in favour of strawberry, 
>>>> that has both the advantage and drawback that it is not using nmake/cl.
>>>>
>>>> http://code.activestate.com/ppm/XML-LibXML/
>>>>
>>>> JD.
>>>>
>>>> Le dimanche 14 décembre 2014 02:00:20 UTC+1, Zeev Atlas a écrit :
>>>>>
>>>>> Thanks again... I work on a Windows platform (active state Perl) and 
>>>>> there is no XML::LibXML.  I'll have to make some adjustments in the next 
>>>>> few days or just look at the module and do my own.  
>>>>>
>>>>> On Saturday, December 13, 2014 9:40:54 AM UTC-5, Durand Jean-Damien 
>>>>> wrote:
>>>>>>
>>>>>> Zeev,
>>>>>>
>>>>>> Instead I invite you to try the sql2003toxml binary distributed with 
>>>>>> MarpaX::Languages::SQL2003::AST, c.f. my g+ post 
>>>>>> <https://plus.google.com/105243759955561553019/posts/Mn7DQSJuKc8>.
>>>>>>
>>>>>> Jean-Damien.
>>>>>>
>>>>>> Le vendredi 12 décembre 2014 14:10:07 UTC+1, Zeev Atlas a écrit :
>>>>>>>
>>>>>>> COuld you please migrate the POC as well
>>>>>>> ZA
>>>>>>>
>>>>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Valid BNF question

[Durand Jean-Damien]

Yes, this is easy... will keep you informed

Le mardi 16 décembre 2014 04:46:43 UTC+1, Zeev Atlas a écrit :
>
> XML::LibXML is not available (yet) for ActiveState Perl 5.16 and above and 
> I use 5.18.  Is it possible to create a package that produces AST version 
> only and does not have 'use XML::LibXML;' at all.  I do not have too much 
> experience with Linux (barely have one machine with Ubuntu).  I will go for 
> strawberry only if I have no other choice (because it resembles the Linux 
> environment)
> Thanks
> ZA
>
> On Sunday, December 14, 2014 10:48:22 AM UTC-5, Durand Jean-Damien wrote:
>>
>> ActiveState will certainly work on that, I bet users of this dsitribution 
>> can't stand without XML::LibXML for a while, usual bribes or whatever PPDs 
>> can perhaps help, although I guess you (perhaps) already tried.
>> I personnaly stopped using this distribution in favour of strawberry, 
>> that has both the advantage and drawback that it is not using nmake/cl.
>>
>> http://code.activestate.com/ppm/XML-LibXML/
>>
>> JD.
>>
>> Le dimanche 14 décembre 2014 02:00:20 UTC+1, Zeev Atlas a écrit :
>>>
>>> Thanks again... I work on a Windows platform (active state Perl) and 
>>> there is no XML::LibXML.  I'll have to make some adjustments in the next 
>>> few days or just look at the module and do my own.  
>>>
>>> On Saturday, December 13, 2014 9:40:54 AM UTC-5, Durand Jean-Damien 
>>> wrote:
>>>>
>>>> Zeev,
>>>>
>>>> Instead I invite you to try the sql2003toxml binary distributed with 
>>>> MarpaX::Languages::SQL2003::AST, c.f. my g+ post 
>>>> <https://plus.google.com/105243759955561553019/posts/Mn7DQSJuKc8>.
>>>>
>>>> Jean-Damien.
>>>>
>>>> Le vendredi 12 décembre 2014 14:10:07 UTC+1, Zeev Atlas a écrit :
>>>>>
>>>>> COuld you please migrate the POC as well
>>>>> ZA
>>>>>
>>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Required first characters

[Durand Jean-Damien]

John,

Can you please post the grammar + input showing the problem.
Guessing that if a :discard rule eating space is not doing it, you can have 
a token that begins with nothing [^\s\S] or newline followed by IF, and a 
pause before that will remove the newline *if* you need to do so.

Jean-Damien.

Le lundi 15 décembre 2014 17:24:38 UTC+1, John Alvord a écrit :
>
> In my syntax checker, a proper form starts off
>
> *IF
>
> Whitespace is discarded.
>
> In the data from customers, I found a case where the first character was a 
> blank... and that triggered incorrect processing later.
>
> Is there a way to code that in the rules, or must I add a pre-syntax check 
> logic.
>
> John Alvord
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MarpaX-Languages-SQL2003-AST

[Durand Jean-Damien]

http://blogs.perl.org/users/jean-damien_durand/2014/12/a-marpa-powered-sql-2003-parser.html

Le dimanche 14 décembre 2014 16:34:10 UTC+1, Durand Jean-Damien a écrit :
>
> FYI
>
> I have pushed to CPAN a complete (and certainly not bug free -;) SQL 2003 
> parser.
>
> Internally, this is Ron's sql-2003-2.bnf 
> <http://savage.net.au/SQL/sql-2003-2.bnf> EBNF translated to Marpa::R2's 
> BNF, and a call to Marpa;;R2 (severe!) parse() method. There is a funny 
> associated binary: sql2003ast to get on the terminal a view of the AST, in 
> either perl's bless or XML formats.
>
> I will also blog about it.
>
> Jean-Damien.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Valid BNF question

[Durand Jean-Damien]

ActiveState will certainly work on that, I bet users of this dsitribution 
can't stand without XML::LibXML for a while, usual bribes or whatever PPDs 
can perhaps help, although I guess you (perhaps) already tried.
I personnaly stopped using this distribution in favour of strawberry, that 
has both the advantage and drawback that it is not using nmake/cl.

http://code.activestate.com/ppm/XML-LibXML/

JD.

Le dimanche 14 décembre 2014 02:00:20 UTC+1, Zeev Atlas a écrit :
>
> Thanks again... I work on a Windows platform (active state Perl) and there 
> is no XML::LibXML.  I'll have to make some adjustments in the next few days 
> or just look at the module and do my own.  
>
> On Saturday, December 13, 2014 9:40:54 AM UTC-5, Durand Jean-Damien wrote:
>>
>> Zeev,
>>
>> Instead I invite you to try the sql2003toxml binary distributed with 
>> MarpaX::Languages::SQL2003::AST, c.f. my g+ post 
>> <https://plus.google.com/105243759955561553019/posts/Mn7DQSJuKc8>.
>>
>> Jean-Damien.
>>
>> Le vendredi 12 décembre 2014 14:10:07 UTC+1, Zeev Atlas a écrit :
>>>
>>> COuld you please migrate the POC as well
>>> ZA
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

MarpaX-Languages-SQL2003-AST

[Durand Jean-Damien]

FYI

I have pushed to CPAN a complete (and certainly not bug free -;) SQL 2003 
parser.

Internally, this is Ron's sql-2003-2.bnf 
 EBNF translated to Marpa::R2's 
BNF, and a call to Marpa;;R2 (severe!) parse() method. There is a funny 
associated binary: sql2003ast to get on the terminal a view of the AST, in 
either perl's bless or XML formats.

I will also blog about it.

Jean-Damien.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Valid BNF question

[Durand Jean-Damien]

Zeev,

Instead I invite you to try the sql2003toxml binary distributed with 
MarpaX::Languages::SQL2003::AST, c.f. my g+ post 
.

Jean-Damien.

Le vendredi 12 décembre 2014 14:10:07 UTC+1, Zeev Atlas a écrit :
>
> COuld you please migrate the POC as well
> ZA
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Valid BNF question

[Durand Jean-Damien]

The MarpaX::Languages::SQL::AST repository will disappear in favour of 
MarpaX::Languages::SQL2003::AST 
 - please retry 
with the later.
JD.

Le jeudi 4 décembre 2014 18:37:51 UTC+1, Zeev Atlas a écrit :
>
> Hi all
> I am new to Marpa, so I may be trying to chew too much, but my question is 
> of general nature.
> I am interested ultimately in parsing SQL (not running it, just parsing 
> into structures that I could than analyze.)  So I wrote a simple program 
> that strip the SQL 2003 BNF file (http://savage.net.au/SQL/sql-2003-2.bnf) 
> from irrelevant data and try to feed it to Marpa as is.
>
> In the BNF I have clauses like this:
>  ::= %
> which I already figured out I need to change to something like
>  ::= '%'
>
> My issue is the infamous clauses:
>
>  ::= 
> or worse
>  ::= '
>
> Could somebody tell me please how should I deal with those
> note that 
>  ::= ' ' and  ::= ''' or  ::=  do not work
>
> BTW, if anybody already did a full featured (not specific dialect) SQL 
> parser (SQL::Statement is a relatively incomplete subset) or knows about 
> such one, please let me know.  Also, I am looking for dialect specific full 
> BNF files if available
>
> Thanks all 
> ZA
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Valid BNF question

[Durand Jean-Damien]

ps: I'll fix the fact that the XML is invalid - the concept does not change 
-;

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Valid BNF question

[Durand Jean-Damien]

Since the SQL topic got a revival I have reworked the grammar..


   - Now the AST in in the XML format (XML::LibXML thingy), as in the 
   example in attachement which is the AST of "select * from myTable;'.
   - The reworked grammar is in the __DATA__ section of 
   lib/MarpaX/Languages/SQL/AST/Grammar/ISO_IEC_9075_2_2003.pm 
   
<https://github.com/jddurand/MarpaX-Languages-SQL-AST/blob/master/lib/MarpaX/Languages/SQL/AST/Grammar/ISO_IEC_9075_2_2003.pm>
   - Please use the example that is in proof_of_concept/synopsis.pl 
   
<https://github.com/jddurand/MarpaX-Languages-SQL-AST/blob/master/proof_of_concept/synopsis.pl>
 to 
   reproduce the XML attached to this mail: perl -Ilib 
   proof_of_concept/synopsis.pl

Following a recent discussion on IRC 
<http://irclog.perlgeek.de/marpa/2014-12-07#i_9769809> with Jeffrey, I move 
to G1 a lot of the ambiguities of the SQL grammar and letted Marpa's LATM 
handle them.

Please note that SQL grammar being anyway *highly* ambiguous, my generated 
grammar is systematically executed with 'high_rule_only' ranking method, 
and that 100% of the grammar is (ab)using the rank Marpa facility:, I 
estimated that, alike in the old FLEX files where the lexemes priorities 
were implicit v.s. their appearance in the .lex file content, the rules in 
the SQL grammar have implicit priorities v.s. their appearance in the 
grammar.

Jean-Damien.

Le dimanche 7 décembre 2014 06:36:59 UTC+1, Durand Jean-Damien a écrit :
>
> Hello,
>
> Yes, grammar's defaults are right now:
>
> :default ::= action => [values] bless => ::lhs
> lexeme default = action => [start,length,value] latm => 1
>
> I'll may move to a DOM, optionally, if you prefer.
>
> Le dimanche 7 décembre 2014 03:28:36 UTC+1, Ron Savage a écrit :
>>
>> Could anybody comment about the below specific question and direct me to 
>>> the correct place where to get the information
>>> The object contains these:
>>> sample#1
>>> bless( [
>>>  [
>>>0,
>>>6,
>>>'CREATE'
>>>  ],
>>>  [
>>>7,
>>>6,
>>>'SCHEMA'
>>>  ],
>>> Where can I find the meanings of each of the three elements of the tuple 
>>> (the last one is obvious).
>>>
>>
>>  The output can be controlled by the programmer (i.e. every package can 
>> output a different format), but here I'd say 0 is the offset of the 1st 
>> token, and 6 is its length, while 7 is the offset of the 2nd token, and 6 
>> is its length.
>>  
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


synopsis.xml
Description: XML document

Re: Valid BNF question

[Durand Jean-Damien]

Hello,

Yes, grammar's defaults are right now:

:default ::= action => [values] bless => ::lhs
lexeme default = action => [start,length,value] latm => 1

I'll may move to a DOM, optionally, if you prefer.

Le dimanche 7 décembre 2014 03:28:36 UTC+1, Ron Savage a écrit :
>
> Could anybody comment about the below specific question and direct me to 
>> the correct place where to get the information
>> The object contains these:
>> sample#1
>> bless( [
>>  [
>>0,
>>6,
>>'CREATE'
>>  ],
>>  [
>>7,
>>6,
>>'SCHEMA'
>>  ],
>> Where can I find the meanings of each of the three elements of the tuple 
>> (the last one is obvious).
>>
>
>  The output can be controlled by the programmer (i.e. every package can 
> output a different format), but here I'd say 0 is the offset of the 1st 
> token, and 6 is its length, while 7 is the offset of the 2nd token, and 6 
> is its length.
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Marpa::R2 2.100000

[Durand Jean-Damien]

Tested ok on Windows 8 strawberry perl.

Le mardi 18 novembre 2014 03:43:06 UTC+1, Jeffrey Kegler a écrit :
>
> I just uploaded a new indexed release of Marpa::R2 to CPAN.  It's mainly 
> documentation updates & fixes.  Testing is appreciated!
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ambiguous methods: ambiguity_metric() and ambiguous()

[Durand Jean-Damien]

Just note that having an ambiguity metric does not mean that values() are 
different.
Nevertheless, you know that I love non-ambiguous grammars -;

Le mercredi 5 novembre 2014 22:41:08 UTC+1, Ron Savage a écrit :
>
> Say I want a program to provide an option for a user to abort the run if 
> an ambiguous grammar is detected.
>
> Should I test the return of just 1 of the above methods in preference to 
> the other? If so, which?
>
> I'm also thinking of whether it makes sense to report something to the 
> user after calling both methods, or for just call 1.
>
> Here's my preliminary code:
>
> if ($self -> recce -> ambiguity_metric > 1)
> {
> $self -> log(notice => 'Parse is ambiguous. Ambiguity metric > 1');
> }
>
> if (my $ambiguous_status = $self -> recce -> ambiguous)
> {
> $self -> log(notice => "Parse is ambiguous. Status: $ambiguous_status");
> }
>
> Obviously the 'notice' log level could become 'error', if the user wishes.
>
> Ideas?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Parsing domain names, and cookies

[Durand Jean-Damien]

It is overkill, but the proof of concept is more than that, since this was 
writen for ECMAScript, c.f. this post on blogs.perl.org 

 (which 
have semantics 99% like perl, with a big vicous exception for what is the 
"last match").

Le vendredi 3 octobre 2014 23:44:35 UTC+2, Ron Savage a écrit :
>
> Yes, Marpa seems like overkill. But it'd be slightly interesting to handle 
> the between-lines linkages.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A grammar for quoted strings with escaped chars

[Durand Jean-Damien]

Not sure I got it right from the beginning, but my attempt, using a 
"parameterized" subset of the C grammar is at 
https://gist.github.com/jddurand/8d3238c22731a85eb890 .
JD.

Le lundi 22 septembre 2014 09:12:31 UTC+2, Ron Savage a écrit :
>
> I've developed a grammar (with help from various people of course) for 
> quoted strings: http://scsys.co.uk:8002/424926
>
> Requirements:
>
> o Strings must be quoted
>
> o Strings are either single or double quoted
>
> o The escape character is \
>
> o If the string is single quoted, internal single quotes must be escaped
>
> o If the string is double quoted, internal double quotes must be escaped
>
> o Any other character may be escaped
>
> o If a character is escaped, the escape character is preserved in the 
> output
>
> o Empty strings are accepted
>
> ToDo: Make it work with utf8.
>
> Does anyone see problems, or other input strings which should be tested?
>
> Jeffrey: This is one of the plug-in grammars Jean-Damien and I talked 
> about recently. Any chance you can implement:
>
> my $source = <<'END_OF_GRAMMAR';
> ...
> :include /my/grammars/quoted.strings.bnf
> ...
> END_OF_GRAMMAR
>
> to include a suitable[*] grammar in situ within a grammar declaration?
>
> [*] Obviously, here that just means the prefix:
>
> :default ::= action => [values]
>
> lexeme default =  latm => 1 # Longest Acceptable Token Match.
>
> :start ::= string_token
>
> and the suffix:
>
> # Boilerplate.
>
> :discard ~ whitespace
> whitespace ~ [\s]+
>
> END_OF_GRAMMAR
>
> would not be present in the include file.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Low Hanging-fruit: Inline::Marpa

[Durand Jean-Damien]

In the same spirit of Inline::XXX I guess that being able to "inline" a BNF 
grammar would be great -;

I have the procedure doing so with an EBNF, easily translatable to Marpa's 
BNF (I used an internal meta-representation of the grammar).

Doing so raises the avaibility of Marpa as a shared library. Marpa::R2 
ships R2.so, while it would sound more natural with libmarpa.so.
In the later case, there would be the need ot marpa.h, though.

JD.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows build problem with spaces in name?

[Durand Jean-Damien]

Yep - this should do it - I personnally use(d) a mixture of 
Win32::ShellQuote and String::ShellQuote in some of my packages, c;f. for 
example 
https://github.com/jddurand/MarpaX-Languages-C-AST/blob/master/lib/MarpaX/Languages/C/AST/Grammar/ISO_ANSI_C_2011/Scan.pm#L767
 
(which could have been in a single routine of course).
JD.

Le mercredi 10 septembre 2014 19:12:47 UTC+2, rns a écrit :
>
> Wrapping $libmarpa_build_dir in double quotes in Build_Me.pm:
>
> - my @new_ccflags = ( '-I', $libmarpa_build_dir, '-I', 'xs' );
> +my @new_ccflags = ( '-I', '"' . $libmarpa_build_dir . '"', '-I', 'xs' );
>
> fixed it for me under 'John Doe' account on cygwin.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stackoverflow question about parsing C preprocessor files in Perl

[Durand Jean-Damien]

You're right - writing a real preprocessor was one of my other projects - 
but not done / JD.

Le mardi 9 septembre 2014 17:41:04 UTC+2, rns a écrit :
>
> subj 
> 
>  
> — I gave an answer, hope somebody can supplement. I take it that 
> Jean-Damien's MarpaX-Languages-C-AST parse C files only after preprocessor?
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New recce->doit() method, with test program

[Durand Jean-Damien]

Hello,

> The intent is that this is a very simple method, good for beginners and 
for a first cut, and uncomplicated by options

Then, very good!

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Subtleties of read() vs value() error handling

[Durand Jean-Damien]

Ok, point taken.
Marpa::R2  has now only a bug-fix only roadmap isn't it Jeffrey ? This 
sounds like a feature request.
About the name , hmmm eval() ?

Le vendredi 15 août 2014 22:37:29 UTC+2, Christopher Layne a écrit :
>
> Yes but value returns a ref to a ref so the user can still do that 
> already. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Subtleties of read() vs value() error handling

[Durand Jean-Damien]

IMHO I'd do nothing, the documentation states things clearly, the two error 
paths are for very different things.
In addition returning undef from value() could be a semantic user choice, 
not a invalid parse tree isn't it?

Le vendredi 15 août 2014 02:31:46 UTC+2, Ron Savage a écrit :
>
> On Friday, 15 August 2014 10:05:58 UTC+10, Christopher Layne wrote:
>>
>> On Aug 14, 2014, at 1650 PT, Ron Savage  wrote: 
>>
>> > On Friday, 15 August 2014 09:15:46 UTC+10, Christopher Layne wrote: 
>> > On Aug 14, 2014, at 1523 PT, Ron Savage  wrote: 
>> > 
>> > > Questions: 
>> > > 
>> > > Are these for C or Perl or both? 
>> > >   
>> > > 1.) What should be its name?  [Probably not doit() ]. 
>> > > 
>> > > I'd like it to be called process(). 
>> > 
>> > process() as an additional method also sounds find to me, although it's 
>> a bit non-parser like. However, the latter probably doesn't matter as it's 
>> an OO interface, and $parser->process() does make sense in that context. 
>> > 
>> > I do prefer process(), but now read_all() comes to mind. 
>>
>> I also thought about read_all() but the problem is that the _all() part 
>> implies "read all of the input." That's already what read() is doing and a 
>> matching call would be read_partial() which also wouldn't really be 
>> involved with what we're shooting for. I think your original process() is 
>> better than read_all(). $parser->run() would also work, as that's kind of 
>> what value() is already doing. I've always thought value() was named 
>> somewhat strangely for what it actually did - regardless of the fact that 
>> it returns value(s) for the parse. Perhaps that's because value() usually 
>> implies something already computed whereas value() itself definitely has 
>> significant side-effects. That wouldn't change though. 
>>
>
> Agreed. Forget read_all().
>
> As for run(), I think it's too general...
>
> As for value(), I would probably have called it result(), or perhaps even 
> status().
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Marpa::R2 release candidate: 2.089_001

[Durand Jean-Damien]

Was this bug in libmarpa or in the perl/xs world ?

Le samedi 9 août 2014 19:34:41 UTC+2, Jeffrey Kegler a écrit :
>
> Marpa::R2 2.089_001 is up on CPAN.  It's a release candidate. 
> CPANtesters looks good and I've gotten additional results from judrand 
> and rns on the IRC channel.  Additional testing is appreciated! 
>
> The main feature is the fix to the bug that Ion Toloaca reported to this 
> group. 
>
> -- jeffrey 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MarpaX-Languages-IDL-AST

[Durand Jean-Damien]

Here is the blogs.perl.org entry 
<http://blogs.perl.org/users/jean-damien_durand/2014/08/a-marpa-powered-idl-parser-and-translation-to-moose.html>
 .


Le samedi 9 août 2014 11:32:47 UTC+2, Durand Jean-Damien a écrit :
>
> FYI I have uploaded the first release of MarpaX-Languages-IDL-AST, which 
> contains a tool that translates and IDL to perl's Moose -;
> I should blog about it shortly.
> JD.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Strange behavior of Marpa events

[Durand Jean-Damien]

Note that MarpaX-Languages-C-AST seems to also use last_completed (when 
processing enums).
JD.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

MarpaX-Languages-IDL-AST

[Durand Jean-Damien]

FYI I have uploaded the first release of MarpaX-Languages-IDL-AST, which 
contains a tool that translates and IDL to perl's Moose -;
I should blog about it shortly.
JD.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Marpa::R2 and new PPI

[Durand Jean-Damien]

Test is OK.
Full log in attachment / JD.

Le mercredi 6 août 2014 02:31:53 UTC+2, Jeffrey Kegler a écrit :
>
> The PPI folks have suggested that releases that depend on PPI test with 
> the new PPI 1.217_01.  Marpa::R2 uses PPI for testing, if it is 
> present.  By default, Marpa::R2 will not install if these tests fail. 
>
> If one or more in the Marpa community could try the new PPI out, I'd 
> appreciate it.  I think what's needed is to install the new PPI, and 
> then attempt to reinstall Marpa::R2. 
>
> thanks, jeffrey 
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
┌─(ROOT@jddwww:pts/3)─(~)─┐
└─(02:40:#)── cpan M/MI/MITHALDU/PPI-1.217_01.tar.gz

  ──(mer.,août06)─┘
CPAN: Storable loaded ok (v2.41)
Reading '/root/.local/share/.cpan/Metadata'
  Database was generated on Tue, 05 Aug 2014 23:06:17 GMT
Running make for M/MI/MITHALDU/PPI-1.217_01.tar.gz
CPAN: LWP::UserAgent loaded ok (v6.06)
Fetching with LWP:
http://cpan.mirror.anlx.net/authors/id/M/MI/MITHALDU/PPI-1.217_01.tar.gz
CPAN: YAML loaded ok (v0.94)
CPAN: Digest::SHA loaded ok (v5.84_01)
Fetching with LWP:
http://cpan.mirror.anlx.net/authors/id/M/MI/MITHALDU/CHECKSUMS
CPAN: Compress::Zlib loaded ok (v2.064)
Checksum for 
/root/.local/share/.cpan/sources/authors/id/M/MI/MITHALDU/PPI-1.217_01.tar.gz ok
CPAN: File::Temp loaded ok (v0.23)
CPAN: Parse::CPAN::Meta loaded ok (v1.4414)
CPAN: CPAN::Meta loaded ok (v2.141520)
CPAN: Module::CoreList loaded ok (v3.03)

  CPAN.pm: Building M/MI/MITHALDU/PPI-1.217_01.tar.gz

Checking if your kit is complete...
Looks good
Warning: prerequisite Test::Object 0.07 not found.
Warning: prerequisite Test::SubCalls 1.07 not found.
Writing Makefile for PPI
Writing MYMETA.yml and MYMETA.json
 Unsatisfied dependencies detected during 
   MITHALDU/PPI-1.217_01.tar.gz   
Test::Object [build_requires]
Test::SubCalls [build_requires]
Running make test
  Delayed until after prerequisites
Running make install
  Delayed until after prerequisites
Running install for module 'Test::Object'
Running make for A/AD/ADAMK/Test-Object-0.07.tar.gz
Fetching with LWP:
http://cpan.mirror.anlx.net/authors/id/A/AD/ADAMK/Test-Object-0.07.tar.gz
Checksum for 
/root/.local/share/.cpan/sources/authors/id/A/AD/ADAMK/Test-Object-0.07.tar.gz 
ok

  CPAN.pm: Building A/AD/ADAMK/Test-Object-0.07.tar.gz

Checking if your kit is complete...
Looks good
Writing Makefile for Test::Object
Writing MYMETA.yml and MYMETA.json
cp lib/Test/Object.pm blib/lib/Test/Object.pm
cp lib/Test/Object/Test.pm blib/lib/Test/Object/Test.pm
Manifying blib/man3/Test::Object.3pm
  ADAMK/Test-Object-0.07.tar.gz
  /usr/bin/make -- OK
Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 
'inc', 'blib/lib', 'blib/arch')" t/*.t
t/01_compile.t .. ok   
t/02_simple.t ... ok   
t/99_pod.t .. skipped: Skipping module author tests
All tests successful.
Files=3, Tests=4,  1 wallclock secs ( 0.03 usr  0.00 sys +  0.08 cusr  0.00 
csys =  0.11 CPU)
Result: PASS
  ADAMK/Test-Object-0.07.tar.gz
  /usr/bin/make test -- OK
Running make install
Manifying blib/man3/Test::Object.3pm
Installing /usr/local/share/perl/5.18.2/Test/Object.pm
Installing /usr/local/share/perl/5.18.2/Test/Object/Test.pm
Installing /usr/local/man/man3/Test::Object.3pm
Appending installation info to /usr/local/lib/perl/5.18.2/perllocal.pod
  ADAMK/Test-Object-0.07.tar.gz
  /usr/bin/make install  -- OK
Running install for module 'Test::SubCalls'
Running make for A/AD/ADAMK/Test-SubCalls-1.09.tar.gz
Fetching with LWP:
http://cpan.mirror.anlx.net/authors/id/A/AD/ADAMK/Test-SubCalls-1.09.tar.gz
Checksum for 
/root/.local/share/.cpan/sources/authors/id/A/AD/ADAMK/Test-SubCalls-1.09.tar.gz
 ok

  CPAN.pm: Building A/AD/ADAMK/Test-SubCalls-1.09.tar.gz

Checking if your kit is complete...
Looks good
Warning: prerequisite Hook::LexWrap 0.20 not found.
Writing Makefile for Test::SubCalls
Writing MYMETA.yml and MYMETA.json
 Unsatisfied dependencies detected during 
  ADAMK/Test-SubCalls-1.09.tar.gz 
Hook::LexWrap [requires]
Running make test
  Delayed until after prerequisites
Running make install
  Delayed until after prerequisites
Running install for module 'Hook::LexWrap'
Running make for C/CH/CHORNY/Hook-LexWrap-0.24.tar.gz
Fetching with LWP:
http://cpan.mirror.anlx.net/authors/id/C/CH/CHORNY/Hook-LexWrap-0.24.tar.gz
Checksum for 
/root/.local/share/.cpan/sources/authors/id/C/CH/CHORNY/Hook-LexWrap-0.24.tar.gz
 ok
CPAN: Module:

Re: Appeal for testing: Marpa-R2 2.087_002 on MS Windows

[Durand Jean-Damien]

I meant "nmake/cl" box.

Le jeudi 10 juillet 2014 20:12:04 UTC+2, Durand Jean-Damien a écrit :
>
> Ok on windows7/perl-5.18/gcc/dmake.
> Anybody with a name/cl box ? Otherwise ActiveState will do it.
> JD.
>
> Le jeudi 10 juillet 2014 17:59:48 UTC+2, Jeffrey Kegler a écrit :
>>
>> Re Marpa-R2 2.087_002:  It's a release candidate, and at this point, 
>> I've gotten lots of testing, with 100% "OK" results.  But one issue 
>> bothers me. 
>>
>> None of those tests are on MS Windows.  This release *does* heavily 
>> refactor the build logic, and Win32 is a very different build 
>> environment from the others.  I'd really like to see some Win32 testing 
>> before I do the indexed release. 
>>
>> Anyone able to help out, it's greatly appreciated. 
>>
>> -- jeffrey 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Appeal for testing: Marpa-R2 2.087_002 on MS Windows

[Durand Jean-Damien]

Ok on windows7/perl-5.18/gcc/dmake.
Anybody with a name/cl box ? Otherwise ActiveState will do it.
JD.

Le jeudi 10 juillet 2014 17:59:48 UTC+2, Jeffrey Kegler a écrit :
>
> Re Marpa-R2 2.087_002:  It's a release candidate, and at this point, 
> I've gotten lots of testing, with 100% "OK" results.  But one issue 
> bothers me. 
>
> None of those tests are on MS Windows.  This release *does* heavily 
> refactor the build logic, and Win32 is a very different build 
> environment from the others.  I'd really like to see some Win32 testing 
> before I do the indexed release. 
>
> Anyone able to help out, it's greatly appreciated. 
>
> -- jeffrey 
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Conditional event triggering

[Durand Jean-Damien]

You might find the few util methods in this link 

 
useful -;

Le jeudi 26 juin 2014 14:50:12 UTC+2, Ion Toloaca a écrit :
>
> One last question and I suppose the problem will be solved.
>
> Can I also access the location where the rule got matched within the 
> action? 
> When using events I used something along the lines:
> /
> my $pos = $recce->read( \"$input", $start, $length - $start );
> ..
> my ($start_rule, $length_rule) = $recce->last_completed($name);
> my $last_expression = $recce->substring($start_rule, $length_rule);
> push @$actual_events, [$pos - length($last_expression) +1,$pos+1, $_]; 
> #Marpa counted unicode symbol length incorrectly - so that's a work 
> around
> ...
> eval {$pos = $recce->resume(); };
> /
> This way I found the positions where the notations/arguments matched  - 
> can I rewrite this using actions?
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Compiling a list of Perl modules using Marpa

[Durand Jean-Damien]

Based on Toby's post 
,
 
results to be confirmed -;

App-datecalc 0.03 (SHARYANTO) - Date calculator
Catmandu 0.9204 (NICS) - a data toolkit
Catmandu-Activiti 0.11 (NJFRANCK) - Catmandu module for Activiti
Catmandu-AlephX 1.065 (NJFRANCK) - Low level api for Aleph X Services
Catmandu-ArXiv 0.01 (NICS) - Catmandu modules for working with ArXiv data.
Catmandu-Atom 0.02 (NICS) - modules for working with Atom feeds
Catmandu-BibTeX 0.04 (NICS) - Catmandu modules for working with BibTeX data
Catmandu-Cmd-repl 0.01 (NICS) - interactive shell for Catmandu
Catmandu-CrossRef 0.001 (VPEIL) - makes something
Catmandu-DOI 0.01 (NICS) - Catmandu modules for working with DOI data.
Catmandu-EuropePMC 0.13 (VPEIL) - A bundle of Catmandu modules for working 
with data from EuropePMC
Catmandu-Exporter-Template 0.05 (VPEIL) - a TT2 Template exporter in 
Catmandu style
Catmandu-FedoraCommons 0.271 (HOCHSTEN) - Low level Catmandu interface to 
the Fedora Commons REST API
Catmandu-Fix-Date 0.0121 (NJFRANCK) - Catmandu fix modules for parsing dates
Catmandu-Fix-XML 0.1 (NJFRANCK) - Catmandu fix modules for processing xml
Catmandu-Fix-cmd 0.0201 (NICS) - pipe data to be fixed through an external 
process
Catmandu-Importer-DBI 0.03 (HOCHSTEN) - Catmandu module to import data from 
any DBI source
Catmandu-Importer-MODS 0.1 (NJFRANCK) - Catmandu importer for mods records 
in xml or json
Catmandu-Importer-Purr 0.02 (HOCHSTEN) - Perl Utility for Recent Releases
Catmandu-Importer-getJSON 0.40 (VOJ) - Load JSON-encoded data from a server 
using a GET HTTP request
Catmandu-Inspire 0.262 (VPEIL) - Catmandu modules for working with Inspire 
data.
Catmandu-LDAP 0.0103 (NICS) - Catmandu modules for working with LDAP 
directories
Catmandu-MAB2 0.07 (JOROL) - Catmandu modules for working with MAB2 data.
Catmandu-MARC 0.204 (HOCHSTEN) - Catmandu modules for working with MARC data
Catmandu-MediaMosa 0.279 (NJFRANCK) - Package that imports MediaMosa asset 
information into your application
Catmandu-OAI 0.04 (HOCHSTEN) - Catmandu modules for working with OAI 
repositories
Catmandu-OCLC 0.005 (HOCHSTEN) - Catmandu modules for working with OCLC web 
services
Catmandu-PICA 0.09 (VOJ) - Catmandu modules for working with PICA+ data.
Catmandu-PLoS 0.01 (NICS) - Catmandu module for working with PLoS data
Catmandu-PubMed 0.01 (NICS) - Catmandu module for working with PubMed data
Catmandu-RDF 0.14 (VOJ) - Modules for handling RDF data within the Catmandu 
framework
Catmandu-SRU 0.036 (HOCHSTEN) - Catmandu module for working with SRU data
Catmandu-Serializer-messagepack 0.0101 (NICS) - A Catmandu::Serializer 
backend using Data::MessagePack
Catmandu-Serializer-storable 0.0102 (NICS) - A Catmandu::Serializer backend 
using Storable
Catmandu-Store-CouchDB 0.01 (NICS) - A searchable store backed by CouchDB
Catmandu-Store-DBI 0.04 (NICS) - A Catmandu::Store plugin for DBI based 
interfaces
Catmandu-Store-ElasticSearch 0.0206 (NICS) - A searchable store backed by 
Elasticsearch
Catmandu-Store-Lucy 0.0101 (NICS) - A searchable store backed by Lucy
Catmandu-Store-MongoDB 0.0302 (NICS) - A searchable store backed by MongoDB
Catmandu-Store-Solr 0.0204 (NICS) - A searchable store backed by Solr
Catmandu-Twitter 0.03 (HOCHSTEN) - Package that imports Twitter feeds
Catmandu-Wikidata 0.05 (VOJ) - Import from Wikidata for processing with 
Catmandu
Catmandu-XLS 0.03 (NICS) - modules for working with Excel .xls files
Catmandu-Z3950 0.04 (NICS) - Catmandu module for working with Z3950 data
Dancer-Plugin-Catmandu-OAI 0.0305 (NICS) - OAI-PMH provider backed by a 
searchable Catmandu::Store
Dancer-Plugin-Catmandu-SRU 0.03 (NICS) - SRU server backed by a searchable 
Catmandu::Store
Dancer-Session-Catmandu 0.02 (NICS) - Dancer session store backed by a 
Catmandu::Store
Grammar-Marpa 2.000 (PWBENNETT) - Overload wrapper around 
Marpa::R2::Scanless
Graph-Easy-Marpa 2.01 (RSAVAGE) - A Marpa-based parser for 
Graph::Easy-style Graphviz files
GraphViz2-Marpa 1.11 (RSAVAGE) - A Perl lexer and parser for Graphviz dot 
files
GraphViz2-Marpa-PathUtils 1.04 (RSAVAGE) - Provide various analyses of 
Graphviz dot files
MarpaX-Database-Terminfo 0.010 (JDDPAUSE) - Terminfo interface
MarpaX-Demo-JSONParser 1.03 (RSAVAGE) - A JSON parser with a choice of 
grammars
MarpaX-Demo-StringParser 1.05 (RSAVAGE) - Conditional preservation of 
whitespace while parsing
MarpaX-Grammar-Parser 1.01 (RSAVAGE) - Converts a Marpa grammar into a tree 
using Tree::DAG_Node
MarpaX-Languages-C-AST 0.37 (JDDPAUSE) - Translate a C source to an AST
MarpaX-Languages-ECMAScript-AST 0.015 (JDDPAUSE) - Translate a ECMAScript 
source to an AST
MarpaX-Languages-SVG-Parser 1.04 (RSAVAGE) - An SVG parser
MarpaX-Repa 0.10 (RUZ) - helps start with Marpa
MarpaX-Simple 0.03 (SHARYANTO) - Generate Marpa-based parser
MarpaX-xPathLike 0.203 (JVVERDE) - a xPath like processor for perl 
data-structures (hashes and arrays)!
Plack-Session-Store-Catma

Re: I may be teaching my colleagues Marpa

[Durand Jean-Damien]

Each line has a different rule Id. That's why A is, well must be, a symbol 
and not a rule.

I.e. this grammar consist of three symbols:
A, B, H

and three rules:
A ::= B
A ::= H
A ::=

The fact that H is "hello!" is irrelevant from pure grammar point of view -;

JD.

Le mercredi 18 juin 2014 21:49:08 UTC+2, Paul Bennett a écrit :
>
> On Wed, Jun 18, 2014 at 12:01 PM, Jeffrey Kegler 
> > A ::= B 
> > A ::= 'hello!' 
> > A ::= # empty 
>
> Point not taken. Point, in fact, blew my mind. More research is required. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: I may be teaching my colleagues Marpa

[Durand Jean-Damien]

Even if it not for the SLIF user, I tend to say that looking to the libmarpa 
API documentation 
 
is really worth doing it: it is pedagogic and expresses clearly the types 
(symbols and rules are explicitely different calls producing different 
types), and the architectures (grammar, recognizer, progress, bocage, 
etc...) - reading it helped to understand some design decisions for the 
SLIF.
JD.

Le mercredi 18 juin 2014 18:02:31 UTC+2, Jeffrey Kegler a écrit :
>
> Also on slide 2: The LHS of a production is not really its name, it's a 
> symbol.  That is, "A ::= B" says that symbol A derives (or produces or 
> can be rewritten to) symbol B.  "A" is sometimes used to "name" the 
> rule, to be sure, but it's dangerous to think of it as the rule's name.   
> One reason it is dangerous is that several rules can have the same LHS: 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Finding a parse inside a (potentially long) string?

[Durand Jean-Damien]

Definitely -;

Btw there is a full regexp engine writen with Marpa (well, the JavaScript 
one, wich differs from perl with quite subtile things 
)
 
here 

.

JD.

Le lundi 9 juin 2014 19:50:47 UTC+2, Jeffrey Kegler a écrit :
>
>  By the way, another target of opportunity is a regex engine which detects 
> "hard" and "easy" regexes.  Most regexes it would handle in the ordinary 
> way, with a regex engine, but the hard ones it hands over to Marpa.  This 
> might prove popular because people *want* to do everything with a regex.  
> This would allow them to.  It'd make a great Perl extension.
>
> -- jeffrey
>
> 

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Marpa::R2 being officially packaged by Debian

[Durand Jean-Damien]

Jeffrey,
I was reading the debian build-log on the s390 architecture 
<https://buildd.debian.org/status/fetch.php?pkg=libmarpa-r2-perl&arch=s390x&ver=2.084000~dfsg-1&stamp=1401473766>
 
- puzzling -; gcc complains about truncations and there are strange 
segfaults.
Original report is here 
<http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/2014-June/077947.html>
.
JD.

Le lundi 2 juin 2014 23:57:45 UTC+2, Durand Jean-Damien a écrit :
>
> FYI the Debian-Perl group has taken over packaging of Marpa::R2, c.f. their 
> repository 
> <http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libmarpa-r2-perl.git;a=summary>
>  
> that is adressing the (debian naming for such thing) this Package Request 
> Bug Report <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748484>.
>
> This mean that Marpa::R2, when their package will be ok (I refer to this 
> mail 
> <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/2014-June/077945.html>
>  
> for example) will hit a miriad of computer on various architectures via 
> various distributions (Ubuntu in particular).
>
> Very good news -;
>
> JD.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Marpa::R2 being officially packaged by Debian

[Durand Jean-Damien]

FYI the Debian-Perl group has taken over packaging of Marpa::R2, c.f. their 
repository 

 
that is adressing the (debian naming for such thing) this Package Request 
Bug Report .

This mean that Marpa::R2, when their package will be ok (I refer to this 
mail 

 
for example) will hit a miriad of computer on various architectures via 
various distributions (Ubuntu in particular).

Very good news -;

JD.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Declaring dependencies on core modules

[Durand Jean-Damien]

Self-adaption from Dist::Zilla method applied to Marpa in attachment.

Usage: /usr/bin/perl /home/jdurand/Documents/scanprereqs.pl path1 [... 
[pathn]]

Example: /usr/bin/perl /home/jdurand/Documents/scanprereqs.pl 
~/git/Marpa--R2/cpan

Output:

$VAR1 = {
  'URI::URL' => '0',
  'XSLoader' => '0',
  'File::Spec::Functions' => '0',
  'CPAN::Version' => '0',
  'autodie' => '0',
  'Fatal' => '0',
  'overload' => '0',
  'CPAN' => '0',
  'HTML::Entities' => '0',
  'charnames' => '0',
  'List::Util' => '0',
  'CPAN::Meta' => '0',
  'Data::Dumper' => '0',
  'Test::More' => '0.94',
  'WWW::Mechanize' => '0',
  'Pod::Simple' => '0',
  'feature' => '0',
  'File::Copy' => '0',
  'warnings' => '0',
  'Perl::Tidy' => '0',
  'perl' => '5.010',
  'sort' => '0',
  'Test::CPAN::Meta' => '0',
  'HTML::Parser' => '3.69',
  'HTML::LinkExtor' => '0',
  'ExtUtils::Mkbootstrap' => '0',
  'ExtUtils::Manifest' => '0',
  'Text::Wrap' => '0',
  'base' => '0',
  'Module::Build' => '0',
  'Time::Piece' => '0',
  'PPI' => '0',
  'Test::Pod' => '0',
  'YAML::XS' => '0',
  'IPC::Cmd' => '0',
  'vars' => '0',
  'Getopt::Long' => '0',
  'Module::Load' => '0',
  'Perl::Critic' => '0',
  'Carp' => '0',
  'Test::Perl::Critic' => '0',
  'Cwd' => '0',
  'lib' => '0',
  'File::Path' => '0',
  'POSIX' => '0',
  'File::Spec' => '0.82',
  'Text::Diff' => '0',
  'English' => '0',
  'utf8' => '0',
  'constant' => '0',
  'Scalar::Util' => '0',
  'Exporter' => '0',
  'DynaLoader' => '0',
  'LWP::UserAgent' => '0',
  'open' => '0',
  'File::Temp' => '0',
  'File::Slurp' => '0',
  'GetOpt::Long' => '0',
  'strict' => '0'
};

JD.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
#!env perl
#
# Inspired by Dist::Zilla::Plugin::AutoPrereqs.pm
#
use strict;
use diagnostics;
use List::AllUtils 'uniq';
use Perl::PrereqScanner 1.016; # don't skip "lib"
use PPI;
use CPAN::Meta::Requirements;
use version;
use File::Find;
use File::Basename;
use File::Slurp;
use Data::Dumper;
use POSIX qw/EXIT_SUCCESS/;
use File::Spec;
use IO::Handle;

autoflush STDOUT 1;

if (! @ARGV) {
print STDERR "Usage: $^X $0 path1 [... [pathn]]\n";
print STDERR "\n";
print STDERR "Example: $^X $0 ~/git/Marpa--R2/cpan\n";
exit(EXIT_SUCCESS);
}

our @sets = (
[ configure => 'found_configure_files' ], # must come before runtime
[ runtime => 'found_files'  ],
[ test=> 'found_test_files' ],
  );

my @modules;
my $scanner = Perl::PrereqScanner->new();
my $req = CPAN::Meta::Requirements->new;

find({ wanted => \&wanted, no_chdir => 1 }, @ARGV);

# remove prereqs shipped with current dist
$req->clear_requirement($_) for @modules;
$req->clear_requirement($_) for qw(Config Errno); # never indexed
# we're done, return what we've found
my %got = %{ $req->as_string_hash };
my %without_Marpa = map {$_ => $got{$_}} grep {! /\bMarpa\b/} keys %got;
print Dumper(\%without_Marpa);
exit(EXIT_SUCCESS);

sub wanted {
my $filename = File::Spec->canonpath($_);

return if (! -f $filename);

my $content = read_file($filename);

# parse only perl files
return unless ($filename =~ /\.(?:pm|pl|t|psgi)$/i
		   || $content =~ /^#!(?:.*)perl(?:$|\s)/);
# RT#76305 skip extra tests produced by ExtraTests plugin
return if $filename =~ m{^t/(?:author|release)-[^/]*\.t$};

print "Scanning $filename\n";

# store module name, to trim it from require list later on
my @this_thing = $filename;
if ($this_thing[0] =~ /^t/) {
push @this_thing, ($this_thing[0]) x 2;
$this_thing[1] =~ s{^t/}{};
$this_thing[2] =~ s{^t/lib/}{};
} else {
$this_thing[0] =~ s{^lib/}{};
}
@this_thing = uniq @this_thing;
s{\.pm$}{} for @this_thing;
s{/}{::}g for @this_thing;
push @modules, @this_thing;

# parse a file, and merge with existing prereqs
my $file_req = $scanner->scan_string($content);
$req->add_requirements($file_req);
}

Re: Unicode characters counted as multiple characters

[Durand Jean-Damien]

I forgot the output!

$VAR1 = \[
[
  "\x{2260}"
]
  ];
≠: OK, pos=1

Correct isn't it -; May I suggest you do a Data::Dumper as well, I am 
pretty sure you think unicode while it is not.

Jean-Damien.

Le vendredi 23 mai 2014 20:50:07 UTC+2, Durand Jean-Damien a écrit :
>
> AFAIK Marpa should be ok with unicode, c.f. advent calendar that is 
> somewhere in the test suite.
> C.f. attachment that replays your example.
> Jean-Damien.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unicode characters counted as multiple characters

[Durand Jean-Damien]

AFAIK Marpa should be ok with unicode, c.f. advent calendar that is 
somewhere in the test suite.
C.f. attachment that replays your example.
Jean-Damien.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
#!env perl
use strict;
use warnings FATAL => 'all';
use Marpa::R2;
use Data::Section -setup;
use open ':std', ':encoding(utf8)';
use Data::Dumper;

our $DATA = __PACKAGE__->local_section_data;

# Grammar and test suite are in __DATA__
# --
my $grammar = Marpa::R2::Scanless::G->new( { source => $DATA->{grammar_source } });
my @tests = grep {"$_"} split(/\n/, ${$DATA->{tests}});

map {printf "%-40s : %s\n", $_, play($grammar, $_)} @tests;

###

sub play {
my ($grammar, $input) = @_;

my $recognizer = Marpa::R2::Scanless::R->new({grammar => $grammar});
my $length  = length($input);

my %played = ();
#
# 1: Parse
#
my $pos = eval {$recognizer->read(\$input)} || do {return $@};
my $value = $recognizer->value();
print STDERR Dumper($value);
return ($value ? 'OK' : 'KO') . ", pos=$pos";
}

__DATA__
__[ grammar_source ]__
:start ::= Start
:default ::= action => [values]
Start ::= Rule1 
Rule1 ::= '≠'
event 'Start' = completed Start
__[ tests ]__
≠

Re: Request for discussion: Lexeme priority revisited

[Durand Jean-Damien]

Not saying this is my preference, but since you want to type the priority, 
another possibility is to have another keyword that is doing so  e.g.:

> :lexeme ~  priority => 1 scope => xxx

where xxx = latm, or xxx = longests is the default, saying the scope is on 
the longests tokens only.
xxx => all mean that the scope is on all lexemes.

Just an idea.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Artilce sur la gestion de fortune , Artilce on asset management

[Durand Jean-Damien]

You sent spam to this list.
Please check your account ASAP or I propose the maintainer of the list to 
remove your email from this list.
Regards.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A Totally Clueless Newbie Tilting At Windmills

[Durand Jean-Damien]

Beging a noob with COBOL I just wanna know if the language is perfectly 
standardized, or if programmers in it are tempted to use extensions that 
makes a general parser more difficult, like with C code using GNUCC only 
extensions.
Side-effect of my question, is the COBOL source code you are targetting 
subject to some extensions, or is it writen if perfect (ANSI ?) COBOL.
Thanks,

Btw I found this link 
interesting.

>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: t/thin_eq.t ambiguous grammar test rewriten in C

[Durand Jean-Damien]

Oups - fixed. Current version is fine with me.
Ok to include it in the libmarpa package, or would you like to get that 
into your repo.
Same question for eventual pedagogic applications, based a priori on what 
is doing t/thin_eq.t.
Thanks, JD.

Le dimanche 20 avril 2014 19:51:07 UTC+2, Jeffrey Kegler a écrit :
>
>  It looks really good.   I think it'd be good to add checking of the error 
> codes from all the Marpa methods.  Also I notice the x86 executable is in 
> the examples directory.  -- jeffrey
>
> On 04/20/2014 10:30 AM, Durand Jean-Damien wrote:
>  
> C.f. https://github.com/jddurand/libmarpa-packaging/tree/master/examples
>
> for uptodate (and eventually fixed or better) version(s).
>
> Jean-Damien.
>
> Le dimanche 20 avril 2014 17:20:45 UTC+2, Durand Jean-Damien a écrit : 
>>
>> The list might be interested to see a C version of what is writen in perl 
>> using the Thin interface.
>> This is the first test that is in t/thin_eq.t, doing this ambiguous 
>> grammar:
>>
>>   :start ::= S
>>   S ::= E
>>   E ::= E op E
>>   E ::= number
>>
>>   applied on tokens "2", "-", "0", "*", "3", "+", "1".
>>
>>   Result is:
>>
>> Expected result (((2-0)*3)+1) == 7, value 7
>> Expected result ((2-(0*3))+1) == 3, value 3
>> Expected result (2-((0*3)+1)) == 1, value 1
>> Expected result (2-(0*(3+1))) == 2, value 2
>> Expected result ((2-0)*(3+1)) == 8, value 8
>>
>> Source files in attachment.
>>
>> May I ask somebody to review it, because I plan to submit it to git for 
>> inclusion in debian packages -;
>> valgrind on it is happy v.s. eventual lekage btw.
>>
>> Thanks, Jean-Damien.
>>
>>   -- 
> You received this message because you are subscribed to the Google Groups 
> "marpa parser" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to marpa-parser...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
> 

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: t/thin_eq.t ambiguous grammar test rewriten in C

[Durand Jean-Damien]

C.f. https://github.com/jddurand/libmarpa-packaging/tree/master/examples

for uptodate (and eventually fixed or better) version(s).

Jean-Damien.

Le dimanche 20 avril 2014 17:20:45 UTC+2, Durand Jean-Damien a écrit :
>
> The list might be interested to see a C version of what is writen in perl 
> using the Thin interface.
> This is the first test that is in t/thin_eq.t, doing this ambiguous 
> grammar:
>
>   :start ::= S
>   S ::= E
>   E ::= E op E
>   E ::= number
>
>   applied on tokens "2", "-", "0", "*", "3", "+", "1".
>
>   Result is:
>
> Expected result (((2-0)*3)+1) == 7, value 7
> Expected result ((2-(0*3))+1) == 3, value 3
> Expected result (2-((0*3)+1)) == 1, value 1
> Expected result (2-(0*(3+1))) == 2, value 2
> Expected result ((2-0)*(3+1)) == 8, value 8
>
> Source files in attachment.
>
> May I ask somebody to review it, because I plan to submit it to git for 
> inclusion in debian packages -;
> valgrind on it is happy v.s. eventual lekage btw.
>
> Thanks, Jean-Damien.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

t/thin_eq.t ambiguous grammar test rewriten in C

[Durand Jean-Damien]

The list might be interested to see a C version of what is writen in perl 
using the Thin interface.
This is the first test that is in t/thin_eq.t, doing this ambiguous grammar:

  :start ::= S
  S ::= E
  E ::= E op E
  E ::= number

  applied on tokens "2", "-", "0", "*", "3", "+", "1".

  Result is:

Expected result (((2-0)*3)+1) == 7, value 7
Expected result ((2-(0*3))+1) == 3, value 3
Expected result (2-((0*3)+1)) == 1, value 1
Expected result (2-(0*(3+1))) == 2, value 2
Expected result ((2-0)*(3+1)) == 8, value 8

Source files in attachment.

May I ask somebody to review it, because I plan to submit it to git for 
inclusion in debian packages -;
valgrind on it is happy v.s. eventual lekage btw.

Thanks, Jean-Damien.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
#include 
#include 
#include 
#include 
#include 
#include "thin_macros.h"

/*
  C version of first example in file t/thin_eq.t
  from Marpa::R2 CPAN distribution

  Grammar is:

  :start ::= S
  S ::= E
  E ::= E op E
  E ::= number

  Expected values:
  
  (2-(0*(3+1))) == 2 => 1
  (((2-0)*3)+1) == 7 => 1
  ((2-(0*3))+1) == 3 => 1
  ((2-0)*(3+1)) == 8 => 1
  (2-((0*3)+1)) == 1 => 1

  Compilation: cc -g -o ./thin ./thin.c -lmarpa
  Execution  : ./thin

*/

/* A stack here is composed of two elements, the string and a corresponding int */
typedef struct s_stack {
  char *string;
  int value;
} s_stack_;

static char *_make_str(const char *fmt, ...);
static void _check(Marpa_Error_Code errorCode, const char *call, int forcedCondition);
static void _push_to_stack(s_stack_ **stackpp, int *stacksizep, int index, char *string, int value);

struct marpa_error_description_s {
  Marpa_Error_Code error_code;
  const char*name;
  const char*suggested;
};
extern const struct marpa_error_description_s marpa_error_description[];

int main() {
  Marpa_Configmarpa_configuration;
  Marpa_Grammar   g;
  Marpa_Symbol_ID S, E, op, number;
  Marpa_Rule_ID   start_rule_id, op_rule_id, number_rule_id;
  Marpa_Recognizerr;
  char*token_values[] = { "0", "1", "2", "3", "0", "-", "+", "*" };
  s_stack_   expected_results[5] = {
{"(2-(0*(3+1))) == 2", 2},
{"(((2-0)*3)+1) == 7", 7},
{"((2-(0*3))+1) == 3", 3},
{"((2-0)*(3+1)) == 8", 8},
{"(2-((0*3)+1)) == 1", 1}
  };
  int ivalue = 0;
  Marpa_Earley_Set_ID latest_earley_set_ID;
  Marpa_Bocagebocage;
  Marpa_Order order;
  Marpa_Tree  tree;
  s_stack_*stackp = NULL;
  size_t  stacksize = -1;
  int zero = 4;  /* Indice 4 in token_values */
  int minus_token_value= 5;  /* Indice 5 in token_values */
  int plus_token_value = 6;  /* Indice 6 in token_values */
  int multiply_token_value = 7;  /* Indice 7 in token_values */

  /* Configuration initialisation */
  marpa_c_init(&marpa_configuration); /* never fails as per the doc */

  /* Grammar creation */
  g = marpa_g_new(&marpa_configuration);
  _check(marpa_c_error(&marpa_configuration, NULL), "marpa_g_new()", g == NULL);

  /* Symbols creation */
  CREATE_SYMBOL(S, g);
  CREATE_SYMBOL(E, g);
  CREATE_SYMBOL(op, g);
  CREATE_SYMBOL(number, g);

  /* ::start ::= S */
  SET_START_SYMBOL(S, g);

  /* Rules creation */
  {Marpa_Symbol_ID rhs[] = { E };CREATE_RULE(start_rule_id,  g, S, rhs, ARRAY_LENGTH(rhs));}
  {Marpa_Symbol_ID rhs[] = { E, op, E }; CREATE_RULE(op_rule_id, g, E, rhs, ARRAY_LENGTH(rhs));};
  {Marpa_Symbol_ID rhs[] = { number };   CREATE_RULE(number_rule_id, g, E, rhs, ARRAY_LENGTH(rhs));}

  PRECOMPUTE(g);

  r = marpa_r_new(g);
  if (r == NULL) {
fprintf(stderr, "marpa_r_new() failure\n");
exit(EXIT_FAILURE);
  }

  if (marpa_r_start_input(r) < 0) {
fprintf(stderr, "marpa_r_start_input() failure\n");
exit(EXIT_FAILURE);
  }

  /*
The numbers from 1 to 3 are themselves --
that is, they index their own token value.
Important: zero cannot be itself!
  */

  ALTERNATIVE(r, number, 2, 1);
  EARLEME_COMPLETE(r);
  ALTERNATIVE(r, op, minus_token_value, 1);
  EARLEME_COMPLETE(r);
  ALTERNATIVE(r, number, zero, 1);
  EARLEME_COMPLETE(r);
  ALTERNATIVE(r, op, multiply_token_value, 1);
  EARLEME_COMPLETE(r);
  ALTERNATIVE(r, number, 3, 1);
  EARLEME_COMPLETE(r);
  ALTERNATIVE(r, op, plus_token_value, 1);
  EARLEME_COMPLETE(r);
  ALTERNATIVE(r, number, 1, 1);
  EARLEME_COMPLETE(r);

  latest_earley_set_ID = marpa_r_latest_earley_set(r);

  bocage = marpa_b_new(r, latest_earley_set_ID);
  if (bocage == NULL) {
fprintf(stderr, "marpa_b_new() failure\n");
exit(EXIT_FAILURE);
  }

  order = marpa_o_new(bocage);
  if (order == NULL) {
fpr

Re: Libmarpa versioning

[Durand Jean-Damien]

This will endup in lib soname:

objdump -x ./.libs/libmarpa.so.0.0.0|grep SONAME
  SONAME   libmarpa.so.0


Le mercredi 16 avril 2014 06:56:43 UTC+2, Durand Jean-Damien a écrit :
>
> Fine with me / JD.
>
> Le mardi 15 avril 2014 23:09:21 UTC+2, Jeffrey Kegler a écrit :
>>
>> Libmarpa versioning will not be visible to most of Marpa's users. In 
>> particularly, if you use Libmarpa only through its Perl interfaces,   
>> you'll probably never notice it. 
>>
>> But for those thinking of using Marpa's C library, it may be 
>> significant, so I wanted to toss this out for comment and discussion.   
>> Jean-Damien has been creating shared libraries from Libmarpa, and 
>> currently they are not versioned -- they're all 0.0.0.  This is not 
>> adequate and forces me to decide on a versioning scheme.  Libmarpa's 
>> versioning is not tied to that of Marpa::R2 (although Marpa::R2 is very 
>> very fussy about which version of Libmarpa it is using.) 
>>
>> At this point I intend to use a scheme currently in use mainly for 
>> security libraries, where the version is of the form MAJOR.MINOR.MICRO, 
>> but MINOR and MICRO are always zero.  This makes every change a major 
>> version change, which means that in most environments no version will be 
>> treated as compatible with any other.  In Marpa's case the reason for 
>> this ultra-cautious style is that development is aggressive, but the 
>> software is extremely complex and interactions are complex.  An upgrade 
>> discipline that simply "drops in" changes seems to me over-aggressive in 
>> this context.  I'll admit I am inclined, if I must err, to do so on the 
>> cautious side. 
>>
>> My current inclination is that the next Libmarpa version will be 3.0.0 
>> and all subsequent ones will be of the form MAJOR.0.0.  (Note that this 
>> three (3) has nothing to do with any plans for a Marpa::R3). 
>>
>> Your comments, advice, etc., are welcome. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Libmarpa versioning

[Durand Jean-Damien]

Fine with me / JD.

Le mardi 15 avril 2014 23:09:21 UTC+2, Jeffrey Kegler a écrit :
>
> Libmarpa versioning will not be visible to most of Marpa's users. In 
> particularly, if you use Libmarpa only through its Perl interfaces,   
> you'll probably never notice it. 
>
> But for those thinking of using Marpa's C library, it may be 
> significant, so I wanted to toss this out for comment and discussion.   
> Jean-Damien has been creating shared libraries from Libmarpa, and 
> currently they are not versioned -- they're all 0.0.0.  This is not 
> adequate and forces me to decide on a versioning scheme.  Libmarpa's 
> versioning is not tied to that of Marpa::R2 (although Marpa::R2 is very 
> very fussy about which version of Libmarpa it is using.) 
>
> At this point I intend to use a scheme currently in use mainly for 
> security libraries, where the version is of the form MAJOR.MINOR.MICRO, 
> but MINOR and MICRO are always zero.  This makes every change a major 
> version change, which means that in most environments no version will be 
> treated as compatible with any other.  In Marpa's case the reason for 
> this ultra-cautious style is that development is aggressive, but the 
> software is extremely complex and interactions are complex.  An upgrade 
> discipline that simply "drops in" changes seems to me over-aggressive in 
> this context.  I'll admit I am inclined, if I must err, to do so on the 
> cautious side. 
>
> My current inclination is that the next Libmarpa version will be 3.0.0 
> and all subsequent ones will be of the form MAJOR.0.0.  (Note that this 
> three (3) has nothing to do with any plans for a Marpa::R3). 
>
> Your comments, advice, etc., are welcome. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Compile fails because of long long int

[Durand Jean-Damien]

I may have access to a windows 32 bit platform with MSVS's cl - will check.

Le jeudi 13 mars 2014 04:04:16 UTC+1, Jeffrey Kegler a écrit :
>
>  The obvious solution is to add, as backup if there is no "unsigned long 
> long int" at configure time, a search for the uint64_t type, which C99 
> requires and many other compilers support.  But I was wondering if there 
> was any knowledge about the particular situation in the linked-to problem 
> report.  If I did it now it would be a shot in the dark -- for all I know 
> it may not support either, in which case I've complicated my build without 
> necessarily adding a single new platform, present or future, to the list of 
> those supported.
>
> -- jeffrey
>
>  On 03/12/2014 02:19 PM, Durand Jean-Damien wrote:
>  
> Hmmm... would you mind to assume a C99 compatible compiler ? Then there is 
> int64_t, which IMHO is better than long long int, if your concern is the 
> storage size. 
>
>  JD.
>
> Le mercredi 12 mars 2014 20:58:31 UTC+1, Jeffrey Kegler a écrit : 
>>
>>  From Activestate's site, I get this report of a Microsoft compile 
>> failure<http://ppm4.activestate.com/MSWin32-x86/5.12/1200/J/JK/JKEGL/Marpa-R2-2.082000.d/log-20140311T220808.txt>because
>>  I require "long long int".  My questions, for those more attuned to 
>> the world of Microsoft than I, are
>>
>> 1.)  Should I care?  That is, does it look like the setup is broken, or 
>> does it seem so oddball that I should ignore it?
>>
>> 2.)  If I should care, what's a good workaround?.  "long long int" is 
>> used to ensure that the int is at least 64-bits.  There are other ways to 
>> do that, none 100% portable.  I'd assume there is some way that this 
>> compiler likes to be asked for a 64-bit int.
>>
>> Thanks, jeffrey
>>  
>  -- 
> You received this message because you are subscribed to the Google Groups 
> "marpa parser" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to marpa-parser...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
> 

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Compile fails because of long long int

[Durand Jean-Damien]

Hmmm... would you mind to assume a C99 compatible compiler ? Then there is 
int64_t, which IMHO is better than long long int, if your concern is the 
storage size.

JD.

Le mercredi 12 mars 2014 20:58:31 UTC+1, Jeffrey Kegler a écrit :
>
>  From Activestate's site, I get this report of a Microsoft compile 
> failurebecause
>  I require "long long int".  My questions, for those more attuned to 
> the world of Microsoft than I, are
>
> 1.)  Should I care?  That is, does it look like the setup is broken, or 
> does it seem so oddball that I should ignore it?
>
> 2.)  If I should care, what's a good workaround?.  "long long int" is used 
> to ensure that the int is at least 64-bits.  There are other ways to do 
> that, none 100% portable.  I'd assume there is some way that this compiler 
> likes to be asked for a 64-bit int.
>
> Thanks, jeffrey
>  

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New blog post: "Evolvable languages"

[Durand Jean-Damien]

Nice post -; !

Le mardi 11 mars 2014 19:09:46 UTC+1, Jeffrey Kegler a écrit :
>
>  I have a new blog 
> postup:
>  "Language design has been like shooting crap in a casino that sets you 
> up to win a lot of the first rolls before the laws of probability grind you 
> down." 
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: cscan on Go lang C code

[Durand Jean-Damien]

FYI bug identified in c2ast and fixed with release 0.37, just uploaded.
JD.

Le mercredi 5 mars 2014 21:34:43 UTC+1, Durand Jean-Damien a écrit :
>
> Sorry for the noise, I just want to comment that there are some c2ast 
> failures, and I will have to:
> * check with a previous version of Marpa::R2 in case this would be a 
> regression
> * check c2ast itself
> Few files are in failure, but hey, there should be 100% success parsing C.
>
> Le mercredi 5 mars 2014 20:55:49 UTC+1, Durand Jean-Damien a écrit :
>>
>> Btw, interesting. One of the files seems crafted I do not know how:
>>
>>  return defgetenv("GOROOT", /home/jdurand/Téléchargements/go);
>> --^
>>
>> and another one gives c2ast failure. This last case I will have to check. 
>> Could be a c2ast bug, to be confirmed.
>>
>>  d->name = d->uid = d->gid = d->muid = "";
>> -^
>>
>> JD.
>>
>> Le mercredi 5 mars 2014 20:34:45 UTC+1, rns a écrit :
>>>
>>> That's a great start! 
>>>
>>> As for the question, can't really help here, sorry, 
>>> golang-dev<https://groups.google.com/forum/#!forum/golang-dev> looks 
>>> like a good place to ask and/or report on the results.
>>>
>>> "We plan to translate the existing compilers from C to Go by writing and 
>>> then applying an automatic translator" — says Russ Cox in Go 1.3+ 
>>> Compiler 
>>> Overhaul<https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/edit>
>>>  — 
>>> looks like they may find C parsing features provided by 
>>> MarpaX::Languages::C::AST useful.
>>>
>>>
>>>
>>>
>>> On Wed, Mar 5, 2014 at 9:13 PM, Durand Jean-Damien <
>>> jeandami...@gmail.com> wrote:
>>>
>>>> Is there a way to know how GO bootstraps its library, I mean starting 
>>>> at:
>>>>
>>>> ./cmd/dist/dist bootstrap $buildall $GO_DISTFLAGS -v # builds 
>>>> go_bootstrap
>>>> # Delay move of dist tool to now, because bootstrap may clear tool 
>>>> directory.
>>>> mv cmd/dist/dist "$GOTOOLDIR"/dist
>>>> "$GOTOOLDIR"/go_bootstrap clean -i std
>>>> echo
>>>>
>>>> if [ "$GOHOSTARCH" != "$GOARCH" -o "$GOHOSTOS" != "$GOOS" ]; then
>>>> echo "# Building packages and commands for host, $GOHOSTOS/$GOHOSTARCH."
>>>>  GOOS=$GOHOSTOS GOARCH=$GOHOSTARCH \
>>>> "$GOTOOLDIR"/go_bootstrap install -ccflags "$GO_CCFLAGS" -gcflags 
>>>> "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std
>>>>  echo
>>>> fi
>>>>
>>>> echo "# Building packages and commands for $GOOS/$GOARCH."
>>>> "$GOTOOLDIR"/go_bootstrap install $GO_FLAGS -ccflags "$GO_CCFLAGS" 
>>>> -gcflags "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std
>>>> echo
>>>>
>>>> rm -f "$GOTOOLDIR"/go_bootstrap
>>>>
>>>> if [ "$1" != "--no-banner" ]; then
>>>> "$GOTOOLDIR"/dist banner
>>>> fi
>>>>
>>>> I see ccflags etc... but I mean: can you confirm or give me a way to 
>>>> know what are exactly all the c flags in action.
>>>> The first step, creating the bootstrap was easy. But bootstrap is a bit 
>>>> obscure.
>>>> Oterwise c2ast did not suffer from analysing GO bootstrap code -;
>>>>
>>>> Ah, result of the 1st step (i.e. the one that generates the bootstrap) 
>>>> is:
>>>>
>>>> cmd/dist/buf.c(218) strpcmp: Names beginning with 'str', 'mem', or 
>>>> 'wcs' followed by a lowercase letter are reserved for additional string 
>>>> and 
>>>> array functions
>>>> cmd/dist/build.c(25)  tooldir: Names that begin with either 'is' or 
>>>> 'to' followed by a lowercase letter may be used for additional character 
>>>> testing and conversion functions.
>>>> cmd/dist/build.c(612) islib: Names that begin with either 'is' or 
>>>> 'to' followed by a lowercase letter may be used for additional character 
>>>> testing and conversion functions.
>>>> cmd/dist/build.c(612) ispkg: Names that begin with either 'is' or 
>>>>

Re: 31 of many topics (1 unread)

[Durand Jean-Damien]

Got it as well several times, a bug in the reader IMHO.
I clicked on "Mark all as read" -;

Le jeudi 6 mars 2014 05:03:08 UTC+1, Ron Savage a écrit :
>
> I keep getting the msg about (1 unread), but there is no indication of 
> which message it is. Any ideas?
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: cscan on Go lang C code

[Durand Jean-Damien]

 top: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.
src/cmd/gc/typecheck.c(32)  stringtoarraylit: Names beginning with 
'str', 'mem', or 'wcs' followed by a lowercase letter are reserved for 
additional string and array functions
src/cmd/gc/typecheck.c(59)  top: Names that begin with either 'is' or 
'to' followed by a lowercase letter may be used for additional character 
testing and conversion functions.
src/cmd/gc/typecheck.c(140) top: Names that begin with either 'is' or 
'to' followed by a lowercase letter may be used for additional character 
testing and conversion functions.
src/cmd/gc/typecheck.c(305) top: Names that begin with either 'is' or 
'to' followed by a lowercase letter may be used for additional character 
testing and conversion functions.
src/cmd/gc/typecheck.c(2123)isddd: Names that begin with either 'is' or 
'to' followed by a lowercase letter may be used for additional character 
testing and conversion functions.
src/cmd/gc/typecheck.c(2378)iscomptype: Names that begin with either 
'is' or 'to' followed by a lowercase letter may be used for additional 
character testing and conversion functions.
src/cmd/gc/typecheck.c(2644)islvalue: Names that begin with either 'is' 
or 'to' followed by a lowercase letter may be used for additional character 
testing and conversion functions.
src/cmd/gc/typecheck.c(2875)stringtoarraylit: Names beginning with 
'str', 'mem', or 'wcs' followed by a lowercase letter are reserved for 
additional string and array functions
src/cmd/gc/typecheck.c(3322)isterminating: Names that begin with either 
'is' or 'to' followed by a lowercase letter may be used for additional 
character testing and conversion functions.
src/cmd/gc/typecheck.c(3322)top: Names that begin with either 'is' or 
'to' followed by a lowercase letter may be used for additional character 
testing and conversion functions.
src/cmd/gc/walk.c(1620)isddd: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.
src/cmd/gc/walk.c(2128)memwrite: Names beginning with 'str', 'mem', or 
'wcs' followed by a lowercase letter are reserved for additional string and 
array functions
src/cmd/8l/../ld/data.c(670) strnput: Names beginning with 'str', 
'mem', or 'wcs' followed by a lowercase letter are reserved for additional 
string and array functions
src/cmd/8l/../ld/elf.c(16)  iself: Names that begin with either 'is' or 
'to' followed by a lowercase letter may be used for additional character 
testing and conversion functions.
src/cmd/8l/../ld/go.c(643) isz: Names that begin with either 'is' or 
'to' followed by a lowercase letter may be used for additional character 
testing and conversion functions.
src/cmd/8l/../ld/ldmacho.c(126) stroff: Names beginning with 'str', 
'mem', or 'wcs' followed by a lowercase letter are reserved for additional 
string and array functions
src/cmd/8l/../ld/ldmacho.c(127) strsize: Names beginning with 'str', 
'mem', or 'wcs' followed by a lowercase letter are reserved for additional 
string and array functions
src/cmd/8l/../ld/ldmacho.c(152) tocoff: Names that begin with either 
'is' or 'to' followed by a lowercase letter may be used for additional 
character testing and conversion functions.
src/cmd/8l/../ld/ldmacho.c(379) strbuf: Names beginning with 'str', 
'mem', or 'wcs' followed by a lowercase letter are reserved for additional 
string and array functions
src/cmd/8l/../ld/lib.c(580) isinternal: Names that begin with either 
'is' or 'to' followed by a lowercase letter may be used for additional 
character testing and conversion functions.
src/cmd/8l/../ld/lib.c()top: Names that begin with either 'is' or 
'to' followed by a lowercase letter may be used for additional character 
testing and conversion functions.
src/cmd/8l/span.c(564) istls: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.
src/cmd/8c/../cc/pswt.c(50)  isv: Names that begin with either 'is' or 
'to' followed by a lowercase letter may be used for additional character 
testing and conversion functions.
src/cmd/8c/swt.c(336) tofree: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.
src/cmd/8c/txt.c(276) isreg: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.
src/cmd/8g/ggen.c(52)  toffset: Names that begin with either 'is' or 
'to' followed by a lowercase letter may be used for additional character 
testing and conversion functions.
src/cmd/8g/reg.c(1086)isreg: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.
src/cmd/8g/reg.c(1133)isreg: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.


Le mercredi 5 mars 2014 19:36:44 UTC+1, Durand Jean-Damien a écrit :
>
> I'll do on go1.2.1. Will tell you / JD.
>
> Le mercredi 5 mars 2014 10:24:56 UTC+1, rns a écrit :
>>
>> There is that presentation [1] to be held at GopherCon; at first sight, 
>> running 
>> cscan/c2ast<https://github.com/jddurand/MarpaX-Languages-C-AST/tree/master/bin>like
>>  Jean Damien did 
>> with perl source 
>> code<https://groups.google.com/d/msg/marpa-parser/QkcRarH1N7k/VJWmdfICNsQJ>and
>>  blogging or otherwise letting know about it looks like a good thing to 
>> show what Marpa can do.
>>
>> [1] Go from C to Go
>> Friday, 25 Apr 8:30am (30m)Russ Cox - Engineer at Google
>>
>> It's time for the Go compilers to be written in Go, not in C. I'll talk 
>> about the unusual process the Go team has adopted to make that happen: 
>> mechanical conversion of the existing C compilers into idiomatic Go code.
>>
>> http://www.gophercon.com/schedule/#ross_cox
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: cscan on Go lang C code

[Durand Jean-Damien]

Sorry for the noise, I just want to comment that there are some c2ast 
failures, and I will have to:
* check with a previous version of Marpa::R2 in case this would be a 
regression
* check c2ast itself
Few files are in failure, but hey, there should be 100% success parsing C.

Le mercredi 5 mars 2014 20:55:49 UTC+1, Durand Jean-Damien a écrit :
>
> Btw, interesting. One of the files seems crafted I do not know how:
>
>  return defgetenv("GOROOT", /home/jdurand/Téléchargements/go);
> --^
>
> and another one gives c2ast failure. This last case I will have to check. 
> Could be a c2ast bug, to be confirmed.
>
>  d->name = d->uid = d->gid = d->muid = "";
> -^
>
> JD.
>
> Le mercredi 5 mars 2014 20:34:45 UTC+1, rns a écrit :
>>
>> That's a great start! 
>>
>> As for the question, can't really help here, sorry, 
>> golang-dev<https://groups.google.com/forum/#!forum/golang-dev> looks 
>> like a good place to ask and/or report on the results.
>>
>> "We plan to translate the existing compilers from C to Go by writing and 
>> then applying an automatic translator" — says Russ Cox in Go 1.3+ 
>> Compiler 
>> Overhaul<https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/edit>
>>  — 
>> looks like they may find C parsing features provided by 
>> MarpaX::Languages::C::AST useful.
>>
>>
>>
>>
>> On Wed, Mar 5, 2014 at 9:13 PM, Durand Jean-Damien > > wrote:
>>
>>> Is there a way to know how GO bootstraps its library, I mean starting at:
>>>
>>> ./cmd/dist/dist bootstrap $buildall $GO_DISTFLAGS -v # builds 
>>> go_bootstrap
>>> # Delay move of dist tool to now, because bootstrap may clear tool 
>>> directory.
>>> mv cmd/dist/dist "$GOTOOLDIR"/dist
>>> "$GOTOOLDIR"/go_bootstrap clean -i std
>>> echo
>>>
>>> if [ "$GOHOSTARCH" != "$GOARCH" -o "$GOHOSTOS" != "$GOOS" ]; then
>>> echo "# Building packages and commands for host, $GOHOSTOS/$GOHOSTARCH."
>>>  GOOS=$GOHOSTOS GOARCH=$GOHOSTARCH \
>>> "$GOTOOLDIR"/go_bootstrap install -ccflags "$GO_CCFLAGS" -gcflags 
>>> "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std
>>>  echo
>>> fi
>>>
>>> echo "# Building packages and commands for $GOOS/$GOARCH."
>>> "$GOTOOLDIR"/go_bootstrap install $GO_FLAGS -ccflags "$GO_CCFLAGS" 
>>> -gcflags "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std
>>> echo
>>>
>>> rm -f "$GOTOOLDIR"/go_bootstrap
>>>
>>> if [ "$1" != "--no-banner" ]; then
>>> "$GOTOOLDIR"/dist banner
>>> fi
>>>
>>> I see ccflags etc... but I mean: can you confirm or give me a way to 
>>> know what are exactly all the c flags in action.
>>> The first step, creating the bootstrap was easy. But bootstrap is a bit 
>>> obscure.
>>> Oterwise c2ast did not suffer from analysing GO bootstrap code -;
>>>
>>> Ah, result of the 1st step (i.e. the one that generates the bootstrap) 
>>> is:
>>>
>>> cmd/dist/buf.c(218) strpcmp: Names beginning with 'str', 'mem', or 
>>> 'wcs' followed by a lowercase letter are reserved for additional string and 
>>> array functions
>>> cmd/dist/build.c(25)  tooldir: Names that begin with either 'is' or 
>>> 'to' followed by a lowercase letter may be used for additional character 
>>> testing and conversion functions.
>>> cmd/dist/build.c(612) islib: Names that begin with either 'is' or 
>>> 'to' followed by a lowercase letter may be used for additional character 
>>> testing and conversion functions.
>>> cmd/dist/build.c(612) ispkg: Names that begin with either 'is' or 
>>> 'to' followed by a lowercase letter may be used for additional character 
>>> testing and conversion functions.
>>> cmd/dist/build.c(612) isgo: Names that begin with either 'is' or 
>>> 'to' followed by a lowercase letter may be used for additional character 
>>> testing and conversion functions.
>>> cmd/dist/goc2c.c(127) structround: Names beginning with 'str', 
>>> 'mem', or 'wcs' followed by a lowercase letter are reserved for additional 
>>> string and array 

Re: cscan on Go lang C code

[Durand Jean-Damien]

Btw, interesting. One of the files seems crafted I do not know how:

 return defgetenv("GOROOT", /home/jdurand/Téléchargements/go);
--^

and another one gives c2ast failure. This last case I will have to check. 
Could be a c2ast bug, to be confirmed.

 d->name = d->uid = d->gid = d->muid = "";
-^

JD.

Le mercredi 5 mars 2014 20:34:45 UTC+1, rns a écrit :
>
> That's a great start! 
>
> As for the question, can't really help here, sorry, 
> golang-dev<https://groups.google.com/forum/#!forum/golang-dev> looks 
> like a good place to ask and/or report on the results.
>
> "We plan to translate the existing compilers from C to Go by writing and 
> then applying an automatic translator" — says Russ Cox in Go 1.3+ 
> Compiler 
> Overhaul<https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/edit>
>  — 
> looks like they may find C parsing features provided by 
> MarpaX::Languages::C::AST useful.
>
>
>
>
> On Wed, Mar 5, 2014 at 9:13 PM, Durand Jean-Damien 
> 
> > wrote:
>
>> Is there a way to know how GO bootstraps its library, I mean starting at:
>>
>> ./cmd/dist/dist bootstrap $buildall $GO_DISTFLAGS -v # builds 
>> go_bootstrap
>> # Delay move of dist tool to now, because bootstrap may clear tool 
>> directory.
>> mv cmd/dist/dist "$GOTOOLDIR"/dist
>> "$GOTOOLDIR"/go_bootstrap clean -i std
>> echo
>>
>> if [ "$GOHOSTARCH" != "$GOARCH" -o "$GOHOSTOS" != "$GOOS" ]; then
>> echo "# Building packages and commands for host, $GOHOSTOS/$GOHOSTARCH."
>>  GOOS=$GOHOSTOS GOARCH=$GOHOSTARCH \
>> "$GOTOOLDIR"/go_bootstrap install -ccflags "$GO_CCFLAGS" -gcflags 
>> "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std
>>  echo
>> fi
>>
>> echo "# Building packages and commands for $GOOS/$GOARCH."
>> "$GOTOOLDIR"/go_bootstrap install $GO_FLAGS -ccflags "$GO_CCFLAGS" 
>> -gcflags "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std
>> echo
>>
>> rm -f "$GOTOOLDIR"/go_bootstrap
>>
>> if [ "$1" != "--no-banner" ]; then
>> "$GOTOOLDIR"/dist banner
>> fi
>>
>> I see ccflags etc... but I mean: can you confirm or give me a way to know 
>> what are exactly all the c flags in action.
>> The first step, creating the bootstrap was easy. But bootstrap is a bit 
>> obscure.
>> Oterwise c2ast did not suffer from analysing GO bootstrap code -;
>>
>> Ah, result of the 1st step (i.e. the one that generates the bootstrap) is:
>>
>> cmd/dist/buf.c(218) strpcmp: Names beginning with 'str', 'mem', or 
>> 'wcs' followed by a lowercase letter are reserved for additional string and 
>> array functions
>> cmd/dist/build.c(25)  tooldir: Names that begin with either 'is' or 
>> 'to' followed by a lowercase letter may be used for additional character 
>> testing and conversion functions.
>> cmd/dist/build.c(612) islib: Names that begin with either 'is' or 
>> 'to' followed by a lowercase letter may be used for additional character 
>> testing and conversion functions.
>> cmd/dist/build.c(612) ispkg: Names that begin with either 'is' or 
>> 'to' followed by a lowercase letter may be used for additional character 
>> testing and conversion functions.
>> cmd/dist/build.c(612) isgo: Names that begin with either 'is' or 'to' 
>> followed by a lowercase letter may be used for additional character testing 
>> and conversion functions.
>> cmd/dist/goc2c.c(127) structround: Names beginning with 'str', 'mem', 
>> or 'wcs' followed by a lowercase letter are reserved for additional string 
>> and array functions
>> cmd/dist/goc2c.c(284) token: Names that begin with either 'is' or 
>> 'to' followed by a lowercase letter may be used for additional character 
>> testing and conversion functions.
>> cmd/dist/goc2c.c(294) token: Names that begin with either 'is' or 
>> 'to' followed by a lowercase letter may be used for additional character 
>> testing and conversion functions.
>> cmd/dist/goc2c.c(389) token: Names that begin with either 'is' or 
>> 'to' followed by a lowercase letter may be used for additional character 
>> testing and conversion functions.
>> cmd/dist/goc2c.c(437) token: N

Re: cscan on Go lang C code

[Durand Jean-Damien]

No pb, I think I managed to get it, using option -v - do not know if this 
will catch all the c file but it seems so.
Will post the final result soon.
Otherwise, yes, building an AST for automatic translation can probably be 
derived quite easily from c2ast (which still requires the preprocessor, but 
has very obscure flags, like --lazy, to work without... i.e. build an AST 
from an unpreprocessed file).

Le mercredi 5 mars 2014 20:34:45 UTC+1, rns a écrit :
>
> That's a great start! 
>
> As for the question, can't really help here, sorry, 
> golang-dev<https://groups.google.com/forum/#!forum/golang-dev> looks 
> like a good place to ask and/or report on the results.
>
> "We plan to translate the existing compilers from C to Go by writing and 
> then applying an automatic translator" — says Russ Cox in Go 1.3+ 
> Compiler 
> Overhaul<https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/edit>
>  — 
> looks like they may find C parsing features provided by 
> MarpaX::Languages::C::AST useful.
>
>
>
>
> On Wed, Mar 5, 2014 at 9:13 PM, Durand Jean-Damien 
> 
> > wrote:
>
>> Is there a way to know how GO bootstraps its library, I mean starting at:
>>
>> ./cmd/dist/dist bootstrap $buildall $GO_DISTFLAGS -v # builds 
>> go_bootstrap
>> # Delay move of dist tool to now, because bootstrap may clear tool 
>> directory.
>> mv cmd/dist/dist "$GOTOOLDIR"/dist
>> "$GOTOOLDIR"/go_bootstrap clean -i std
>> echo
>>
>> if [ "$GOHOSTARCH" != "$GOARCH" -o "$GOHOSTOS" != "$GOOS" ]; then
>> echo "# Building packages and commands for host, $GOHOSTOS/$GOHOSTARCH."
>>  GOOS=$GOHOSTOS GOARCH=$GOHOSTARCH \
>> "$GOTOOLDIR"/go_bootstrap install -ccflags "$GO_CCFLAGS" -gcflags 
>> "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std
>>  echo
>> fi
>>
>> echo "# Building packages and commands for $GOOS/$GOARCH."
>> "$GOTOOLDIR"/go_bootstrap install $GO_FLAGS -ccflags "$GO_CCFLAGS" 
>> -gcflags "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std
>> echo
>>
>> rm -f "$GOTOOLDIR"/go_bootstrap
>>
>> if [ "$1" != "--no-banner" ]; then
>> "$GOTOOLDIR"/dist banner
>> fi
>>
>> I see ccflags etc... but I mean: can you confirm or give me a way to know 
>> what are exactly all the c flags in action.
>> The first step, creating the bootstrap was easy. But bootstrap is a bit 
>> obscure.
>> Oterwise c2ast did not suffer from analysing GO bootstrap code -;
>>
>> Ah, result of the 1st step (i.e. the one that generates the bootstrap) is:
>>
>> cmd/dist/buf.c(218) strpcmp: Names beginning with 'str', 'mem', or 
>> 'wcs' followed by a lowercase letter are reserved for additional string and 
>> array functions
>> cmd/dist/build.c(25)  tooldir: Names that begin with either 'is' or 
>> 'to' followed by a lowercase letter may be used for additional character 
>> testing and conversion functions.
>> cmd/dist/build.c(612) islib: Names that begin with either 'is' or 
>> 'to' followed by a lowercase letter may be used for additional character 
>> testing and conversion functions.
>> cmd/dist/build.c(612) ispkg: Names that begin with either 'is' or 
>> 'to' followed by a lowercase letter may be used for additional character 
>> testing and conversion functions.
>> cmd/dist/build.c(612) isgo: Names that begin with either 'is' or 'to' 
>> followed by a lowercase letter may be used for additional character testing 
>> and conversion functions.
>> cmd/dist/goc2c.c(127) structround: Names beginning with 'str', 'mem', 
>> or 'wcs' followed by a lowercase letter are reserved for additional string 
>> and array functions
>> cmd/dist/goc2c.c(284) token: Names that begin with either 'is' or 
>> 'to' followed by a lowercase letter may be used for additional character 
>> testing and conversion functions.
>> cmd/dist/goc2c.c(294) token: Names that begin with either 'is' or 
>> 'to' followed by a lowercase letter may be used for additional character 
>> testing and conversion functions.
>> cmd/dist/goc2c.c(389) token: Names that begin with either 'is' or 
>> 'to' followed by a lowercase letter may be used for additional character 
>> testing and conversion

Re: cscan on Go lang C code

[Durand Jean-Damien]

Is there a way to know how GO bootstraps its library, I mean starting at:

./cmd/dist/dist bootstrap $buildall $GO_DISTFLAGS -v # builds go_bootstrap
# Delay move of dist tool to now, because bootstrap may clear tool 
directory.
mv cmd/dist/dist "$GOTOOLDIR"/dist
"$GOTOOLDIR"/go_bootstrap clean -i std
echo

if [ "$GOHOSTARCH" != "$GOARCH" -o "$GOHOSTOS" != "$GOOS" ]; then
echo "# Building packages and commands for host, $GOHOSTOS/$GOHOSTARCH."
GOOS=$GOHOSTOS GOARCH=$GOHOSTARCH \
"$GOTOOLDIR"/go_bootstrap install -ccflags "$GO_CCFLAGS" -gcflags 
"$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std
echo
fi

echo "# Building packages and commands for $GOOS/$GOARCH."
"$GOTOOLDIR"/go_bootstrap install $GO_FLAGS -ccflags "$GO_CCFLAGS" -gcflags 
"$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std
echo

rm -f "$GOTOOLDIR"/go_bootstrap

if [ "$1" != "--no-banner" ]; then
"$GOTOOLDIR"/dist banner
fi

I see ccflags etc... but I mean: can you confirm or give me a way to know 
what are exactly all the c flags in action.
The first step, creating the bootstrap was easy. But bootstrap is a bit 
obscure.
Oterwise c2ast did not suffer from analysing GO bootstrap code -;

Ah, result of the 1st step (i.e. the one that generates the bootstrap) is:

cmd/dist/buf.c(218) strpcmp: Names beginning with 'str', 'mem', or 
'wcs' followed by a lowercase letter are reserved for additional string and 
array functions
cmd/dist/build.c(25)  tooldir: Names that begin with either 'is' or 
'to' followed by a lowercase letter may be used for additional character 
testing and conversion functions.
cmd/dist/build.c(612) islib: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.
cmd/dist/build.c(612) ispkg: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.
cmd/dist/build.c(612) isgo: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.
cmd/dist/goc2c.c(127) structround: Names beginning with 'str', 'mem', 
or 'wcs' followed by a lowercase letter are reserved for additional string 
and array functions
cmd/dist/goc2c.c(284) token: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.
cmd/dist/goc2c.c(294) token: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.
cmd/dist/goc2c.c(389) token: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.
cmd/dist/goc2c.c(437) token: Names that begin with either 'is' or 'to' 
followed by a lowercase letter may be used for additional character testing 
and conversion functions.

Thanks / JD.

Le mercredi 5 mars 2014 10:24:56 UTC+1, rns a écrit :
>
> There is that presentation [1] to be held at GopherCon; at first sight, 
> running 
> cscan/c2astlike
>  Jean Damien did 
> with perl source 
> codeand
>  blogging or otherwise letting know about it looks like a good thing to 
> show what Marpa can do.
>
> [1] Go from C to Go
> Friday, 25 Apr 8:30am (30m)Russ Cox - Engineer at Google
>
> It's time for the Go compilers to be written in Go, not in C. I'll talk 
> about the unusual process the Go team has adopted to make that happen: 
> mechanical conversion of the existing C compilers into idiomatic Go code.
>
> http://www.gophercon.com/schedule/#ross_cox
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: cscan on Go lang C code

[Durand Jean-Damien]

I'll do on go1.2.1. Will tell you / JD.

Le mercredi 5 mars 2014 10:24:56 UTC+1, rns a écrit :
>
> There is that presentation [1] to be held at GopherCon; at first sight, 
> running 
> cscan/c2astlike
>  Jean Damien did 
> with perl source 
> codeand
>  blogging or otherwise letting know about it looks like a good thing to 
> show what Marpa can do.
>
> [1] Go from C to Go
> Friday, 25 Apr 8:30am (30m)Russ Cox - Engineer at Google
>
> It's time for the Go compilers to be written in Go, not in C. I'll talk 
> about the unusual process the Go team has adopted to make that happen: 
> mechanical conversion of the existing C compilers into idiomatic Go code.
>
> http://www.gophercon.com/schedule/#ross_cox
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Just uploaded a release candidate to CPAN: Marpa-R2 2.081_001

[Durand Jean-Damien]

Here is a gist showing how to inspect Marpa 
grammar together 
with the new rule_name() and start_symbol_id() methods.
Great release candidate -;

Le lundi 24 février 2014 18:55:10 UTC+1, Jeffrey Kegler a écrit :
>
> I've just uploaded Marpa-R2 
> 2.081_001, 
> which is a release candidate.  Value added includes:
>
>- 
>- In the semantics, new array descriptor 
> elements:
>  
>"name", "symbol", "lhs". 
>- The ability to change the treatment of inaccessibble 
> symbols.
>  (Inaccessible 
>symbols are those which cannot be reached from the start symbol).
>- The SLIF's use of ambiiguity in its own DSL is now 
> documented
>.
>- Rules can now be named, using the "name" 
> adverb
>. 
>
> Since this is a release candidate, testing is especially appreciated.
>
> Thanks, jeffrey
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Just uploaded a release candidate to CPAN: Marpa-R2 2.081_001

[Durand Jean-Damien]

Here is a gist showing how to inspect Marpa 
grammartogether with the new 
rule_name() and start_symbol_id() methods.
Great release candidate -;

Le lundi 24 février 2014 18:55:10 UTC+1, Jeffrey Kegler a écrit :
>
> I've just uploaded Marpa-R2 
> 2.081_001, 
> which is a release candidate.  Value added includes:
>
>- 
>- In the semantics, new array descriptor 
> elements:
>  
>"name", "symbol", "lhs". 
>- The ability to change the treatment of inaccessibble 
> symbols.
>  (Inaccessible 
>symbols are those which cannot be reached from the start symbol).
>- The SLIF's use of ambiiguity in its own DSL is now 
> documented
>.
>- Rules can now be named, using the "name" 
> adverb
>. 
>
> Since this is a release candidate, testing is especially appreciated.
>
> Thanks, jeffrey
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: A note on integer arithmetic

[Durand Jean-Damien]

Interesting! Thnx.

Le samedi 22 février 2014 23:07:16 UTC+1, Ron Savage a écrit :
>
>
> http://www.exploringbinary.com/ten-ways-to-check-if-an-integer-is-a-power-of-two-in-c/
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ambiguity_metric

[Durand Jean-Damien]

Ah... I answer to myself: I presume this is yes unless the grammar has 
"rank" keyword, which is my case (IF/ELSE and CASE embiguities in 
ECMAScript grammar).
Ok, please forget this mail - I have to go back to calling value() twice to 
detect ambiguity at the parse tree value phase -;

ps: Ah, DSL connection back

Le samedi 22 février 2014 08:29:28 UTC+1, Durand Jean-Damien a écrit :
>
> Jeffrey,
> If this call return a value >=2 is it guaranteed that value () on the 
> recce will return at least two defined value references? 
> Thx, JD
>
> Ps: cannot irc i have very unstable connection currently this mail is sent 
> via cellular phone -;
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

ambiguity_metric

[Durand Jean-Damien]

Jeffrey,
If this call return a value >=2 is it guaranteed that value () on the recce
will return at least two defined value references?
Thx, JD

Ps: cannot irc i have very unstable connection currently this mail is sent
via cellular phone -;

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New indexed CPAN release, with Longest Acceptable Tokens Matching

[Durand Jean-Damien]

Was reading this idea about diagnostic compiler and C 
language.
 
 Running c2ast or cscan will do it, with a customized user-friendly output 
rewriten as:

   it failed here
   --^

or did I misunderstood the point.

Le jeudi 20 février 2014 10:21:06 UTC+1, Jeffrey Kegler a écrit :
>
>  I just re-read the linked 
> page, 
> the current version is very, very good. -- jeffrey
>
>  On 02/19/2014 02:03 PM, Ron Savage wrote:
>  
> Thursday last week I started a new job, working from home, so I won't play 
> with this for a few days. But then I'll mindlessly change the default in 
> all grammars, and run all the tests. 
>
>  Also, we need to come up with a short(ish) description of the above, to 
> suit: http://savage.net.au/Perl-modules/html/marpa.papers/chapter2.html
>  -- 
> You received this message because you are subscribed to the Google Groups 
> "marpa parser" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to marpa-parser...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> 

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New indexed CPAN release, with Longest Acceptable Tokens Matching

[Durand Jean-Damien]

A major and remarquable change / JD.

Le mercredi 19 février 2014 19:37:33 UTC+1, Jeffrey Kegler a écrit :
>
> I've just uploaded 2.08, a new indexed 
> version, 
> to CPAN.  This release
> is a very big change internally, the first external sign of which is
> the introduction of efficient Longest Acceptable Tokens Matching (LATM)
> to the SLIF.  LATM is implemented using the "forgiving 
> adverb"
> .
>
> LATM means that the SLIF, when lexing, considers only those tokens
> that would actually be acceptable to the top-level structural grammar.
> Previously, the SLIF used Longet Tokens Matching (LTM), and considered
> all lexemes, even those that would not be acceptable to the parse.
> LTM is the tradition and the current standard practice in parsing --
> pre-Marpa parsers are not smart enough to tell lexers which lexemes they
> can accept and which they cannot.
>
> LATM is "smarter" than LTM.  This "smartness" allows you to be more
> aggressive in designing your lexer -- it increases the likelihood that
> the parser will know "what you meant".  When context is used to help make
> the decision, the chance that two of your tokens will treat the same
> input string in conflicting ways is reduced.  With LATM, unacceptable
> tokens will not cause conflicts.
>
> LATM is not the default, because of backward compatibility.  But I
> recommend that everyone, as their preferred choice, start all new
> scripts with
>
> lexeme default = forgiving => 1
>
>
> You also should be able to convert most old scripts to use LATM without a
> problem, making them faster and easier to extend.
>
> Note that the documentation still contains warning language about the
> efficiency implications of the "forgiving" adverb.  These warnings
> need not be heeded -- they are no longer true, and will be removed in
> a future release.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Request for discussion: an "interface" statement

[Durand Jean-Damien]

let's go with interface

Le dimanche 16 février 2014 03:35:22 UTC+1, Jeffrey Kegler a écrit :
>
>  Re "interface 2", I can go with something that has a bit more "hype", 
> like
>
> dsl maker 2
>
> -- jeffrey
>
>  On 02/15/2014 05:58 PM, Durand Jean-Damien wrote:
>  
> :default ::= action => ::array sound the best to me, because it is 
> natural when we read a grammar to expect as many values as there are RHS. 
>
>  I quite liked to proposal of ron, although IMHO lhs better fits in 
> blessing, despite the fact that beginners will always certainly do 
> Data::Dumper(), whose output is simply unmanagable with  hundreds of 
> blessed structures - in contrary to a lhs that would be added to [values]. 
> But I'd not make that a default.
>
>  What puzzles me is the presence of "interface 2", or is it "revision 2". 
> Meaning is clear. Backward compatibility constraint is clear. But this look 
> strange. Unfortunately, until a major version change, there is no real 
> alternative.
>
>   

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Request for discussion: an "interface" statement

[Durand Jean-Damien]

should read "I quite liked to proposal of rns" - sorry.
You can delete this message having read it -;

Le dimanche 16 février 2014 02:58:51 UTC+1, Durand Jean-Damien a écrit :
>
> I quite liked to proposal of ron, ./..
>

>>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Request for discussion: an "interface" statement

[Durand Jean-Damien]

:default ::= action => ::array sound the best to me, because it is natural 
when we read a grammar to expect as many values as there are RHS.

I quite liked to proposal of ron, although IMHO lhs better fits in 
blessing, despite the fact that beginners will always certainly do 
Data::Dumper(), whose output is simply unmanagable with  hundreds of 
blessed structures - in contrary to a lhs that would be added to [values]. 
But I'd not make that a default.

What puzzles me is the presence of "interface 2", or is it "revision 2". 
Meaning is clear. Backward compatibility constraint is clear. But this look 
strange. Unfortunately, until a major version change, there is no real 
alternative.

Le samedi 15 février 2014 18:29:06 UTC+1, Jeffrey Kegler a écrit :
>
> I'd like opinions on adding a "interface" statement to the SLIF.
> Currently, for backward compatibility reasons, some of the defaults are
> not the best.  I'd like to add a
>
> interface 2
>
> statement which, if present, will makes these the new defaults:
>
>   lexeme default = forgiving => 1
>   :default ::= action => ::array
>
> The first line would make LATM the default, and the second would make
> the make the default semantics for rules return the child values in
> an array.
>
> A specific reason for changing the default for rule semantics is that
> in the first stages of development, array output is useful in checking
> your grammar.  So it's a great way to start.
>
> The current behavior, returning 'undef' by default, is especially
> perplexing to newcomers to Marpa.  It means that, by default, value()
> returns \undef on success, and undef on failure.  This behavior is
> unintuitive, unhelpful and confusing.
>
> A specific question I have: Should one of the bless options also be the
> default for rules?  If so, what about lexemes?  A reason not to bless
> is clutter.  A reason to bless is that it provides even more information
> for grammar checking.
>
> As usual, these defaults will be able to be overriden, but they do make
> a real difference in convenience, and to those just finding their way
> in Marpa.  Whichever is the choice, I'll change all the synopses in the
> docs to include a
>
>   revision 2
>
> statement at the beginning, so that it becomes more or less like the
> "use strict", etc. incantation at the beginning of Perl scripts.
>
> Please comment or ask questions -- jeffrey
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Blog post] A Marpa use case: JavaScript Regexp Implementation

[Durand Jean-Damien]

FYI (cross-posted from IRC);

A Marpa use case: JavaScript Regexp 
Implementation

JD.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Low-hanging fruit: A Regex compiler

[Durand Jean-Damien]

FYI I was reading http://www.unicode.org/reports/tr18/ - less easy to 
understand but well -;

Le samedi 25 janvier 2014 19:51:23 UTC+1, rns a écrit :
>
> Looks good. I'll certainly have to steal from there. Thanks for pointing 
> me to it.
>
> On Sat, Jan 25, 2014 at 8:40 PM, Durand Jean-Damien 
> 
> > wrote:
>
>> Then you might like my 
>> implementation<https://github.com/jddurand/MarpaX-Languages-ECMAScript-AST/blob/master/lib/MarpaX/Languages/ECMAScript/AST/Grammar/ECMAScript_262_5/Lexical/RegularExpressionLiteral.pm>
>>  - 
>> the only subtility in this simple grammar is that I use these 
>> user-defined character 
>> classes<https://github.com/jddurand/MarpaX-Languages-ECMAScript-AST/blob/master/lib/MarpaX/Languages/ECMAScript/AST/Grammar/CharacterClasses.pm>
>> . 
>>
>> Le samedi 25 janvier 2014 19:26:59 UTC+1, rns a écrit :
>>>
>>> Thanks Jean Damien! I've already found a couple of some similar but this 
>>> one is very clear.
>>>
>>>
>>> On Sat, Jan 25, 2014 at 8:24 PM, Durand Jean-Damien <
>>> jeandami...@gmail.com> wrote:
>>>
>>>> Note that a startup can be the ECMAScript pattern 
>>>> specification<http://www.ecma-international.org/ecma-262/5.1/#sec-15.10.1> 
>>>> - 
>>>> ECMAScript implements a very low subset of perl regexp pattern, but it 
>>>> shows quite well how such a grammar should be structured.
>>>>
>>>> Le samedi 25 janvier 2014 18:59:06 UTC+1, Jeffrey Kegler a écrit :
>>>>
>>>>>  I like the idea.  Regular expressions, as parsed using 
>>>>> special-purpose regular expression engines, will always survive, because 
>>>>> of 
>>>>> the speed.  But a lot of things people do with regular expressions would 
>>>>> benefit from more power.  -- jeffrey
>>>>>
>>>>>   -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "marpa parser" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to marpa-parser...@googlegroups.com.
>>>>
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>
>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "marpa parser" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to marpa-parser...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Low-hanging fruit: A Regex compiler

[Durand Jean-Damien]

Then you might like my 
implementation<https://github.com/jddurand/MarpaX-Languages-ECMAScript-AST/blob/master/lib/MarpaX/Languages/ECMAScript/AST/Grammar/ECMAScript_262_5/Lexical/RegularExpressionLiteral.pm>
 - 
the only subtility in this simple grammar is that I use these user-defined 
character 
classes<https://github.com/jddurand/MarpaX-Languages-ECMAScript-AST/blob/master/lib/MarpaX/Languages/ECMAScript/AST/Grammar/CharacterClasses.pm>
. 

Le samedi 25 janvier 2014 19:26:59 UTC+1, rns a écrit :
>
> Thanks Jean Damien! I've already found a couple of some similar but this 
> one is very clear.
>
>
> On Sat, Jan 25, 2014 at 8:24 PM, Durand Jean-Damien 
> 
> > wrote:
>
>> Note that a startup can be the ECMAScript pattern 
>> specification<http://www.ecma-international.org/ecma-262/5.1/#sec-15.10.1> - 
>> ECMAScript implements a very low subset of perl regexp pattern, but it 
>> shows quite well how such a grammar should be structured.
>>
>> Le samedi 25 janvier 2014 18:59:06 UTC+1, Jeffrey Kegler a écrit :
>>
>>>  I like the idea.  Regular expressions, as parsed using special-purpose 
>>> regular expression engines, will always survive, because of the speed.  But 
>>> a lot of things people do with regular expressions would benefit from more 
>>> power.  -- jeffrey
>>>
>>>   -- 
>> You received this message because you are subscribed to the Google Groups 
>> "marpa parser" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to marpa-parser...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Low-hanging fruit: A Regex compiler

[Durand Jean-Damien]

Note that a startup can be the ECMAScript pattern 
specification - 
ECMAScript implements a very low subset of perl regexp pattern, but it 
shows quite well how such a grammar should be structured.

Le samedi 25 janvier 2014 18:59:06 UTC+1, Jeffrey Kegler a écrit :
>
>  I like the idea.  Regular expressions, as parsed using special-purpose 
> regular expression engines, will always survive, because of the speed.  But 
> a lot of things people do with regular expressions would benefit from more 
> power.  -- jeffrey
>
> 

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Grammar::Formal

[Durand Jean-Damien]

Started <https://rt.cpan.org/Public/Dist/Display.html?Name=Grammar-Formal>-; 

Le lundi 20 janvier 2014 22:00:52 UTC+1, Durand Jean-Damien a écrit :
>
> FYI I came across this new module 
> Grammar::Formal<https://metacpan.org/release/Grammar-Formal>, 
> Marpa BNF cannot be expressed with it, but for sure it covers usual BNF's 
> without, how to say, options.
> I might file such a feature request -;
> JD.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Grammar::Formal

[Durand Jean-Damien]

FYI I came across this new module 
Grammar::Formal, 
Marpa BNF cannot be expressed with it, but for sure it covers usual BNF's 
without, how to say, options.
I might file such a feature request -;
JD.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: alternative() failed

[Durand Jean-Damien]

Ah yes, sorry, these messages were lost in the thousands of lines of 
debug...
I am experimenting with a grammar that give me troubles-; forgiving keyword 
included.
Thx / JD.

Le samedi 18 janvier 2014 17:33:56 UTC+1, Jeffrey Kegler a écrit :
>
>  I'd expect it indicates the the symbol being read is not accessible, 
> that is, not reachable from the start symbol.  The message isn't of the 
> best -- it talks too much about the internals.  Was there a warning message 
> that you have an inaccessible symbol?
>
> -- jeffrey
>
>  On 01/18/2014 05:45 AM, Durand Jean-Damien wrote:
>  
> Jeffrey, 
>
>  Another question:
>
>  Is the message "Problem in u_read(), alternative() failed: Token symbol 
> is inaccessible at /usr/local/lib/perl/5.18.2/Marpa/R2/SLR.pm line 881" 
> expected to be a problem in the user's grammar or in the SLIF internals ?
>
>  This is with 2.07901.
>
>  Thanks / JD.
>
>  -- 
> You received this message because you are subscribed to the Google Groups 
> "marpa parser" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to marpa-parser...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> 

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.