Re: [event] PooledExecutor locking up?

On Thursday, June 12, 2003, at 06:52 PM, Shash Chatterjee wrote: I am also noticing (when debugging using Eclipse under Win-XP as well as Solaris) that there is a new thread being created rapidly about once a second and which dies (at least disappears) quickly. Whenever I've been able to suspe

[RT] Minimizing stack traces on startup.

Hi, Leif, Berin and all! Looks like the question of minimizing the stack traces is still on the table. To me it splits into the following sub-areas: 1) AbstractContainer throws a CompositeException from initialize() Good. AbstractContainer can be taught not to log anything itself. (

Re: Going going gone!

Thank you for this. I for one have followed the problems within Avalon with a heavy heart for some time but do not fault anyone. I value the work that Peter did on LogKit as of particular significance to me at the time. And, if he decides to leave the Avalon community, I will miss his EMail signa

Re: [event] PooledExecutor locking up?

Pete, I am also noticing (when debugging using Eclipse under Win-XP as well as Solaris) that there is a new thread being created rapidly about once a second and which dies (at least disappears) quickly. Whenever I've been able to suspend it, the thread stack is: Thread [Thread-293] (Suspended

cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/command CommandManager.java

atagunov2003/06/12 15:43:36 Modified:event/src/java/org/apache/excalibur/event/command CommandManager.java Log: Make use of Null..SHARED_INSTANCE Revision ChangesPath 1.30 +1 -1 avalon-excalibur/event/src/java/org/apache/excalibur/event/

cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/command NullCommandFailureHandler.java

atagunov2003/06/12 15:42:48 Modified:event/src/java/org/apache/excalibur/event/command NullCommandFailureHandler.java Log: added SHARED_INSTANCE Revision ChangesPath 1.2 +1 -0 avalon-excalibur/event/src/java/org/apache/excalibur/event/c

Re: face to face :)

Privet, Anton! On Thu, 12 Jun 2003 22:22:38 +0400 (Subject: face to face :)) Anton Tagunov <[EMAIL PROTECTED]> wrote: > http://cvs.apache.org/~atagunov > > -anton Oh, You got it! Pazdravryayu vas! (Sorry if I misspelled in transliteration) As I said before, I am looking forward to see the Russ

[event] PooledExecutor locking up?

It appears that my PooledExecutor is locking up... From a thread dump: "Thread-6" prio=1 tid=0x0x8637fc8 nid=0x1292 in Object.wait() [89bcd000..89bcd830] at java.lang.Object.wait(Native Method) - waiting on <0x4dde3d28> (a EDU.oswego.cs.dl.util.concurrent.LinkedNode) at

Re[2]: [Fortress] Minimizing stack traces on startup.

Hello Leif! 1) The matter has attracted my interest too. Please tell me, what did you end up with? If I understand correctly you wanted your system not to startup if any of the components failed to initialize and you wanted the log to be quite, right? So, what do you do now? Pass in your own Com

Re: [VOTE] split sources into src/api and src/impl

Niclas Hedhman wrote: On Wednesday 11 June 2003 12:32 pm, Leo Simons wrote: I think this is a good idea as it enforces clean seperation in a logical way In a true Avalon spirit of SoC. Could I add, to have a 3rd directory/jar, avalon-framework-compat-${v}.jar, where you stuff all the deprecated

Re: [VOTE] split sources into src/api and src/impl

Niclas Hedhman wrote: On Wednesday 11 June 2003 12:32 pm, Leo Simons wrote: I think this is a good idea as it enforces clean seperation in a logical way In a true Avalon spirit of SoC. Could I add, to have a 3rd directory/jar, avalon-framework-compat-${v}.jar, where you stuff all the deprecat

cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/command TPSPThreadManager.java

bloritsch2003/06/12 13:04:26 Modified:event/src/java/org/apache/excalibur/event/command TPSPThreadManager.java Log: Update the docs Revision ChangesPath 1.30 +37 -1 avalon-excalibur/event/src/java/org/apache/excalibur/event/command/TPSPTh

cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/command TPSPThreadManager.java

bloritsch2003/06/12 12:55:10 Modified:event/src/java/org/apache/excalibur/event/command TPSPThreadManager.java Log: TPSPThreadManager is written, but it needs to be validated and refactored. Perhaps the two classes (SourceRunner and SourceDequeueInterceptor)

Re: Re[2]: face to face :)

On Thursday, June 12, 2003, at 03:03 PM, Anton Tagunov wrote: Very impressed! :-)) Could you please specify the GMT +/- on the time so that it will really be a killer? done. est5edt (florida, usa). -pete - To unsubscribe, e-mail:

Re[2]: face to face :)

Very impressed! :-)) Could you please specify the GMT +/- on the time so that it will really be a killer? -Anton :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: avalon-excalibur/monitor/src/java/org/apache/avalon/excalibur/monitor/impl AbstractMonitor.java

cziegeler2003/06/12 11:57:45 Modified:logger/src/java/org/apache/avalon/excalibur/logger/decorator LoggerManagerDecorator.java logger/src/java/org/apache/avalon/excalibur/logger/logkit LogKitConfHelper.java log

cvs commit: avalon-logkit/src/java/org/apache/log/output/jms AbstractJMSTarget.java

cziegeler2003/06/12 11:56:41 Modified:src/java/org/apache/log/output/jms AbstractJMSTarget.java Log: Organizing imports Revision ChangesPath 1.9 +1 -3 avalon-logkit/src/java/org/apache/log/output/jms/AbstractJMSTarget.java Index: AbstractJMSTarget.java

cvs commit: avalon-sandbox/merlin/merlin-spi/src/java/org/apache/avalon/merlin/kernel Kernel.java

cziegeler2003/06/12 11:56:21 Modified:merlin/assembly/src/java/org/apache/avalon/assembly/lifecycle/impl DefaultDeploymentService.java AvalonContextualizer.java DefaultContextualizer.java merlin/merlin

Re: face to face :)

you look russian! :D Anton Tagunov wrote: http://cvs.apache.org/~atagunov -anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: Going going gone!

Anton Tagunov wrote: A very sad moment. Have there been any real disagreements except the statement that Peter is not part of the team? The 4 positive answers should have been more important then some silly words shouldn't they? Of course there were. Such a heavy action is never taken lightly or

Re: [event] Multiple TPCThreadManagers in a JVM

On Thursday, June 12, 2003, at 10:46 AM, Berin Loritsch wrote: The FortressConfig class allows you to pass in your own ThreadManager. I highly recommend that you do so when you have multiple Fortress containers. It only allowed the passing in of a Sink before, updated to allow ThreadManager too

Re: face to face :)

On Thursday, June 12, 2003, at 02:22 PM, Anton Tagunov wrote: http://cvs.apache.org/~atagunov -anton http://fotap.org/webcam/ :) -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED

cvs commit: avalon-excalibur/fortress/src/java/org/apache/avalon/fortress/util ContextManager.java

proyal 2003/06/12 11:45:54 Modified:fortress/src/java/org/apache/avalon/fortress/util ContextManager.java Log: Initialize thread manager independently of command sink Revision ChangesPath 1.47 +43 -21 avalon-excalibur/fortress/src/java/or

cvs commit: avalon-excalibur/fortress/src/java/org/apache/avalon/fortress/util FortressConfig.java

proyal 2003/06/12 11:44:46 Modified:fortress/src/java/org/apache/avalon/fortress/util FortressConfig.java Log: Allow ThreadManager to be specified Revision ChangesPath 1.20 +7 -1 avalon-excalibur/fortress/src/java/org/apache/avalon/fort

Re: Maven/Gump integration issue

Berin Loritsch wrote: Leo, the build.xml file seems to not include basic dependencies like Avalon Framework. Does this still happen for GUMP integration? yep. Gump sets up the system classpath to include dependencies based on the gump descriptor. Any classpath definitions in your buildfiles are

