buddy-developers — Participating in BuDDy development

Re: [Buddy-developers] re-entrant branch

[Nikos G. <nik...@gm...>]

Hi Jim,

On 21/07/14 15:56, J.J. Green wrote:
> Just to be clear, my scope for this is just to remove all global
> & file-static variables (this counts as 're-entrant' to me). I'm
> not planning any multi-threadedness or MPI-ness myself (but this
> should make such developments easier).

I see, thanks for clarifying.

> It may be the case that passing around (and dereferencing) all
> of these state pointers has a heavy performance penalty, for
> this reason I don't suggest that this be folded back into the
> main buddy tree at present -- I've made a proper fork:
>
>     https://github.com/jjgreen/rebuddy
>
> and have done the first cut of kernel.c and bddio.c so far
> (comments most welcome)
>
> If things look OK after I've got the re-entrant-ness working
> then I plan to make a unit-test suite, this using the 'legacy
> wrapper using a single global state variable' as suggested earlier
> by John.  So this should be usable in the main tree without
> change if so desired.  That is a month or two down the line though.

Sounds good, it would be very interesting to see how it fares.

Regards
Nikos

Re: [Buddy-developers] re-entrant branch

[J.J. G. <j.j...@gm...>]

Hi John, Nikos,

> John's comment, to me, implies that shifting BDDs from one thread to the 
> other would require new API functions and copying.  If I am correct, 
> then this does not sound too far from process-level concurrency and some 
> form of IPC for moving BDDs around.  Am I missing examples of workloads 
> that would specifically benefit from this?

Just to be clear, my scope for this is just to remove all global
& file-static variables (this counts as 're-entrant' to me). I'm
not planning any multi-threadedness or MPI-ness myself (but this
should make such developments easier).

It may be the case that passing around (and dereferencing) all 
of these state pointers has a heavy performance penalty, for 
this reason I don't suggest that this be folded back into the 
main buddy tree at present -- I've made a proper fork:

   https://github.com/jjgreen/rebuddy 

and have done the first cut of kernel.c and bddio.c so far 
(comments most welcome)

If things look OK after I've got the re-entrant-ness working
then I plan to make a unit-test suite, this using the 'legacy
wrapper using a single global state variable' as suggested earlier
by John.  So this should be usable in the main tree without 
change if so desired.  That is a month or two down the line though.

Cheers

Jim

Re: [Buddy-developers] re-entrant branch

[Nikos G. <nik...@gm...>]

Hi Jim, John,

John's comment, to me, implies that shifting BDDs from one thread to the 
other would require new API functions and copying.  If I am correct, 
then this does not sound too far from process-level concurrency and some 
form of IPC for moving BDDs around.  Am I missing examples of workloads 
that would specifically benefit from this?

Regards,
Nikos

On 20/07/14 20:35, John Whaley wrote:
> Hi Jim,
>
> I think the _r suffix plus the first argument is fine.  The best way to
> do it to avoid code duplication would be to change all of the functions
> to include _r, then add "legacy" wrappers without the _r that pass in a
> pointer to a global struct as the first argument.
>
> Reentrant might be somewhat of a misnomer though because reentrant
> implies thread safety. This would not be thread-safe when operating on
> the same BDD table.
>
> -John
> —
> Sent from Mailbox <https://www.dropbox.com/mailbox> for iPad
>
>
> On Tue, Jul 15, 2014 at 3:00 AM, J.J. Green <j.j...@gm...
> <mailto:j.j...@gm...>> wrote:
>
>     Hi all,
>
>     I've just signed up to buddy-developers, hello!
>
>     I've been thinking about a re-entrant fork of buddy
>     for a while (i.e., create a buddy_state_t with slots
>     for all of the global variables, then produce function_r
>     versions of the buddy functions but taking a pointer to
>     buddy_state_t as the first argument). As this seems to
>     be an alive version of buddy, it's clearly better if I fork
>     from here, ..., but possibly there would be interest in
>     this work as a branch your tree? If so please let me know,
>     if not I'll create the new project on github.
>
>     Yes or no, thanks for all of the buddy bugfixes, this
>     fabulous code needs some love!
>
>     Cheers
>
>     Jim Green
>
>
>
>
>     ------------------------------------------------------------------------------
>
>     Want fast and easy access to all the code in your enterprise? Index and
>     search up to 200,000 lines of code with a free copy of Black Duck
>     Code Sight - the same software that powers the world's largest code
>     search on Ohloh, the Black Duck Open Hub! Try it now.
>     http://p.sf.net/sfu/bds
>     _______________________________________________
>     Buddy-developers mailing list
>     Bud...@li...
>     https://lists.sourceforge.net/lists/listinfo/buddy-developers
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
>
>
>
> _______________________________________________
> Buddy-developers mailing list
> Bud...@li...
> https://lists.sourceforge.net/lists/listinfo/buddy-developers
>

