Re: gump issues under winblows and a suggestion...

[Andrew C. Oliver]

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

[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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

[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

ForwardSourceID:NT000A1AE6

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

ForwardSourceID:NT000A1EBE

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>