cvs commit: avalon-excalibur/fortress/src/java/org/apache/avalon/fortress/impl/role Role2MetaInfoManager.java

proyal 2003/06/12 11:44:06 Modified:fortress/src/java/org/apache/avalon/fortress/impl/role Role2MetaInfoManager.java Log: Allow a parent to be specified Revision ChangesPath 1.6 +9 -2 avalon-excalibur/fortress/src/java/org/apache/avalo

cvs commit: avalon-excalibur/fortress/src/java/org/apache/avalon/fortress/impl/factory ProxyManager.java

proyal 2003/06/12 11:43:27 Modified:fortress/src/java/org/apache/avalon/fortress/impl/factory ProxyManager.java Log: Check for presence of BCEL and the wrapper. In case fortress is build w/o BCEL but run with it Revision ChangesPath 1.4 +1

Re: Going going gone!

A very sad moment. Have there been any real disagreements except the statement that Peter is not part of the team? The 4 positive answers should have been more important then some silly words shouldn't they? ("silly" as in "silly bullet") Very upsetting. - Anton -

face to face :)

http://cvs.apache.org/~atagunov -anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: avalon/fortress/container maven.xml

bloritsch2003/06/12 11:24:22 Modified:fortress/container maven.xml Log: update the maven.xml Revision ChangesPath 1.2 +2 -2 avalon/fortress/container/maven.xml Index: maven.xml === RCS fil

Maven/Gump integration issue

Leo, the build.xml file seems to not include basic dependencies like Avalon Framework. Does this still happen for GUMP integration? I updated the project and gump descriptors so that the proper dependencies are listed. For the record, for every "project" like excalibur-instrument, excalibur-instru

cvs commit: avalon/fortress/container project.xml

bloritsch2003/06/12 10:49:51 Modified:buildsystem/gump-integration/project avalon-fortress-container.xml fortress/container project.xml Log: hopefully fix the problem with instrument management Revision ChangesPath 1.4 +35 -27

Avalon France - pub culture

How about a Parisian pub-event at the end of the month - Friday 27 June 8:00 PM for example? If you are in this part of the world (resident or transient) - post a message! Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net Sent via James running under Merlin as

Re: cvs commit: avalon-phoenix/src/java/org/apache/avalon/phoenix/components/classloaderDefaultLoaderResolver.java

Peter Royal wrote: On Thursday, June 12, 2003, at 11:17 AM, [EMAIL PROTECTED] wrote: Can you fix your IDE/environment to not mange the line endings? Makes it hard to see exactly what was changed :) If you are doing a diff before checkin to see what the changes are, just make sure that the

Re: Maven GUMP Failure for Fortress-Container

Berin Loritsch wrote: Leo, congrats on your hard work. :D It appears that you are missing a dependency on Instrument-Manager. (...) Ah, yes, apparently so! Are the new GUMP definitions in the GUMP CVS or are they generated dynamically? If they are generated dynamically, could you give me a rund

cvs commit: avalon-phoenix/src/java/org/apache/avalon/phoenix/components/classloader DefaultLoaderResolver.java

bloritsch2003/06/12 08:24:46 Modified:src/java/org/apache/avalon/phoenix/components/classloader DefaultLoaderResolver.java Log: fix formatting Revision ChangesPath 1.4 +35 -34 avalon-phoenix/src/java/org/apache/avalon/phoenix/components/c

Re: cvs commit: avalon-phoenix/src/java/org/apache/avalon/phoenix/components/classloader DefaultLoaderResolver.java

On Thursday, June 12, 2003, at 11:17 AM, [EMAIL PROTECTED] wrote: bloritsch2003/06/12 08:17:10 Modified: src/java/org/apache/avalon/phoenix/components/classloader DefaultLoaderResolver.java Log: Fix GUMP build. We need to get rid of our need on the class as

