Subject: Re: sage lib, my current version

From: Zheng Gengbin <[email-masked]>
Date: Thu, 19 Sep 1996 10:34:19 +0800 (EAT)

On Wed, 18 Sep 1996, Guansong Zhang wrote:

> I am sending the sage lib code here to the you, the old place. The network is
> still too slow. I don't know whether it will be successful.
> 
> This time, two files will be transfered:
> 
> a). xsageop.tar.gz
> b). example.tar.gz
> 
> put them in our frontend/src/ and tar them open. (The frontend I am working
> here is 1.59, I am sorry have no time to combine the latest 1.60 these days.
> But I don't think it will cause problem for the lib.)
> 
> Two dirs will be created: one as xsageop, another example
> 
> cd to xsageop and type make, if you work on RS6000, the .a file will be
> generated. else you may need modify the Makefile a little.
> 
> Then come to example dir type make, an exacutable named as addstuff will be
> generated. It takes .dep file as command line argument and generated a
> debug.dep file, unparse this file, you will find what have been done:
> bassically adding new things in the original program.
> 

	I am regetting these two files .The network seems so slow .

> As I said in previous letters, I don't do further work on this lib when it can
> be used for my current purpose, I do not even pick out global include files to
> fit our frontend dir structure. All the files for the new .a file located in
> xsageop dir, and users need to take it as include dir to include necessary
> files. You can see this in example/Makefile.
> 
> As I work on compiling forall, I may further modify the problem in this lib, I
> will keep you posted. But I think I will not take care about file structures
> temporarily. So I have the following suggestion on the next step work for this
> lib:
> 
> a). Consider the relations between file once more, pick out the thing, mainly
> (.h files) which is global and meaningful to the include dir. reorganize files
> (mainly .C files) if necessary.
>

	After I got your version , I will give you another version as soon
as possible . After several exchange , I think we can settle down.

> b). Make clear the memory strategy used in the lib, and decide the one for our
> own. This is an important step. It will not only give the principle for how to
> expand this lib but also on how this lib should be used.
> 
> c). Check each derived class and their member function to see if them fit our
> frontend. Add new ones when needed.
>

	To check each derived class and their member function one by one itself 
seems a tedious work . But we will try . Anyway I think it is best to check
if a member function is correct is to use it and see the result .

> d). Give out the documentation for other users to use this lib.
> 

	After this lib is mature , we will give a document .

	Another thing , in order to desciminate from Sage , we decide to use 
Pt to replace the Sg prefix , such as PtFile instead of SgFile .

> Please make comments on this.
> 

	The network is terrible now , it broken 3 times and I only got 
40K more  in this whole morning .

Zheng

---

From: Zheng Gengbin <[email-masked]>
Date: Fri, 20 Sep 1996 09:49:12 +0800 (EAT)

Hi,

	Now I succesully compiled the xsageop on our HP by using g++ and gcc.

	I found you modified the constructor function of SgProject::SgProject
by adding 2 additional arguments: argc , argv . What's the purpose on 
that ?

Zheng

---

From: Zheng Gengbin <[email-masked]>
Date: Fri, 20 Sep 1996 09:53:28 +0800 (EAT)

Hi,

	When I compiled a simple example with libxsage.a , I found these:
/bin/ld: Unsatisfied symbols:
   cunparse_blck (code)
   cunparse_type (code)
   funparse_blck (code)
   funparse_type (code)

and these functions are defined in file db_unp_vpc.c . Why not copy it to
dir xsageop ?

Zheng .