Re: [Buddy-developers] re-entrant branch

[John W. <joe...@gm...>]

Hi Jim,




I think the _r suffix plus the first argument is fine.  The best way to do it to avoid code duplication would be to change all of the functions to include _r, then add "legacy" wrappers without the _r that pass in a pointer to a global struct as the first argument.




Reentrant might be somewhat of a misnomer though because reentrant implies thread safety. This would not be thread-safe when operating on the same BDD table.




-John

—
Sent from Mailbox for iPad

On Tue, Jul 15, 2014 at 3:00 AM, J.J. Green <j.j...@gm...> wrote:

> Hi all,
> I've just signed up to buddy-developers, hello!
> I've been thinking about a re-entrant fork of buddy 
> for a while (i.e., create a buddy_state_t with slots
> for all of the global variables, then produce function_r
> versions of the buddy functions but taking a pointer to
> buddy_state_t as the first argument).  As this seems to
> be an alive version of buddy, it's clearly better if I fork
> from here, ..., but possibly there would be interest in
> this work as a branch your tree?  If so please let me know,
> if not I'll create the new project on github.
> Yes or no, thanks for all of the buddy bugfixes, this 
> fabulous code needs some love!
> Cheers
> Jim Green
>  
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Buddy-developers mailing list
> Bud...@li...
> https://lists.sourceforge.net/lists/listinfo/buddy-developers

[Buddy-developers] re-entrant branch

[J.J. G. <j.j...@gm...>]

Hi all,

I've just signed up to buddy-developers, hello!

I've been thinking about a re-entrant fork of buddy 
for a while (i.e., create a buddy_state_t with slots
for all of the global variables, then produce function_r
versions of the buddy functions but taking a pointer to
buddy_state_t as the first argument).  As this seems to
be an alive version of buddy, it's clearly better if I fork
from here, ..., but possibly there would be interest in
this work as a branch your tree?  If so please let me know,
if not I'll create the new project on github.

Yes or no, thanks for all of the buddy bugfixes, this 
fabulous code needs some love!

Cheers

Jim Green

 

[Buddy-developers] [ buddy-Bugs-3605234 ] Conflicting declarations of variable bddproduced

[SourceForge.net <no...@so...>]

Bugs item #3605234, was opened at 2013-02-18 16:31
Message generated for change (Tracker Item Submitted) made by alpha7
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=662728&aid=3605234&group_id=112658

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: code
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Tautschnig (alpha7)
Assigned to: Nobody/Anonymous (nobody)
Summary: Conflicting declarations of variable bddproduced

Initial Comment:
While compiling your package with our research compiler infrastructure we noticed the following conflicting declarations:

- kernel.c: long int     bddproduced;
- reorder.c: extern int bddproduced;

For any architecture with sizeof(long)!=sizeof(int) this may cause undefined behaviour. In particular, big endian architectures will inevitably cause wrong counter values.

Best,
Michael

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=662728&aid=3605234&group_id=112658

[Buddy-developers] [ buddy-Bugs-3434521 ] bdd_reorder_auto() early exit doesn't work.

[SourceForge.net <no...@so...>]