cvs commit: avalon-excalibur/fortress/src/java/org/apache/avalon/fortress/util ContextManager.java

proyal 2003/06/12 08:19:21 Modified:fortress/src/java/org/apache/avalon/fortress/util ContextManager.java Log: * Remove unused imports * Add a SourceResolver if the parent SM doesn't have one Revision ChangesPath 1.46 +4 -10 avalon-exc

cvs commit: avalon-phoenix/src/java/org/apache/avalon/phoenix/components/classloader DefaultLoaderResolver.java

bloritsch2003/06/12 08:17:10 Modified:src/java/org/apache/avalon/phoenix/components/classloader DefaultLoaderResolver.java Log: Fix GUMP build. We need to get rid of our need on the class as it stands, and refactor it into something more friendly. Spice Cl

Re: [event] Multiple TPCThreadManagers in a JVM

On Thursday, June 12, 2003, at 10:46 AM, Berin Loritsch wrote: The FortressConfig class allows you to pass in your own ThreadManager. I highly recommend that you do so when you have multiple Fortress containers. Ah, good :) I'll upgrade. And upon further investigation, it appears that my problem

RE: [event] Multiple TPCThreadManagers in a JVM

The FortressConfig class allows you to pass in your own ThreadManager. I highly recommend that you do so when you have multiple Fortress containers. > -Original Message- > From: Peter Royal [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 12, 2003 10:40 AM > To: Avalon List > Subject: [e

[event] Multiple TPCThreadManagers in a JVM

I'm curious if anyone has any experience with multiple TPCThreadManager instances inside of a single JVM? I have three instances at the moment, one for event management of my own, and two others that embedded fortress containers spawn. What I am noticing, is that frequently, on a 1.4.1_02 JVM u

cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/command TPSPThreadManager.java

bloritsch2003/06/12 07:36:16 Modified:event/src/java/org/apache/excalibur/event/command TPSPThreadManager.java Log: Ensure the maximium thread count is properly adjusted. Revision ChangesPath 1.28 +5 -1 avalon-excalibur/event/src/java/or

cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/command TPSPThreadManager.java

bloritsch2003/06/12 07:35:06 Modified:event/src/java/org/apache/excalibur/event/command TPSPThreadManager.java Log: Allow for a margin of error. I.e. The threshold accounts for enqueued items +/- a margin. If the queue size is greater than the threshold +

cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/event/command TPSPThreadManager.java

bloritsch2003/06/12 07:06:52 Modified:event/src/java/org/apache/excalibur/event/command TPSPThreadManager.java Log: Add DequeueInterceptor for the TPSPThreadManager--maybe we can get this one working soon. Revision ChangesPath 1.26 +63 -0

cvs commit: avalon-excalibur/event/src/java/org/apache/excalibur/util SystemUtil.java

bloritsch2003/06/12 06:49:23 Modified:event/src/java/org/apache/excalibur/event/command TPCThreadManager.java event/src/java/org/apache/excalibur/util SystemUtil.java Log: Start the pooled executor with defaults that will allow it to grow on dem

Re: Going going gone!

Berin Loritsch wrote: For those who are concerned that support for Phoenix will disappear dont worry. At this stage we are planning on continuing development elsewhere so you will not be left high and dry. More details will follow when things are more concrete. Phoenix will continue to be sup

Maven GUMP Failure for Fortress-Container

Leo, congrats on your hard work. It appears that you are missing a dependency on Instrument-Manager. Are the new GUMP definitions in the GUMP CVS or are they generated dynamically? If they are generated dynamically, could you give me a rundown so that I can help you with the process?

Re: Going going gone!

Ulrich Mayring wrote: Peter Donald wrote: For those who are concerned that support for Phoenix will disappear dont worry. At this stage we are planning on continuing development elsewhere so you will not be left high and dry. More details will follow when things are more concrete. So Phoenix

Re: Going going gone!

I am responding with the official side of the Avalon team. Peter Donald wrote: Hi, For those who don't know yet I was kicked out of Avalon on Sunday. I have not been allowed to be a member of the group for a long time but now it is official. That basically means I have no commit access here any

Re: Going going gone!

Peter Donald wrote: > > For those who don't know yet I was kicked out of Avalon on Sunday. I have not > been allowed to be a member of the group for a long time but now it is > official. That basically means I have no commit access here anymore and wont > be able to participate any longer. of

Re: Going going gone!

On 12/06/2003 14:09 Steven Noels wrote: On 12/06/2003 11:33 Ulrich Mayring wrote: So Phoenix will go out of Avalon, but retain the Apache license? Or will it get a new license? Or will there be a fork and users have to decide which branch to use? If development on Phoenix continues outside Ap

Re: Going going gone!

On 12/06/2003 11:33 Ulrich Mayring wrote: So Phoenix will go out of Avalon, but retain the Apache license? Or will it get a new license? Or will there be a fork and users have to decide which branch to use? If development on Phoenix continues outside Apache CVS (which is perfectly legal), it wi

Re: [Fortress] Minimizing stack traces on startup.

On Thursday, June 12, 2003, at 12:29 AM, Leif Mortenson wrote: Rather than this: getLogger().error( msg, e ); I do this: getLogger().error( msg + " : " + e.getMessage() ); getLogger().debug( "Stack Trace:", e ); Or something along those lines. It really depends on the context. You've found that t

Re: Going going gone!

On 12/06/2003 12:43 Stephen McConnell wrote: I'm just noting that it could be helpful to request a PMC point-of-view as an input to that discussion. And I just wanted to note that, from being subscribed to avalon-dev only, one might get the feeling some stuff is silently handled on that PMC lis

Re: Going going gone!

Steven Noels wrote: On 12/06/2003 12:35 Stephen McConnell wrote: It may be helpful to post an email to the PMC requesting clarification on the above questions. The PMC email address is [EMAIL PROTECTED] Why can't this be asked & discussed on the -dev list? There is nothing stopping a dis

[GUMP] PRE-REQ FAILED for phoenix-example-demo

This email is autogenerated from the output from: Missing prereq /home/rubys/jakarta/avalon-cornerstone/build/lib/corne

[GUMP] PRE-REQ FAILED for phoenix-example-testserver

This email is autogenerated from the output from: Missing prereq /home/rubys/jakarta/avalon-cornerstone/build/lib

[GUMP] PRE-REQ FAILED for phoenix-example-pdk

This email is autogenerated from the output from: Missing prereq /home/rubys/jakarta/avalon-phoenix/target/lib/phoenix-p

[GUMP] Build Failure - avalon-phoenix

This email is autogenerated from the output from: Buildfile: build.xml init-windows-nt: init-windows-2000: init-windows-xp

Re: Going going gone!

On 12/06/2003 12:35 Stephen McConnell wrote: It may be helpful to post an email to the PMC requesting clarification on the above questions. The PMC email address is [EMAIL PROTECTED] Why can't this be asked & discussed on the -dev list? -- Steven Noelshttp://outertho

Re: Going going gone!

Ulrich Mayring wrote: Peter Donald wrote: For those who are concerned that support for Phoenix will disappear dont worry. At this stage we are planning on continuing development elsewhere so you will not be left high and dry. More details will follow when things are more concrete. So Phoen

Re: Going going gone!

-1 I would vote for you to stay but this is not a votable issue and I am not a committer, I would like to thank you for you for the quality ideas, arguments and software you have produced for Apache over the last few years, your insight will be sorely missed. regards pb... So long and thanks f

Re: [VOTE] split sources into src/api and src/impl

Niclas Hedhman wrote: On Wednesday 11 June 2003 12:32 pm, Leo Simons wrote: I think this is a good idea as it enforces clean seperation in a logical way In a true Avalon spirit of SoC. Could I add, to have a 3rd directory/jar, avalon-framework-compat-${v}.jar, where you stuff all the

Re: Going going gone!

Peter Donald wrote: For those who are concerned that support for Phoenix will disappear dont worry. At this stage we are planning on continuing development elsewhere so you will not be left high and dry. More details will follow when things are more concrete. So Phoenix will go out of Avalon, bu

Going going gone!

Hi, For those who don't know yet I was kicked out of Avalon on Sunday. I have not been allowed to be a member of the group for a long time but now it is official. That basically means I have no commit access here anymore and wont be able to participate any longer. I spent just under four years

cvs commit: avalon-sandbox/merlin/meta/src/java/org/apache/avalon/meta/info/builder TypeBuilder.java

mcconnell2003/06/12 01:18:51 Modified:merlin/meta/src/java/org/apache/avalon/meta/info/builder TypeBuilder.java Log: Update TypeBuilder javadoc. Revision ChangesPath 1.5 +9 -3 avalon-sandbox/merlin/meta/src/java/org/apache/avalon/meta/i

cvs commit: avalon-sandbox/merlin/merlin-platform/tutorials/meta/src/java/org/apache/avalon/playground Primary.java PrimaryService.java Secondary.java SecondaryService.java

mcconnell2003/06/12 00:44:41 Added: merlin/merlin-platform/tutorials/meta .cvsignore README.TXT maven.xml project.xml merlin/merlin-platform/tutorials/meta/src/java/org/apache/avalon/playground Primary.java PrimaryService.

cvs commit: avalon-sandbox/merlin/merlin-platform/tutorials/meta/src/java/org/apache/avalon/playground - New directory

mcconnell2003/06/12 00:43:48 avalon-sandbox/merlin/merlin-platform/tutorials/meta/src/java/org/apache/avalon/playground - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL P

cvs commit: avalon-sandbox/merlin/merlin-platform/tutorials/meta/src/java/org/apache/avalon - New directory

mcconnell2003/06/12 00:43:33 avalon-sandbox/merlin/merlin-platform/tutorials/meta/src/java/org/apache/avalon - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: avalon-sandbox/merlin/merlin-platform/tutorials/meta/src/java/org/apache - New directory

mcconnell2003/06/12 00:43:24 avalon-sandbox/merlin/merlin-platform/tutorials/meta/src/java/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: avalon-sandbox/merlin/merlin-platform/tutorials/meta/src/java/org - New directory

mcconnell2003/06/12 00:43:14 avalon-sandbox/merlin/merlin-platform/tutorials/meta/src/java/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: avalon-sandbox/merlin/merlin-platform/tutorials/meta/src/java - New directory

mcconnell2003/06/12 00:43:07 avalon-sandbox/merlin/merlin-platform/tutorials/meta/src/java - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: avalon-sandbox/merlin/merlin-platform/tutorials/meta/conf - New directory

mcconnell2003/06/12 00:42:47 avalon-sandbox/merlin/merlin-platform/tutorials/meta/conf - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: avalon-sandbox/merlin/merlin-platform/tutorials/meta/src - New directory

mcconnell2003/06/12 00:42:39 avalon-sandbox/merlin/merlin-platform/tutorials/meta/src - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: avalon-sandbox/merlin/merlin-platform/tutorials/meta - New directory

mcconnell2003/06/12 00:42:31 avalon-sandbox/merlin/merlin-platform/tutorials/meta - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cool! Will this allow us to have DefaultConfigurationBuilder.build(Source ) ?

Anton Tagunov wrote: DefaultConfigurationBuilder.build( Source ) where Source comes from excalibur-sourceresolve it wasn't possible to build this before but in future especially if maven will rule the world here it seems that it won't be a problem to have a dependency chain framework-impl -

Re: merlin's meta tags and a bigger LCD

Hi Leo: Good to see your hard at work! Some agreements and some disagreements in-line. ;-) Leo Simons wrote: Stephen McConnell wrote: Only works if we cater for all of the requirements. I.e. the LCD approach fails the usability test. it fails some tests, not all. A LCD is always less usab