Forum OpenACS Development: I've made an interesting commit to the tree...

If you care to download the latest CVS tree for OpenACS 4 (use -d!)
you can play around with my first efforts to get auto-configuration

If you configure your OpenNSD acs.tcl script to use a series of
PostgreSQL database pools and fire up this version of OpenACS 4x, it
will tell you your PostgreSQL driver's correctly configured (assuming
you're running PG 7.1, you'll get an error otherwise) and offer you a
"Next" button.  Press it and it will load the PG acs-kernel datamodel
Dan's created over the past couple of weeks.

At the end it will die because the code will try to feed PG an Oracle
query, but it *does* succeed in loading the acs-kernel datamodel.


If you then reconfigure your acs.tcl file to define Oracle pools, it
will load the Oracle acs-kernel datamodel.  This works, i.e. I've
tested and you can continue forth and complete your installation to
the bitter end (and when you do a "drop user foo cascade" afterwards
in preparation for your next round of testing, you'll understand why
it's a bitter end - it takes Oracle a long time to get rid of the
installation, at least on my laptop).

I'll post momentarily on the next steps that need to happen, and
tomorrow I'll post more in regard to thoughts about how to get folks
busy working on the project sooner rather than later.

Posted by Don Baccus on
Oh, one thing:

At the moment there's config magic to tell the bootstrapper where to
find the pgsql bin directory.

Assuming you've named your postgres driver "postgres", ala

ns_param postgres


ns_param pgbin "/home/pgtest/install/bin"

(which is where 7.1 lives on my system, you get the idea...)

Note that "drivers" is plural and "driver" singular in the above example.

Before release (beta or otherwise) I intend to get the toolkit to look
for the proper PG environment variables and to find psql there by
default.  The above will still be useful for overriding defaults, i.e.
I run 7.0 and 7.1 on the same machine and share a user account for my
various OpenNSD instances so being able to override the default's handy.

three things.

1. this is very cool.

2. the permissions are wrong on some directory, traceback:
cvs server: Updating packages/acs-kernel/sql/oracle
cvs server: failed to create lock directory in repository
`/cvsroot/openacs-4/packages/acs-kernel/sql/oracle': Permission
cvs server: failed to obtain dir lock in repository
cvs [server aborted]: read lock failed - giving up

3. for those with cvs checkouts already don't forget to do a
cvs update -P -d (to get new directories and remove old files)

Posted by Don Baccus on
1.  Thanks!  It will be even cooler when the query dispatcher and the
APM datamodel loader for different RDMBS engines are working.

2.  Help?  Ben?  Arjun?  I just did "cvs commit".  Since I have an
account on the machine, I made my test copy using that account and had
no problem, so this perhaps is a problem with the pserver????

3.  My personal project's cvs tree is set up such that cvs update
alone removes no-longer-needed files, but that was probably by
accident and due to my knowing next-to-nothing about CVS, so CVS -P is
probably a good idea.

Posted by Ken Kennedy on
I got the same error msg as Kapil when attempting a checkout...(boy, I was excited 'til I hit THAT, though...*grin*). Take a look at the permissions on the '/cvsroot/openacs-4/packages/acs-kernel/sql/oracle' looks like the read lock is failing due to a permissions issue. (See for some general info on CVS locks)
Posted by Don Baccus on
If I get time before leaving town I'll take a look, otherwise Ben or Dan need to.  Ben set up CVS so maybe he'll have an idea.

I just did a cvs add of the new directory...neither of you had problems with the new "bootstrap" directory, though?  Strange...

7: anon CVS Problems (response to 1)
Posted by Arjun Sanyal on
I've changed the permissions on the directories that were failing.
Anonymous checkouts should be working again. I just tested that successfully.
Great to see this! Looking forward to installing it.

While browsing the docs I noticed some graphics were broken
(in workflow package) which are not broken in ACS classic.

File sizes are larger than originals. Suspect RCS is adding
version info. Need to exclude .jpg, .gif, .pdf and any other
such "binaries". Can probably wait until moving to 4.2 beta to
refresh the originals, but cause should be identified now and
corrected now in case it's something worse or affects something
more critical than pictures.


1. What's the guesstimate for moving to 4.2 beta. (Wondering
whether to start printing stuff now or wait)

2. Anyone planning to do the workflow package? (It will be
needed for ecommerce - see the order processing example in
concepts. I assume other stuff needed for ecommerce like
mail and notifications will be done anyway for general core.)

Posted by Ken Kennedy on
Checkout is working...excellent! Thanks for the fix!
Posted by Don Baccus on
Albert ... the tree should be 4.2 beta ... the core stuff I've been
working on is certainly different to some degree than the 4.1 stuff I
started on (i.e. I had a minor fold job to do).  If some files haven't
been updated we need to notify Ben and Arjun.

Have you verified that the broken graphics you talk about work on aD's
4.2 beta release, i.e. that we're the ones who broke them?  It's
possible they just didn't get into the CVS tree...


The broken graphics in workflow package were noticed from
continuing local browse through the html docs in openacs-4 checkout
after having started similar local browse from acs classic 4.2 beta
apm download from aD repository. I don't have anything currently
installed and am not planning to install Oracle. For all I know the
problem could have been in the earlier classic version used to do
openacs-4 (which I've never looked at), and got fixed in 4.2 classic beta tarball. To check, I've just now downloaded acs-workflow-4.0.1
from After rename of file from .apm to .tgz and extracting,
I find that www/doc/order_wf.jpg is 48,849 bytes and works and
user_reg_workflow.jpg is 41,637 bytes and works. These are identical
to (working) files from acs-4-2-beta apm.

I have also just done separate checkout from openacs-4...workflow...
again and got larger file sizes of 49,251 and 41,800 respectively -
both *not* working.

NOTE: I am using WinCVS 1.1b17 (on Win98) and am *not* familiar
with it and have not done anything special at this end to tell
it about .jpg and .gif etc. It may be doing line ending conversion
or something.

If the graphics from cvs work for you then problem is at my end. Otherwise check the file sizes.

BTW Take a look at those 2 graphics anyway. Reason I've been
going through the workflow docs is that it seems to be in core
because it really is "core" and not just a special purpose add
on. Looks like central to design of the "real" ecommerce package
and also useful for user registration and many other things. It
might need to be bumped up in priority as useful even for more
central concerns like CMS and there's a *lot* in it, which also
needs background reading of the extensive docs on what it's
about so there could be a lead time on critical path if not
started early.

PS I've still only got part way through browsing just the sql
for the openacs-4 kernel. It's a massive job just coming to grips
with it by reading. Congratulations on the work you've been doing
to port it - and THANKS!!!

try a "cvs log" on the offending files. Binary files should have
been added with a "cvs add -kb" to suppress keyword expansion (and CR/CRLF translation). if they keyword expansion mode isn't "b", then the problem is as you suspect. This just bit me on one of my own CVS
repositories today

cvs maintainers, you can do a "cvs admin -kb <offending file>" to fix.

Apologies if this isn't the problem.

Better yet, add

 *.gif -k 'b'
to your cvswrappers file and then no one will have to worry about it.
I have a whole slew of binary files in mine.