moose-devel

[Moose-g3-devel] svn rev 6 (secret agent moose-007)

[Josef S. <js...@ya...>]

The latest rev compiles, but with -DDO_UNIT_TESTS on the command line, I get:

[moose-g3]$ ./moose
Error: parseTriggerList: Could not find field 'reinitOut' on class
'KineticHub'Error: parseTriggerList: Could not find field 'sumTotMolIn' on
class 'KineticHub'
Error: parseTriggerList: Could not find field 'processTabOut' on class
'KineticHub'
Error: parseTriggerList: Could not find field 'reinitTabOut' on class
'KineticHub'
ValueFinfoBase::Error: Unable to initialize class Multi
Checking shell->findElement................ done
Checking shell::createFuncLocal(arg1, arg2)........ done
Checking shell::setFuncLocal(arg1, arg2)...... done
Checking shell::copyFuncLocal(arg1, arg2)...... done
Shell Tests complete

Checking wildcarding: Enumerated list. done
Checking wildcarding: Trees, Types and Field equalities........ done
Checking wildcarding: Numerical Field tests.......... done
Wildcarding tests complete

Testing Shell: parseArgs......... done
Testing Scheduling
doing reset
starting run for 10 sec.
....................Scheduling tests complete
Testing table: ................................... done
Error: PlainMultiConn::disconnectAll
moose > 

All is as expected?

js...@ya...
Software Engineer
Linux/OSX C/C++/Java

Re: [Moose-g3-devel] svn rev 6 (secret agent moose-007)

[Upinder S. B. <bh...@nc...>]

Hi, Joe,
  I guess I got too used to seeing diagnostics scroll over the screen. Th=
e
initial few error messages are easy to fix, and the last one can be
ignored. So all seems well.

-- Upi



On Thu, September 7, 2006 8:43 pm, Josef Svitak said:
> The latest rev compiles, but with -DDO_UNIT_TESTS on the command line, =
I
> get:
>
> [moose-g3]$ ./moose
> Error: parseTriggerList: Could not find field 'reinitOut' on class
> 'KineticHub'Error: parseTriggerList: Could not find field 'sumTotMolIn'=
 on
> class 'KineticHub'
> Error: parseTriggerList: Could not find field 'processTabOut' on class
> 'KineticHub'
> Error: parseTriggerList: Could not find field 'reinitTabOut' on class
> 'KineticHub'
> ValueFinfoBase::Error: Unable to initialize class Multi
> Checking shell->findElement................ done
> Checking shell::createFuncLocal(arg1, arg2)........ done
> Checking shell::setFuncLocal(arg1, arg2)...... done
> Checking shell::copyFuncLocal(arg1, arg2)...... done
> Shell Tests complete
>
> Checking wildcarding: Enumerated list. done
> Checking wildcarding: Trees, Types and Field equalities........ done
> Checking wildcarding: Numerical Field tests.......... done
> Wildcarding tests complete
>
> Testing Shell: parseArgs......... done
> Testing Scheduling
> doing reset
> starting run for 10 sec.
> ....................Scheduling tests complete
> Testing table: ................................... done
> Error: PlainMultiConn::disconnectAll
> moose >
>
> All is as expected?
>
> js...@ya...
> Software Engineer
> Linux/OSX C/C++/Java
>
> -----------------------------------------------------------------------=
--
> Using Tomcat but need to do more? Need to support web services, securit=
y?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Moose-g3-devel mailing list
> Moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-g3-devel
>

[Moose-g3-devel] GENESIS development sites and mailing lists

[Dave B. <db...@do...>]

Jim and Michael,

There are some decisions to be made, which have become more pressing due
to the planned move of the genesis-sim.org server (biad181) from UTHSCSA
to UTSA.  There was a flurry of emails on August 17-18 and August 30-31
between Michael, Joe, Hugo, Upi, and Mando. and me.  I'll do my best to
summarize the situation, and give some opinions.  I've copied this email
to the moose-g3-devel mailing list, so that it will go to everyone who was
involved in this discussion, so that it will be archived, and so that they
can point out omissions or errors in my account of what they said.

As I see it, two separate issues came up:

(1) Should the BABEL mailing list be moved to Sourceforge, as is now
the case with the moose-g3-devel mailing list?

