buddy-developers

Re: [Buddy-developers] bits to merge?

[Haim C. <hai...@us...>]

>>
>> I'd be happy if any of these could be merged back into mainline.
>> Below is the detailed list of the changes I made.  I can send diffs
>> for any of these on request.
>>
Hi Alexandre !

Thanks for your bug fixes and improvements.
I am happy to see that we are already starting to benefit from open 
source ! ]
I think the best approach for merging changes made into different 
versions of BuDDy will be the following :

Everyone have read access to the BuDDy repository in S.F. You should 
first checkout/read the current
CVS repository.
It would be great if you could first merge your changes into the BuDDy 
2.3 and test them.
It will assure us an easier integration later on.
I also prefer to create release right after each successful integration 
and testing. This way we give a chance to people
to try it. I assume most of the users will download the tar.gz file 
rather than checkout fresh files from CVS.

I understand you made 3 kinds of changes : improvements, fixes and build 
automation.

I think that the build automation with autoconf should be the first 
thing to integrate into BuDDy.

I will appreciate comments from the members.

Haim

Re: [Buddy-developers] bits to merge?

[Haim C. <hai...@us...>]

Thanks !

I have never used autoconf+automake+libtool before for projects, but I 
have read a bit about those scripts. Your contribution will be much 
appreciated.
I think that configure and Makefile.in files should be kept under CVS. 
Every tar I have downloaded, had these files in.
Could you please explain how do you generate the configure and 
Makefile.in files ? What exactly ( version numbers ) and how should I run ?
I have tried automake and autoconf, but it seems I do not use them 
correctly, or that I have old versions. configure was generated, but did 
not create Makefiles.
I am running Mandrake, and it seems it comes with old version of these 
tools.

Did you take into account the config file in the original project which 
defines label for the preprocessor ? I did not find it in your version 
with configure.

One more request : I have found there is a patch submitting system in 
SF. Could we use this opportunity that you send a patch to try it out ? 
I want to find out which kind of functionality it provides.

Thanks,
Haim

Alexandre Duret-Lutz wrote:

