Re: Wisent:

Hi,

I'm on my phone again so I can't get to my links.

The parser should generate an include tag that closely matches the contents
being parsed.  That way you can regenerate code from the tag with srecode.

You need to implement a mode local fcn to convert the language name into a
filename.  I think java has this method.  It should only convert the raw
text, so foo.bar might convert to foo/bar.java for example.

There are then include paths you can setup either with the system include
path or ede.  These path lists are referenced to find the includes on
demand.

The results are handled and stored automatically by the rest of the system
when you install the parser.

Parsing a buffer doesn't parse include contents.  You can use the context
menu on the include line to force parsing all includes.

There is doc for basic parser setup in the langdev guide.  I haven't looked
in there in a while though.

I hope this helps.
Eric
On Aug 24, 2015 8:43 PM, "Andrea Turso" <[email protected]> wrote:

> Hey Eric,
>
> Thanks for the response, I think I was stretching the grammar a little bit
> there, definitely heading into a dead end. I don't think I'll be doing any
> more type guessing than there already is in my grammar[1], but there are a
> number of things that I would like to improve with how include tags are
> handled.
>
> What I'm trying to do is to ensure that whenever the parser emits an
> include-tag, the type names are all converted into fully qualified form[2]
> for them to be safely resolved to filename withs a function from the
> ede-php-autoload[3] package.
>
> So at this point my question is should I be doing this inside of the
> parser itself – with actions and macros – or after the parser data
> structure is done and generated – by manipulating it?
>
> Generally speaking, where is a good place to store the context of the
> buffer analysis? I remember seeing, but fail to recall the exact code, of a
> semantic java or jde file that used parser hooks – are they documented
> somewhere?
>
> Either way, I appreciate if you could throw some more documentation at me?
>
> Thanks for your help,
> Andrea.
>
> PS: Fully qualified includes are already working fine, besides a couple
> that are still highlighted as lost besides resolving just fine. Sadly no
> matter how many times I parse and reparse they always show as unparsed.
>
> [1] A simple wisent grammar for tagging php
> https://github.com/trashofmasters/semantic-php/blob/master/grammar.wy
> [2] PHP converting names into canonical (fully qualified) form
> http://php.net/manual/en/language.namespaces.rules.php
> [3] Integrates EDE with PHP
> https://github.com/stevenremot/ede-php-autoload
>
> On Mon, Aug 24, 2015 at 3:23 AM, Eric Ludlam <[email protected]>
> wrote:
>
>> I am on a phone so this will be brief.
>>
>> You can return as much as you want from a rule by packing into a list.
>> You then need to unpack upstream to use it.
>>
>> If you have one rule that makes 2 tags, pack the data into one tag
>> equivalent (passes tagp) and then implement a tag expander to break it up.
>> The c/c++ impl does this with variables like this:
>>
>> int a,b;
>>
>> I hope this helps.
>> Eric
>> On Aug 23, 2015 12:39 PM, "Andrea Turso" <[email protected]> wrote:
>>
>>> Dear Eric,
>>>
>>> I have hit a blocker while writing a Wisent grammar to tag a PHP buffer,
>>> in particular I'm using class instantiation and parameter type hinting
>>> information to add include-tags.
>>>
>>> I think this should enable Semantic to load and parse all required files
>>> to provide the appropriate completion.
>>>
>>> My understanding is that Wisent is only aware of tags that are yielded
>>> by a rule, so for example if I want to push an include tag I do this:
>>>
>>> class_instantiation: T_NEW qualified_name
>>>                      *(INCLUDE-TAG $2 nil)*
>>>                    ;
>>>
>>> Alternatively, if I need the name of the class being instantiated I can
>>> do
>>>
>>> class_instantiation: T_NEW qualified_name
>>>                      *(identity $2)*
>>>                    ;
>>>
>>> I am now working in a scenario where I need the class_instantiation
>>> rule to do both actions – push the tag and return the class name.
>>>
>>> In the following example I use *progn *to illustrate what I'm trying to
>>> achieve, of course the class name is returned but the tag isn't registered:
>>>
>>> class_instantiation: T_NEW qualified_name
>>>                      *(progn (INCLUDE-TAG $2 nil) $2)*
>>>                    ;
>>>
>>> Is there any way to have a rule to both push a tag and return a value?
>>>
>>> Kind regards,
>>> Andrea Turso
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> cedet-semantic mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>
>>>
>

------------------------------------------------------------------------------

_______________________________________________
cedet-semantic mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cedet-semantic