In any case, we should change from the present mailing list software, which
is based on my own perl scripts and requires sendmail to be installed on
the server.  We need a standard, well-supported mailing list manager that
deals automatically with bounced mail, subscribes/unsubscribes, etc.
Michael suggested that there may be problems continuing to use the present
system when the server is moved to the UTSA network.  To me, this is the
most urgent issue, because I don't want to see any interuption of service,
or other proiblems, for our users.

Moving it to Sourceforge would be a very easy solution.  We could simply 
set up a mailing list on the same Sourceforge site that we use for the 
GENESIS 2 source code repository and the user forums.  With the exception 
of a short period of problems with sourceforge (see below), this worked out 
pretty well when we moved the genesis-dev mailing list to Sourceforge as 
"moose-g3-devel".  Not only would this save Michael a lot of work, but it 
would help steer our users to the user forums, which haven't been getting 
as much use as they should.  The GENESIS and BABEL web pages have links to 
this site for getting the latest GENESIS OS/X versions and updates from the 
repository.

The disadvantage is that we would have to educate several hundred apathetic
BABEL members to use a new email address at lists.sourceforge.net,
and if we grow unhappy with Sourceforge, then change it back again.

Alternatively, we could run the same mailing list software that Sourceforge
uses (GNU MailMan) and host and manage it ourselves at UTSA.  That would
be more work for us, but would allow us to keep the same email address
for the GENESIS Users Group.

If I could believe that we are likely to stick with Sourceforge, I wouldn't
object to moving it there, while keeping the BABEL website on the the
genesis-sim.org server.

So this raises some questions for Michael that may help us decide:

When is the move likely to happen?  How much time do we have before we
are forced to do something?

Is it a certainty that we can't run the present combination of perl and
sendmail for a while, until we properly set up the new system?  Is it a
problem of administrators not wanting us to run our own mail server
through the UTSA firewall?

Would these same considerations prevent us from running the MailMan
software ourselves from UTSA?

How big of a deal is it to set up MailMan ourselves?  It seems that once it
is set up, it isn't any easier to manage the mailing list on Sourceforge
than it would be to manage it on our own machine.  The big advantage of
Sourceforge is that they have it all installed and set up.  Is that
correct?

(2) Should the site for the MOOSE and GENESIS 3 development (including the
moose-g3-devel mailing list and source code repository) be moved from the
present Sourceforge site to our own server?

We went through a period of problems with Sourceforge around the beginning
of August.  There were frequent downtimes preventing access to the
repository for the MOOSE source code, and a period when the moose-g3-devel
mailing list wasn't getting archived.  These problems have been resolved
(at least for now).  But this led to some discussion, aside from the issue
of the reliability of Sourceforge, of whether we need more sophisticated
tools for collaborative software development than Sourceforge can offer.

Joe pointed out that many of these needs can be met with a wiki, and it
turns out that one can be used with Sourceforge.  Joe has given Michael the
information needed to set one up at the moose-g3 sourceforge site.  Hugo
argued that, in particular, we need a version control system more flexible
than the ones supported by Sourceforge, that is better for distributed
development from many sites.  Most of the others were happy to continue
with the present Subversion system being hosted at Sourceforge, along with
the mailing list.

Upi pointed out that there would be problems with his funding agencies if
the MOOSE development site were moved from a neutral place like sourceforge
to UTSA, or even to his own site.

This makes it clear the the repository and development site for MOOSE must
stay where it is.  At some point, we might want to split the G3
development site off from that for MOOSE, but that seems awfully premature
to me.  I think that any split should come when we have a public release
of something (with a GUI) that we can honestly call GENESIS 3.  At
present, GENESIS 3 is nothing more than the MOOSE core.

As Upi and Greg have made clear, there is a lot more yet to be done in the
way of MOOSE core code development.  I think it would hurt collaboration,
rather than foster it, to separate the GENESIS 3 site from that of MOOSE at
this early stage.  But, we do need a wiki installed on the moose-g3
Sourceforge site.  Michael, can you work on this?

If any of you want to further discuss the issue of collaborative
development tools for GENESIS/MOOSE, please post your comments to
moo...@li..., so that they will be archived.

Dave

Re: [Moose-g3-devel] GENESIS development sites and mailing lists

[Josef S. <js...@ya...>]

--- Dave Beeman <db...@do...> wrote:

> This makes it clear the the repository and development site for MOOSE must
> stay where it is.  At some point, we might want to split the G3
> development site off from that for MOOSE, but that seems awfully premature
> to me.  I think that any split should come when we have a public release
> of something (with a GUI) that we can honestly call GENESIS 3.  At
> present, GENESIS 3 is nothing more than the MOOSE core.
> 
> As Upi and Greg have made clear, there is a lot more yet to be done in the
> way of MOOSE core code development.  I think it would hurt collaboration,
> rather than foster it, to separate the GENESIS 3 site from that of MOOSE at
> this early stage.

My (twenty-)two cents:

What you call it IS important (see
http://producingoss.com/html-chunk/index.html), but saying there's nothing to
release is inaccurate. I suspect Upi has already been doing real science with
Moose. Dieter may argue that putting some sort of GUI on what's already there
is really just icing (fluff?). Certainly the SLI interface to Moose must
qualify as something you'd consider calling Genesis?

There hasn't really been any feedback on my view of the Big Picture:

1. Moose - core library. Savvy users can put whatever front end on it they
wish, using swig interface. Does NOT provide a front end, even a command line.
It's a library.

2. Genesis3 - provide all the groovy front ends that Jim wants and the nasty
back end that we're stuck with (SLI).

This provides some clear boundaries. Cohesion. Focus. 

The age of the monolithic software app is dead (Thank Crom!), so we should try
to get with the program - at this early stage (actually 3 years ago). So, rip
the SLI back out of Moose and make it communicate through the swig interface.
Easier said than done, but done it must be.

There are obviously a lot of other areas that need to be addressed and
relagated to the right project.


> But, we do need a wiki installed on the moose-g3
> Sourceforge site.  Michael, can you work on this?

There's already one there - working. Just have to figure out what we want to
put under it. http://moose-g3.sourceforge.net/phpwiki/index.php

joe

js...@ya...
Software Engineer
Linux/OSX C/C++/Java

Re: [Moose-g3-devel] GENESIS development sites and mailing lists

[Michael E. <mie...@gm...>]

Comments inline.

On 9/7/06, Dave Beeman <db...@do...> wrote:
> When is the move likely to happen?  How much time do we have before we
> are forced to do something?

The timing of the move is not critical.  The folks that have been
administering the machine genesis-sim.org is on are currently feeling
a bit short handed and have been pushing for me to deal with Jim's
machines personally.  The easiest, and most sensible from my point of
view, way for me to do that is for them to be moved to my existing web
server at UTSA.

> Is it a certainty that we can't run the present combination of perl and
> sendmail for a while, until we properly set up the new system?  Is it a
> problem of administrators not wanting us to run our own mail server
> through the UTSA firewall?

Correct.  Otherwise, I suppose I could simply move the current machine
to UTSA, get it an IP address here and leave things more or less as
they are.  I personally think this is an excelent oportunity to
"upgrade" and move babel to sourceforge, but thats just my 0.02$.

> Would these same considerations prevent us from running the MailMan
> software ourselves from UTSA?

Also correct. Baring some political roughhousing from Jim, UTSA has
again made it clear that they really don't want us to run a mail
server.  For some semi-reasonable reasons...

> How big of a deal is it to set up MailMan ourselves?  It seems that once it
> is set up, it isn't any easier to manage the mailing list on Sourceforge
> than it would be to manage it on our own machine.  The big advantage of
> Sourceforge is that they have it all installed and set up.  Is that
> correct?

I have never set up sendmail or MailMan myself.  This is one of the
semi-reasonable reasons UTSA doesn't want me to run a mail server,
though there are a whole list of mainly security/administrative
overhead issues cited as well.

I am told it is a bit of a pain to get things working smoothly,
especially running a fairly complicated set up like we would need to
accomidate both my in-house organizational email needs as well as
those for Genesis.

Once it was set up, it would be functionally equivalent to
sourceforge's system (probably) but any lists or email addresses would
have the genesis-sim.org name attached to it (which is nice).

> (2) Should the site for the MOOSE and GENESIS 3 development (including the
> moose-g3-devel mailing list and source code repository) be moved from the
> present Sourceforge site to our own server?

As Joe has already set things up on sourceforge (I haven't been able
to connect to it today, myself to look at it) if those arangements are
satisfactory, why rock the boat?  Especially as running the site on
sourceforge makes it slightly easier for arbitrary developers to deal
with the site (since they already have a SF login to check out the
code).  If people are unhappy with the performance of the SF site, we
can move it at a later date.