Bugs item #3434521, was opened at 2011-11-07 06:26
Message generated for change (Tracker Item Submitted) made by ddenisen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=662728&aid=3434521&group_id=112658

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: code
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dmitry (ddenisen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdd_reorder_auto() early exit doesn't work.

Initial Comment:
Found using Coverity static code checker. Inside bdd_reorder_auto(() function using '!bdd_reorder_ready' (line 1629 below) to early exit. However, bdd_reorder_ready is a function name, so bdd_reorder_ready is a function pointer that is never NULL. So the early exit can never be triggered.

1618 int bdd_reorder_ready(void)
1619 	{
1620 	   if (bddreordermethod == BDD_REORDER_NONE  ||  vartree == NULL  ||
1621 	       bddreordertimes == 0  ||  reorderdisabled)
1622 	      return 0;
1623 	   return 1;
1624 	}
1625 	
1626 	   
1627 	void bdd_reorder_auto(void)
1628 	{
Event boolean_controlling_expr_is_constant: controlling expression is constant
1629 	   if (!bdd_reorder_ready)
     	        ^
1630 	      return;


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=662728&aid=3434521&group_id=112658

[Buddy-developers] Building buddy dll

[masoud k. <mas...@ya...>]

Dear all;


How I can configure buddy in order to build .dll library file (when compiling 
with Cygwin)?

Thanks


      

[Buddy-developers] BuDDy Out-of-Range error

[Hasan Q. <ha...@gm...>]

Dear All,

I am a new user of Buddy. I am using JavaBDD which is an inteface to BuDDy.

The following lines of code

bddFactory_ = BDDFactory.init(7000000, 1000000); // these numbers are
subject to change
	System.out.println(elementNumberInP_ * 10 );
	bddFactory_.setVarNum(elementNumberInP_ * 10) ;

Give me the following output:

2380
Exception in thread "main" net.sf.javabdd.BDDException: Value out of range
	at net.sf.javabdd.BuDDyFactory.setVarNum0(Native Method)
	at net.sf.javabdd.BuDDyFactory.setVarNum(BuDDyFactory.java:312)

I would highly appreciate it if you could explain to me what went
wrong. What is the range? How to change it?

Thanks,

Hasan

[Buddy-developers] [ buddy-Bugs-3003205 ] Fdd's do not work correctly when domain size is not a power

[SourceForge.net <no...@so...>]

Bugs item #3003205, was opened at 2010-05-18 09:51
Message generated for change (Settings changed) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=662728&aid=3003205&group_id=112658

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
>Priority: 9
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Fdd's do not work correctly when domain size  is not a power

Initial Comment:
Environment: Winows XP or Windows 7 OS with VS 2008 and VS2010 respectively. 
Problem Description: When fdd_extdomain is called with domain size no being power of 2 the operations on bdd's do not work correctly. Please find attached file as simple example.
output is as follows:
bdd = <0:0/1>
neg bdd = <0:2/3>

The expected result is:
bdd = <0:0/1>
neg bdd = <0:2>
as the domains are {0,1,2}.
In the documentation there is no information that bdd domains need to be powers of 2.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=662728&aid=3003205&group_id=112658

[Buddy-developers] [ buddy-Bugs-3003205 ] Fdd's do not work correctly when domain size is not a power

[SourceForge.net <no...@so...>]

Bugs item #3003205, was opened at 2010-05-18 09:51
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=662728&aid=3003205&group_id=112658

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Fdd's do not work correctly when domain size  is not a power

Initial Comment:
Environment: Winows XP or Windows 7 OS with VS 2008 and VS2010 respectively. 
Problem Description: When fdd_extdomain is called with domain size no being power of 2 the operations on bdd's do not work correctly. Please find attached file as simple example.
output is as follows:
bdd = <0:0/1>
neg bdd = <0:2/3>

The expected result is:
bdd = <0:0/1>
neg bdd = <0:2>
as the domains are {0,1,2}.
In the documentation there is no information that bdd domains need to be powers of 2.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=662728&aid=3003205&group_id=112658

Re: [Buddy-developers] BuDDy and JavaBDD

[Jerry J. <log...@gm...>]

On Wed, Aug 20, 2008 at 7:43 PM, John Whaley <joe...@gm...> wrote:
> Yes, the version of BuDDy that ships with JavaBDD has some optimizations and
> a few new functions.  It would make sense to fold those into the main BuDDy
> distribution.

Thanks, John.  Do you have any plans to fold those changes in in the
near future?

(Not that I'm in any particular hurry.  I've just been thinking about
pushing some BDD-related packages into Fedora, and it would be nice to
have this issue resolved first.)
-- 
Jerry James
http://loganjerry.googlepages.com/

Re: [Buddy-developers] BuDDy and JavaBDD

[John W. <joe...@gm...>]

Yes, the version of BuDDy that ships with JavaBDD has some optimizations and
a few new functions.  It would make sense to fold those into the main BuDDy
distribution.

-John


On Wed, Aug 20, 2008 at 11:50 AM, Jerry James <log...@gm...> wrote:

> I've had an RPM of BuDDy [1] around for awhile.  Recently, I decided
> to create one for JavaBDD [2] as well.  I tried to use the installed
> BuDDy headers & libraries instead of those shipped with JavaBDD, in
> order to be repository-friendly, but failed.  It turns out that the
> BuDDy sources shipped with JavaBDD contain at least 3 new functions in
> the API, as well as a number of other changes.  I don't see this stuff
> in the BuDDy CVS repository.  Are the BuDDy developers aware of the
> differences?
>
> Thanks,
>
> References:
> [1] http://jjames.fedorapeople.org/buddy/
> [2] http://javabdd.sourceforge.net/
> --
> Jerry James
> http://loganjerry.googlepages.com/
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Buddy-developers mailing list
> Bud...@li...
> https://lists.sourceforge.net/lists/listinfo/buddy-developers
>

Re: [Buddy-developers] BuDDy and JavaBDD

[Haim C. <ha...@gm...>]

Thanks Jerry !

I am not aware of any branch from buddy. It could be that JavaBDD was
created before BuDDy was moved to SF.



On 8/20/08, Jerry James <log...@gm...> wrote:
> I've had an RPM of BuDDy [1] around for awhile.  Recently, I decided
> to create one for JavaBDD [2] as well.  I tried to use the installed
> BuDDy headers & libraries instead of those shipped with JavaBDD, in
> order to be repository-friendly, but failed.  It turns out that the
> BuDDy sources shipped with JavaBDD contain at least 3 new functions in
> the API, as well as a number of other changes.  I don't see this stuff
> in the BuDDy CVS repository.  Are the BuDDy developers aware of the
> differences?
>
> Thanks,
>
> References:
> [1] http://jjames.fedorapeople.org/buddy/
> [2] http://javabdd.sourceforge.net/
> --
> Jerry James
> http://loganjerry.googlepages.com/
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Buddy-developers mailing list
> Bud...@li...
> https://lists.sourceforge.net/lists/listinfo/buddy-developers
>

-- 
Sent from Gmail for mobile | mobile.google.com

[Buddy-developers] BuDDy and JavaBDD

[Jerry J. <log...@gm...>]

I've had an RPM of BuDDy [1] around for awhile.  Recently, I decided
to create one for JavaBDD [2] as well.  I tried to use the installed
BuDDy headers & libraries instead of those shipped with JavaBDD, in
order to be repository-friendly, but failed.  It turns out that the
BuDDy sources shipped with JavaBDD contain at least 3 new functions in
the API, as well as a number of other changes.  I don't see this stuff
in the BuDDy CVS repository.  Are the BuDDy developers aware of the
differences?

Thanks,

References:
[1] http://jjames.fedorapeople.org/buddy/
[2] http://javabdd.sourceforge.net/
-- 
Jerry James
http://loganjerry.googlepages.com/

[Buddy-developers] Files have been committed to CVS

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

Update of /cvsroot/buddy/buddy/examples/milner
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv31395/examples/milner

Modified Files:
	.cvsignore 
Log Message:
adding .libs 

[Buddy-developers] Files have been committed to CVS

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

Update of /cvsroot/buddy/buddy/examples/bddtest
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv31395/examples/bddtest

Modified Files:
	.cvsignore 
Log Message:
adding .libs 

[Buddy-developers] Files have been committed to CVS

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

Update of /cvsroot/buddy/buddy/examples/adder
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv31395/examples/adder

Modified Files:
	.cvsignore 
Log Message:
adding .libs 

[Buddy-developers] Files have been committed to CVS

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

Update of /cvsroot/buddy/buddy/examples/fdd
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv16536

Modified Files:
	expected fdd.cxx 
Log Message:
Updating this unit test to print '\n' at the end of the file so it gets
flushed. Seems to fail on Mac.

[Buddy-developers] Files have been committed to CVS

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

Update of /cvsroot/buddy/buddy
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv14742

Modified Files:
	AUTHORS 
Log Message:
Adding Nikos

[Buddy-developers] Files have been committed to CVS

[Nikos G. <ni...@us...>]

Update of /cvsroot/buddy/buddy
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv11855

Modified Files:
	ChangeLog 
Log Message:
Fixed regression test so that it works properly with --enable-cache-stats.

[Buddy-developers] Files have been committed to CVS

[Nikos G. <ni...@us...>]

Update of /cvsroot/buddy/buddy/examples/bddcalc
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv11855/examples/bddcalc

Modified Files:
	parser.yxx expected 
Log Message:
Fixed regression test so that it works properly with --enable-cache-stats.

[Buddy-developers] Files have been committed to CVS

[Nikos G. <ni...@us...>]

Update of /cvsroot/buddy/buddy/examples/bddtest/.libs
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv812/.libs

Removed Files:
	.cvsignore 
Log Message:
Again, fixing .libs

[Buddy-developers] Files have been committed to CVS

[Nikos G. <ni...@us...>]

Update of /cvsroot/buddy/buddy/examples/bddtest
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv30995

Modified Files:
	.cvsignore 
Log Message:
Fix missing .cvsignore entry for .libs

[Buddy-developers] Files have been committed to CVS

[Nikos G. <ni...@us...>]

Update of /cvsroot/buddy/buddy/src
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv24197/src

Modified Files:
	bddop.c reorder.c 
Log Message:
Added an #include "config.h" in files referencing the macro CACHESTATS so that --enable-cache-stats works properly.