Thread: [cedet-semantic] Wisent:
Brought to you by:
zappo
From: Andrea T. <and...@gm...> - 2015-08-23 16:39:59
|
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 |
From: Eric L. <er...@si...> - 2015-08-24 02:23:58
|
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" <and...@gm...> 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 > ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-semantic > > |
From: Andrea T. <and...@gm...> - 2015-08-25 00:43:59
|
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 <er...@si...> 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" <and...@gm...> 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 >> ced...@li... >> https://lists.sourceforge.net/lists/listinfo/cedet-semantic >> >> |
From: Eric L. <er...@si...> - 2015-08-25 03:54:15
|
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" <and...@gm...> 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 <er...@si...> > 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" <and...@gm...> 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 >>> ced...@li... >>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic >>> >>> > |
From: Andrea T. <and...@gm...> - 2015-08-25 22:55:31
|
Hi Eric, About the includes, I have tried many times to parse them via the context menu option but it doesn't work. I visited one of those buffers and waited for the parser to pick it up, then figured that the semanticdb-save-db would do something, but after M-x semantic-save-db I got this message "cl-no-applicable-method: No applicable method for %S: semanticdb-save-db, nil". Well, that doesn't keep me from playing with the grammar, but my only worry is that this might in fact be caused by the current state of things. I'm resolving includes as absolute paths. Do you think this might be confusing Ede and in turn SemanticDB? About the mode local function to convert a filename (semantic-analyze-split-name) I'm currently wondering whether I'll be able to have access about certain tags at the time of the call. In particular I'll need the declaration of a 'package tag, I guess I can use semantic-find-tags-by-class to check the parsed data? I have a link to the lang dev guide, is pretty good and that's what I used to get started, unfortunately many of the functions cited there aren't available with Semantic builtin to Emacs 25, so I figure they are either deprecated or only available in the latest CEDET 2? Your help here is greatly appreciated, thanks for answering my many questions in this accidentally untitled thread. Thanks, Andrea. |
From: Eric L. <er...@si...> - 2015-08-28 04:04:52
|
Hi, The function you want to overload is semantic-tag-include-filename. It doesn't need any paths. It's only job is to convert a string into something file compatible. For example the java tag: Import java.thing.Thing; Should convert to: "java/thing/Thing.java" It is the job of other routines to find the full path when it is needed, such as when it tried to parse the includes. Those tools handle caching and saving. It your system uses paths the same way as c, then you shouldn't need to do anything else. Your other troubles are less clear from the email. I can't really help debug until I get my computer back. Eric On Aug 25, 2015 6:54 PM, "Andrea Turso" <and...@gm...> wrote: > Hi Eric, > > About the includes, I have tried many times to parse them via the context > menu option but it doesn't work. > > I visited one of those buffers and waited for the parser to pick it up, > then figured that the semanticdb-save-db would do something, but after M-x > semantic-save-db I got this message "cl-no-applicable-method: No applicable > method for %S: semanticdb-save-db, nil". > > Well, that doesn't keep me from playing with the grammar, but my only > worry is that this might in fact be caused by the current state of things. > > I'm resolving includes as absolute paths. Do you think this might be > confusing Ede and in turn SemanticDB? > > About the mode local function to convert a filename > (semantic-analyze-split-name) I'm currently wondering whether I'll be able > to have access about certain tags at the time of the call. In particular > I'll need the declaration of a 'package tag, I guess I can use > semantic-find-tags-by-class to check the parsed data? > > I have a link to the lang dev guide, is pretty good and that's what I used > to get started, unfortunately many of the functions cited there aren't > available with Semantic builtin to Emacs 25, so I figure they are either > deprecated or only available in the latest CEDET 2? > > Your help here is greatly appreciated, thanks for answering my many > questions in this accidentally untitled thread. > > Thanks, > Andrea. > |