oops; I forget to do a reply all on my original answer.
It sounds a bit complicated for the current status of aqsis.
The message log requirements for aqsis is basically some printf or fprintf
and overload in RiError...() functions.
Until aqsis could render safely multiple instance per CPU; I don't see the
gain/points right now.
I agree as soon as aqsis could run on multiplatform/cpus combinaison we will
required some sorts of locking mechanism to access the log report but right
now it is a bit early.
Let first make sure aqsis could run across the network/multicpus ala
prman... where you divide the work of rendering a frame across multiple
machines using the CropWindow() directive and at the end we stich together
the work of multiple machines across the network (with probable remote
display directives ? or teqser or tiff utilities).
If we code somehow some manager (like Alfred) than we probably need
integrate the log4cpp to provide the feedback back to the server.
It is depending more or less of what we want to do with aqsis in the near
Personnaly let complete the overall feature list of renderman (metaball,
curves,procedures/popen()); fix all the bugs; than re-optimized it; make
sure it runs distributed/multi-thread/multi processes/multi-platforms and
----- Original Message -----
From: "Paul Gregory" <pgregory@...>
Sent: May/07/2002 2:20 PM
Subject: RE: [Aqsis-development] (no subject)
> While I agree with what Michel says about it seeming to be abit over the
> at the moment, what with cross process logging etc. The usefulness I see
> that we can have lts of control over the amount and type of debug and
> informational logging output from the command line.
> In my experience of doing optimisation on projects like Aqsis, the
> usefulness of a dedicated profiler is not always that great. Basically
> will point you at bottlenecks you already knew were there, the common
> bottlenecks in this type of application. However using copious amounts of
> logging at various levels does often pinpoint things that would otherwise
> have been missed.
> Combine this usefulness with the fact that we are then using a common
> library for outputting log information from wherever you happen to be in
> project, which means that there isn't an interdependency between Aqsis
> components that there is now, i.e. the ShaderVM has to lonk to the Aqsis
> core library to get logging functionality which seems over the top.
> Good to hear discussion from both sides, lets keep this going and
> settle on an ideal. It may be that there is a better, more lightweight
> solution available for out needs.
> > -----Original Message-----
> > From: aqsis-development-admin@...
> > [mailto:aqsis-development-admin@... Behalf Of
> > Jonathan Merritt
> > Sent: 07 May 2002 06:03
> > To: aqsis-development@...
> > Subject: Re: [Aqsis-development] (no subject)
> > Hi Paul,
> > The SourceForge info on log4cpp says it's closely based upon log4j.
> > While I haven't used log4cpp, I have used log4j as part of a number of
> > larger projects and found it a very nice system. I normally have things
> > set up so that there's a different Logger (Category) for each class,
> > which I find gives particularly nice output information, but other
> > approaches are also possible. The ability to set different loggers to
> > different levels is *really* great when you want to debug just one area
> > of code and don't want "scroll-blindness".
> > (Also, the log4cpp project page says that log4j is at:
> > http://www.log4j.org/
> > This is wrong; it's now moved to:
> > http://jakarta.apache.org/log4j/
> > ...if anyone's wondering...)
> > >Quick question.
> > >
> > >I've been thinking about using a third party logging library to
> > replace the
> > >ad-hoc message/error reporting mechanism we currently use. We could
> > >really beef up the information output. I'm looking at 'log4cpp' at the
> > >moment, it is on SF at http://sourceforge.net/projects/log4cpp.
> > Does anyone
> > >have any comments for or against this.
> > >
> > >Cheers
> > >
> > >PaulG
> > >
> > --
> > Jonathan Merritt, PhD Student.
> > Equine Clinical Research Unit,
> > Faculty of Veterinary Science,
> > The University of Melbourne.
> > _______________________________________________________________
> > Have big pipes? SourceForge.net is looking for download mirrors. We
> > the hardware. You get the recognition. Email Us:
> > _______________________________________________
> > Aqsis-development mailing list
> > Aqsis-development@...
> > https://lists.sourceforge.net/lists/listinfo/aqsis-development
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: bandwidth@...
> Aqsis-development mailing list