>Hi Haim,
>
>Sorry for the delay (it will happen again :)).
>
>  
>
>>>>"Haim" == Haim Cohen <hai...@us...> writes:
>>>>        
>>>>
>
>[...]
>
> Haim> Everyone have read access to the BuDDy repository in
> Haim> S.F. You should first checkout/read the current CVS
> Haim> repository.
>
>I'll generate all my patches against the CVS version of BuDDy.
>
> Haim> It would be great if you could first merge your changes
> Haim> into the BuDDy 2.3 and test them.
>
>I did that yesterday (i.e., I've imported BuDDy 2.3 into the Spot
>CVS repository and merge my changes).  (The result is in
>http://spot.lip6.fr/dl/spot-0.0v.tar.gz)
>
>I though it would be peanuts because CHANGES said nothing
>changed except the version, but it turned out I had other
>changes to cope with, besides the version bump: many examples
>were renamed, there is a new way of defining VERSION, ...
>
>I agree such changes do not belong to the CHANGES file (which
>looks like what GNU projects call NEWS), yet it would have saved
>me time to have a list of such changes, and I guess it would
>help other contributors too.  Maybe you could consider using a
>ChangeLog to keep track of every changes, like in GNU projects?
>(see also http://www.gnu.org/prep/standards_40.html#SEC40)
>
>[...]
>
> Haim> I think that the build automation with autoconf should be the first
> Haim> thing to integrate into BuDDy.
>
>Wow, you're brave.  I though this would be the most
>controversial change!
>
>I have one question before I prepare a patch for this.  Do you
>want to keep generated files (configure, Makefile.in, ...) in CVS
>or not?  I personally keep them out of CVS, but see
>http://sources.redhat.com/automake/automake.html#CVS
>before making your mind.
>
>
>By the meantime, here is a patch that fixes the following
>diagnostic output by the CVS version of Bison.  I guess its
>better to fix such things before changing the build.
>  
>

Re: [Buddy-developers] bits to merge?

[Alexandre Duret-L. <Ale...@li...>]

>>> "Haim" == Haim Cohen <hai...@us...> writes:

 Haim> I have never used autoconf+automake+libtool before for
 Haim> projects, but I have read a bit about those scripts. Your
 Haim> contribution will be much appreciated.

BTW, I'm afraid I won't be able to work out the patch for this
before next week.

 Haim> Could you please explain how do you generate the configure and
 Haim> Makefile.in files ? 

configure is generated from configure.ac by autoconf
Makefile.in's are generated from Makefile.am's by automake

You do not need to call these tools directly.  Today's Autoconf
versions come with a tool called `autoreconf' that will run
everything for you (run it as `autoreconf -vfi').


  configure.ac    ---.                      .---> configure
                     |                      |
  Makefile.am     ---+                      +---> Makefile.in
                     +-->[autoreconf -vfi]--+
  sub/Makefile.am ---+                      +---> sub/Makefile.in
                     |                      |
  ...             ---'                      `---> ...

 Haim> What exactly ( version numbers ) and how should I run ?

The latest versions are

  Autoconf 2.59
  Automake 1.8.5
  Libtool 1.5.6

new releases usually come with fixes to improve portability of
the generated files to some systems, so as a maintainer of a
package that ships such generated files you should really ensure
you use up-to-date autotools.

These three packages are really easy to install from source, so
if they do not come prepackaged with your distribution you could
get them from ftp::/ftp.gnu.org/gnu/
Simply make sure you install Autoconf before the two others.

 Haim> I have tried automake and autoconf, but it seems I do not
 Haim> use them correctly, or that I have old versions.

I can't comment on this if you do not state how you used them
and which version you have.

[...]

 Haim> Did you take into account the config file in the original project
 Haim> which defines label for the preprocessor ? I did not find it in your
 Haim> version with configure.

Well, the point of Autoconf (= automatic configuration) is
indeed not to have users fiddle such config files.

Of course, options like "swap count" or "cache stats" cannot be
enabled automatically; it's up to the user.  I've turned these
into ./configure options, because that is more idiomatic.  (The 
buddy/README file in Spot lists these options.)
-- 
Alexandre Duret-Lutz

Re: [Buddy-developers] bits to merge?

[Haim C. <hai...@us...>]

>By the meantime, here is a patch that fixes the following
>diagnostic output by the CVS version of Bison.  I guess its
>better to fix such things before changing the build.
>
>[...]
>parser.y:67.12: warning: stray `,' treated as white space
>parser.y:67.19: warning: stray `,' treated as white space
>parser.y:67.29: warning: stray `,' treated as white space
>parser.y:67.37: warning: stray `,' treated as white space
>parser.y:69.17: warning: stray `,' treated as white space
>parser.y:69.27: warning: stray `,' treated as white space
>parser.y:70.14: warning: stray `,' treated as white space
>parser.y:71.21: warning: stray `,' treated as white space
>parser.y:71.32: warning: stray `,' treated as white space
>parser.y:71.40: warning: stray `,' treated as white space
>[...]
>

Alexandre,
After upgrading my yacc ( which is actually byacc ) to 1.9-27, the 
warnings disappeared.
Any ideas ?
I will now start work on making the examples directory a regression 
suite. I am now starting to think it will take more time to make BuDDy 
automake+autoconf+libtool compatible.


Haim

Re: [Buddy-developers] bits to merge?

[Alexandre Duret-L. <Ale...@li...>]

[...]

 Haim> After upgrading my yacc ( which is actually byacc ) to 1.9-27, the
 Haim> warnings disappeared.
 Haim> Any ideas ?

Ideas about what?  

Your previous yacc was GNU Bison 1.875, the new one is Berkeley yacc 1.9.  
Obviously the latter silently accepts non-standard %token definitions.
-- 
Alexandre Duret-Lutz

Re: [Buddy-developers] bits to merge?

[Haim C. <hai...@us...>]

I see.
Great ! I prefer to go with the standard. I will apply your patch latter on.
About the change log - it seems I made a mistake by not checking in 
first the original BuDDy.
SF took time to fix my CVS access, so I released the code first.
Anyway, these changes are minor and sum up to std namespace fixes to be 
C++-standard, and renaming examples to be the same as executables.
I will create a ChangeLog every CVS commit I make. Thanks for this point !
The ChangeLog will also contain CVS versions, to keep track of the files.

The next commit I will made will be about:
1. regression scripts
2. Changing documentation files in the project directory to somewhat 
comply with the GNU standard (NEWS,AUTHORS, etc...)

After I commit the changes, I will be glad if other developers can 
review them and send their opinion.
As you see, I am currently put an effort with 'administrative' changes. 
I hope that soon I will start add real code changes.

Haim

Alexandre Duret-Lutz wrote:

>[...]
>
> Haim> After upgrading my yacc ( which is actually byacc ) to 1.9-27, the
> Haim> warnings disappeared.
> Haim> Any ideas ?
>
>Ideas about what?  
>
>Your previous yacc was GNU Bison 1.875, the new one is Berkeley yacc 1.9.  
>Obviously the latter silently accepts non-standard %token definitions.
>  
>

Re: [Buddy-developers] bits to merge?

[Alexandre Duret-L. <ad...@sr...>]

Hi Haim,

Sorry for the delay (it will happen again :)).

>>> "Haim" == Haim Cohen <hai...@us...> writes:

[...]

 Haim> Everyone have read access to the BuDDy repository in
 Haim> S.F. You should first checkout/read the current CVS
 Haim> repository.

I'll generate all my patches against the CVS version of BuDDy.

 Haim> It would be great if you could first merge your changes
 Haim> into the BuDDy 2.3 and test them.

I did that yesterday (i.e., I've imported BuDDy 2.3 into the Spot
CVS repository and merge my changes).  (The result is in
http://spot.lip6.fr/dl/spot-0.0v.tar.gz)

I though it would be peanuts because CHANGES said nothing
changed except the version, but it turned out I had other
changes to cope with, besides the version bump: many examples
were renamed, there is a new way of defining VERSION, ...

I agree such changes do not belong to the CHANGES file (which
looks like what GNU projects call NEWS), yet it would have saved
me time to have a list of such changes, and I guess it would
help other contributors too.  Maybe you could consider using a
ChangeLog to keep track of every changes, like in GNU projects?
(see also http://www.gnu.org/prep/standards_40.html#SEC40)

[...]

 Haim> I think that the build automation with autoconf should be the first
 Haim> thing to integrate into BuDDy.

Wow, you're brave.  I though this would be the most
controversial change!

I have one question before I prepare a patch for this.  Do you
want to keep generated files (configure, Makefile.in, ...) in CVS
or not?  I personally keep them out of CVS, but see
http://sources.redhat.com/automake/automake.html#CVS
before making your mind.


By the meantime, here is a patch that fixes the following
diagnostic output by the CVS version of Bison.  I guess its
better to fix such things before changing the build.

[...]
parser.y:67.12: warning: stray `,' treated as white space
parser.y:67.19: warning: stray `,' treated as white space
parser.y:67.29: warning: stray `,' treated as white space
parser.y:67.37: warning: stray `,' treated as white space
parser.y:69.17: warning: stray `,' treated as white space
parser.y:69.27: warning: stray `,' treated as white space
parser.y:70.14: warning: stray `,' treated as white space
parser.y:71.21: warning: stray `,' treated as white space
parser.y:71.32: warning: stray `,' treated as white space
parser.y:71.40: warning: stray `,' treated as white space
[...]

FWIW, the standard for yacc can be found at
http://www.opengroup.org/onlinepubs/009695399/utilities/yacc.html#tag_04_174_13_03


2004-06-30  Alexandre Duret-Lutz  <ad...@sr...>

	* examples/bddcalc/parser.y: Remove superfluous comas
	causing warnings from CVS Bison.  POSIX requires
	"%token"s to be space-separated, not coma-separated.

Index: examples/bddcalc/parser.y
===================================================================
RCS file: /cvsroot/buddy/buddy/examples/bddcalc/parser.y,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 parser.y
--- examples/bddcalc/parser.y	25 Jun 2004 13:21:45 -0000	1.1.1.1
+++ examples/bddcalc/parser.y	30 Jun 2004 20:09:31 -0000
@@ -14,11 +14,11 @@
 #include "slist.h"
 #include "hashtbl.h"
 #include "parser.h"
-   
+
    /* Definitions for storing and caching of identifiers */
 #define inputTag  0
 #define exprTag   1
-   
+
    struct nodeData
    {
       nodeData(const nodeData &d) { tag=d.tag; name=sdup(d.name); val=d.val; }
@@ -37,7 +37,7 @@
    int linenum;
 
    bddgbchandler gbcHandler = bdd_default_gbchandler;
-   
+
       /* Prototypes */
 void actInit(token *nodes, token *cache);
 void actInputs(void);
@@ -46,7 +46,7 @@
 void actOpr2(token *res, token *left, token *right, int opr);
 void actNot(token *res, token *right);
 void actId(token *res, token *id);
-void actConst(token *res, int); 
+void actConst(token *res, int);
 void actSize(token *id);
 void actDot(token *fname, token *id);
 void actAutoreorder(token *times, token *method);
@@ -57,30 +57,30 @@
 void actQuantVar2(token *res, token *id, token *list);
 void actQuantVar1(token *res, token *id);
 void actPrint(token *id);
- 
+
 %}
 
 /*************************************************************************
    Token definitions
 *************************************************************************/
 
-%token T_id, T_str, T_intval, T_true, T_false
+%token T_id T_str T_intval T_true T_false
 
-%token T_initial, T_inputs, T_actions
-%token T_size, T_dumpdot
-%token T_autoreorder, T_reorder, T_win2, T_win2ite, T_sift, T_siftite, T_none
-%token T_cache, T_tautology, T_print
+%token T_initial T_inputs T_actions
+%token T_size T_dumpdot
+%token T_autoreorder T_reorder T_win2 T_win2ite T_sift T_siftite T_none
+%token T_cache T_tautology T_print
 
-%token T_lpar, T_rpar
+%token T_lpar T_rpar
 %token T_equal
-%token T_semi, T_dot
+%token T_semi T_dot
 
-%right T_exist, T_forall, T_dot
+%right T_exist T_forall T_dot
 %left T_biimp
 %left T_imp
-%left T_or, T_nor
+%left T_or T_nor
 %left T_xor
-%left T_nand, T_and
+%left T_nand T_and
 %right T_not
 
 /*************************************************************************
@@ -212,7 +212,7 @@
 {
    using namespace std ;
    int c;
-   
+
    while ((c=getopt(ac, av, "hg")) != EOF)
    {
       switch (c)
@@ -225,7 +225,7 @@
 	 break;
       }
    }
-   
+
    if (optind >= ac)
       usage();
 
@@ -242,7 +242,7 @@
 
    bdd_printstat();
    bdd_done();
-   
+
    return 0;
 }
 
@@ -279,7 +279,7 @@
    {
       if (names.exists((*i).name))
 	 yyerror("Redefinition of input %s", (*i).name);
-      
+
       (*i).val = bdd_ithvar(vnum);
       hashData hd((*i).name, 0, &(*i));
       names.add(hd);
@@ -299,7 +299,7 @@
 {
    if (names.exists(id->id))
       yyerror("Redefinition of %s", id->id);
-   
+
    nodeData *d = new nodeData(exprTag, sdup(id->id), *expr->bval);
    hashData hd(d->name, 0, d);
    names.add(hd);

-- 
Alexandre Duret-Lutz