IMPORTANT! You can read every forum, but you can only post in a forum if you are member of the 'Organic Group' that owns the forum. See groups for a complete list of Organic Groups on the Hive. Content (forums, pages, blogs, etc) on OE Hive is all organized using a module called 'Organic Groups'. Every Group has its own forum.
This is the general discussion forum for the OERA Open Source Initiative. If you are commenting on a specific contribution or proposal which already has its own page, please add comments to the page so the page author can respond and consider integrating your material into the page. Use this forum for early stage proposals, discussion of general principles, issues of interaction, etc.
This is getting so easy ;)
DEF BUFFER ParentNode FOR TTNode. FOR EACH TTNode NO-LOCK WHERE TTnode.NodeTypeNum EQ NodeTypes:END# AND TTnode.FirstChild EQ -1, FIRST ParentNode WHERE ParentNode.NodeNum EQ TTnode.Parent NO-LOCK: IF NOT CAN-DO("PROCEDURE,FUNCTION,CASE,METHOD,CLASS,CONSTRUCTOR,DESTRUCTOR":U,ParentNode.NodeText) THEN NEXT. /* ignore DO: FOR: etc */ MESSAGE SUBSTITUTE('Line: &1, Column: &2 Use END &3 to terminate a &4 block',TTnode.NodeLine,TTNode.NodeCol,ParentNode.NodeText,LC(ParentNode.NodeText)) VIEW-AS ALERT-BOX INFORMATION. END.
This is a sample of how we could implement the colon-t prolint rule:
DEF VAR lv_String AS CHAR NO-UNDO. FOR EACH TTNode NO-LOCK WHERE TTnode.NodeTypeNum EQ NodeTypes:QSTRING#: IF SUBSTR(TTnode.NodeText,LENGTH(TTnode.NodeText) - 1) NE ":T" THEN NEXT. ASSIGN lv_String = SUBSTRING(TTnode.NodeText,2,LENGTH(TTnode.NodeText) - 4). IF LENGTH(TRIM(lv_String)) = LENGTH(lv_String) THEN NEXT. MESSAGE SUBSTITUTE('Line: &1, Column: &2 attrib :T will trim string "&3"',TTnode.NodeLine,TTNode.NodeCol, lv_String) VIEW-AS ALERT-BOX INFORMATION. END.
Once the parseunit has been initialized and the cu parsed, the following is an example of a "missing NO-UNDO" rule:
DEF BUFFER ChildNode FOR TTNode. FOR EACH TTnode WHERE nodetypenum EQ NodeTypes:DEFINE# AND NodeTypenum2 EQ NodeTypes:VARIABLE# NO-LOCK: /* DEFINE and VARIABLE */ IF CAN-FIND(FIRST ChildNode WHERE ChildNode.Parent EQ TTNode.Nodenum AND ChildNode.NodeTypeNum EQ NodeTypes:NOUNDO#) THEN NEXT. /* move to the next DEF VAR */
Has anyone thought about running the API on an appserver process ? I see some advantages in this ..
I'm posting this for my own reference. A few weeks from now I won't remember why.
I've been considering this question: "Why not use the nodeNum in the parent/firstChild/nextSibling/prevSibling fields?"
Well, in very general terms, consider that any Object may reference any other Object. A Block object might reference a Node object. A Symbol object might reference a Node object. A Scope object my reference a Block object. There has to be an extremely general purpose mechanism for any one Object to reference any other Object. That's what the indexNum and index->offset gives us.
For the benefit of both OO and non-OO node manipulation, I am going to add more node properties. As a result, I need to make some changes to some property names.
The current property list is
Txt CHAR FirstChildNum INT NextSiblingNum INT PrevSiblingNum INT TypeNum INT IndexNum INT ParentNum INT FileNum INT LineNum INT ColumnNum INT RecordOffSet INT Type CLASS NodeType FirstChild CLASS node NextSibling CLASS node PrevSibling CLASS node Parent CLASS node
Does anyone have any objection to making nodetypes a static class ? The properties of each node type are gathered from the proparse server once. As a node class needs to determine the node type characteristics, we currently have to pass around the parseunit object so that the node can do
DEF PUBLIC PROPERTY Type AS CLASS NodeType NO-UNDO GET(): RETURN parseUnit:proparse:NodeTypes:Item(TypeNum). END GET . PROTECTED SET .
I would prefer to see
DEF PUBLIC PROPERTY Type AS CLASS NodeType NO-UNDO GET():
With the latest version of proparse trunk, we can now use the proparse OO Api to talk with the proparse.jar server. See classclient.p for demos on how to load projects and parse files. We need people to test and play with this to find the holes, and make suggestions, so please roll up your sleeves and get busy !
Getting a list of nodes with something like parseUnit:queryType("DEFINE") is very common in Prolint.
I just did some interesting calculations:
On 100,000 nodes, a run through the data blob finding all nodes of type 23 (for example) takes approx 100ms on my machine. And it is almost linear (50000 nodes = 51ms).
If I create a temp-table, it takes 1500ms to create the records (as an initial hit), BUT always less than 1ms to find all records of type 23 - almost 100 times faster
on 50,000 nodes, the timings are
datablob search: 52 ms