From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8537 invoked by alias); 1 May 2002 21:05:18 -0000 Mailing-List: contact sourcenav-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sourcenav-owner@sources.redhat.com Received: (qmail 8530 invoked from network); 1 May 2002 21:05:17 -0000 Received: from unknown (HELO mail.gmx.net) (213.165.64.20) by sources.redhat.com with SMTP; 1 May 2002 21:05:17 -0000 Received: (qmail 32685 invoked by uid 0); 1 May 2002 21:05:12 -0000 Received: from unknown (HELO richard.gmx.net) (209.47.210.117) by mail.gmx.net (mp001-rz3) with SMTP; 1 May 2002 21:05:12 -0000 Message-Id: <1.1.1.11.2.20020426151258.00aa8690@192.168.60.239> X-Sender: ame01@gmx.net@pop.gmx.net Date: Wed, 01 May 2002 14:05:00 -0000 To: sourcenav@sources.redhat.com From: Aurelian Melinte Subject: sn architecture Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SW-Source: 2002-q2/txt/msg00031.txt.bz2 hello, over the past two months I worked on a Java parser for SN, to replace the original one. More on that below. During this period I had some suggestions from more knowledgeable peoples that I think would be beneficial to SN. a) It would be good to add to the API libraries functions that will allow to query the library from within a parser. Example: if I have a function call somemethod( par1, par2 ); and par1 is of type class P from which classes C1 and C2 are inheriting, then par1 can be of type P or C1 or C2. But when I parse Java file by file, I have no way to know it unless I query the database. This will improve the cross-ref functionality to better display polymorphism. b) It would be good to turn the code of those libraries into loadable modules (.dll, .so, etc). Thus, I can supply my own without having to recompile all the parsers. The idea behind is that I will be able to add to the current structure of the database transparently, to store more information, to support different kinds of queries, etc. Or, I can use my own kind of database just by changing this module. c) In this case, the tcl/tk code probably would need to me modified to query through this module too, and, eventually, group the query functionality in one place. It would be easier to modify it - I noticed that although I can insert xrefs to classes or to local variables, those are not displayed. I have no intimate knowledge with tcl, sorry. About the replacement Java parser: you can find it at http://209.47.210.117:8080/sn.html for now. It detects interface/class inheritance, interface/class structure, methods and class variables properly. It detects some cross-references too but very limited (I will resume work on it in a couple of weeks probably). It is much slower than the original :(. It requires JDK/JRE to work. Regards, a.