gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject Re: gump issues under winblows and a suggestion...
Date Tue, 14 Jan 2003 13:11:14 GMT
I did that too.  Turning off McAffee helped.

Unfortuantely all the logon scripts and everything is set up to 
install/enable/etc it..  I'm going to have to get a lot more tricky!

-Andy

dion@multitask.com.au wrote:
> I did a defrag before my tests, so that's not it.
> 
> I'm currently running a test to see that if it's AntiVirus software. In my 
> preliminary tests, turning it off momentarily made the process a lot 
> quicker.
> 
> I'll report back when I've got some real evidence :)
> --
> dIon Gillard, Multitask Consulting
> Blog:      http://www.freeroller.net/page/dion/Weblog
> Work:      http://www.multitask.com.au
> 
> 
> news <news@main.gmane.org> wrote on 12/01/2003 09:52:28 AM:
> 
> 
>>One thing that improved performance for me was defragmenting.
>>Such is practically unheard of in the Linux world...but Microsoft
>>finally caved and admitted their favorite filesystem fragments like a 
>>mutha.  (Which seemed obvious to me from the technical info I saw on 
> 
> it)...
> 
>>-Andy
>>
>>dion@multitask.com.au wrote:
>>
>>>Any ideas on my performance issues under Win2k?
>>>--
>>>dIon Gillard, Multitask Consulting
>>>Blog:      http://www.freeroller.net/page/dion/Weblog
>>>Work:      http://www.multitask.com.au
>>>
>>>
>>>Sam Ruby <rubys@apache.org> wrote on 11/01/2003 06:28:41 AM:
>>>
>>>
>>>
>>>>Andrew C. Oliver wrote:
>>>>
>>>>
>>>>>Ant files are XML and transforming to them seems to be more natural. 
>>>>
>>>Ant 
>>>
>>>
>>>>>isn't the most kind thing in the world for its "Hey this crap broke" 
>>>>>messages, but it is FAR better than cmd.exe or bash in this respect.
>>>>
>>>>Costin already started something along these lines:
>>>>
>>>>http://cvs.apache.org/viewcvs/jakarta-gump/stylesheet/ant-build.xsl
>>>>
>>>>
>>>>
>>>>>Anyhow, I'm just curious what problems there are with this approach. 
>>>>
>>>As 
>>>
>>>
>>>>>my level of pain increases I'll probably experiment with this, but 
>>>>
> I'm 
> 
>>>>>curious if others have thought of this and what the downsides are...
>>>>
>>>>That may be a value use case for a large portion of the portion of the 
>>>
> 
>>>>potential "marketplace" for gump.
>>>>
>>>>Issues:
>>>>
>>>>* I want to fully bootstrap.  In my case, I want to build ant from 
>>>>source and use that version later in the build.
>>>>
>>>>* I want to be able to easily reproduce problems outside of the 
>>>>environment generated by Gump.  Many times I've found it handy to be 
>>>>able to send somebody a shell script or a batch file along with a set 
>>>
> of 
> 
>>>
>>>>jars to reproduce a problem that they are *sure* must be Gump's fault.
>>>>
>>>>* Leaky abstractions.  I've always found ant calling ant to be 
>>>>confusing, particularly when it comes to what properties can be passed 
>>>
> 
>>>>and what can be modified.  But that may just be me.
>>>>
>>>>* Modifying JDK levels and/or bootclasspath.  A persistent requirement 
>>>
> 
>>>>(despite never having been implemented, so take it with a grain of 
>>>
> salt) 
> 
>>>
>>>>is to do a build with different portions of the build at different JDK 
>>>
> 
>>>>levels.  What is a real requirement, however, is the ability to modify 
>>>
> 
>>>>the bootclasspath between job steps.
>>>>
>>>>All presented merely as food for thought.  They reasons may or may not 
>>>
> 
>>>>be applicable to you.  But there is no reason why Gump can't support 
>>>>multiple targets - it already does so with bash and win2k.
>>>>
>>>>- Sam Ruby
>>>>
>>>>
>>>>--
>>>>To unsubscribe, e-mail:   <mailto:gump-unsubscribe@jakarta.apache.org>
>>>>For additional commands, e-mail: <mailto:gump-help@jakarta.apache.org>
>>>>
>>>>ForwardSourceID:NT000A1AE6 
>>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:   <mailto:gump-unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:gump-help@jakarta.apache.org>
>>
> 
>>ForwardSourceID:NT000A1EBE 
> 




Mime
View raw message