System Info (was: Speed of brutus)
Adam R. B. Jack wrote:
And finally, a nit: I see useful information like the name of the java
command ("java") and the Operating System ("posix"), but I don't see the
values of System.getProperties which contains values such as:
java.vm.version=1.4.2_04-b05
java.vm.vendor=Sun Microsystems Inc.
os.arch=i386
os.name=Linux
Hmm. No, not directly. If a project repeatedly fails Gump automatically
turns on ant verbose and/or debug, and maybe this show those values. Is
there a way to list these things (above) without writing some Java?
What's wrong with writing some Java? ;-)
import commands, os, re
TMP_DIR = '/home/rubys/tmp'
JAVA_SOURCE = TMP_DIR + '/sysprop.java'
properties = [
'java.vendor',
'java.version',
'os.name',
'os.arch',
'os.version'
]
source=open(JAVA_SOURCE,'w')
source.write("""
public class sysprop {
public static void main(String [] args) {
for (int i=0; i
os.system('javac ' + JAVA_SOURCE)
os.unlink(JAVA_SOURCE)
cmd='java -cp ' + TMP_DIR + ' sysprop ' + ' '.join(properties)
properties = dict(re.findall('(.*?): (.*)', commands.getoutput(cmd)))
os.unlink(JAVA_SOURCE.replace('.java','.class'))
for (key,value) in properties.items():
print key, "=>", value
- Sam Ruby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: System Info (was: Speed of brutus)
> > Hmm. No, not directly. If a project repeatedly fails Gump automatically > > turns on ant verbose and/or debug, and maybe this show those values. Is > > there a way to list these things (above) without writing some Java? > > What's wrong with writing some Java? ;-) > As I'm sure you are aware ... there is a strong feeling on this list that no Java pre-requisite ought exist, so Gump can be run in a 'clean' environment w/o worrying about CLASSPATHs and such. (Might seem odd for a Java Builder, but Gump may do more/other than Java one day). That said, you seem to have cleverly worked around that. So long as Python Gump generates it, compiles it, and runs it -- I can't see folks objecting. It would (IMHO) be good if you added this code into GumpEnvironment in gumpenv.py, and used some things like self.javaCommand (defaults to 'java', but can be overwritten). If you do it after the check for java and javac, it'd be best. If you could manage to use checkExecutable (which adds the result/output to the GumpEnvironment object as work, and hence shows up in documentation) that would be good. Might I ask that you simply listProperties --- so we can see all, not just these (important) few? You could get the output file from the command, and parse that, if you are interested in having the values. [As you know I like to start verbose and trim backwards, one never knows (it seems) what information might be interesting.] Just and FYI: We have a slight issue with 'tmp', not so much what you've done as what exists. I'd like everything to run in $WORKSPACE/tmp, but some things (like this, are pre-workspace) and dir.tmp is what we ought use. [This is only an issue when we run multiple things in one install, which we don't typically do, but it bugs me.] BTW: Nice addition. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: System Info (was: Speed of brutus)
Folk, When both Stefano and Leo both misinterpret me, I realize I failed to communicate yet again. English truly ought not be counted as my first language (despite being born a Brit. ;-) You triggered off this: > As I'm sure you are aware ... there is a strong feeling on this list that no > Java pre-requisite ought exist, so Gump can be run in a 'clean' environment > w/o worrying about CLASSPATHs and such. But didn't seem to register this, which was part of the same paragraph. > (Might seem odd for a Java Builder, > but Gump may do more/other than Java one day). That said, you seem to have > cleverly worked around that. So long as Python Gump generates it, compiles > it, and runs it -- I can't see folks objecting. where (1) I agree it is odd [I was being polite] for a Java Builder not to want Java, but then explained it and (2) I agree that this worked around any objection. Heck, I never even said they were my objections, I was just trying to summarize what I understood from prior threads/comments on this list. So, for the record (to try to clear up any miscommunication): - I agreed from the start that this was a nice to have. I said that 'ant --debug' might display it, but that I didn't know how to get it directly without writing Java. (Seems others don't either.) - I didn't think this list (from comments I've heard supporting Python Gump) wanted to have to configure/install/environment a Java compiler, but they are happy for Python to auto-discover and use one [clearly]. - I agreed that this solution is consistent with the purist (some might say bootstrap) approach, of starting with pure Python. - All in all, I agreed this was a good solution to the requirement, and fitting within what I understood as the philosophy. That all said, let's please clarify (because it came up again with C, I believe) and I don't want to be assuming that I understand the views of this community: - Do folks want a pure Python Gump, that one can download & run directly? [This solution investigates and locates tools in the environment and uses what it finds, even bootstrapping with those to build more of it's own tools.] - Or, are folks ok with Gump having other language components, and requiring a build prior to being able to run it. Any such build would need to be automated so we could deploy remote Gump agents. (Clearly this approach is achievable, traditional Gump did it, and clearly one could use ant in order to build Java, and perhaps C, etc.) I prefer the Python approach (even if I do get called a purist and not a pragmatist, this time. ;). That said, I could live with either. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: System Info (was: Speed of brutus)
> -Original Message- > From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] > Sent: Saturday, April 03, 2004 7:34 AM > To: Gump code and data > Subject: Re: System Info (was: Speed of brutus) > > > Folk, > > When both Stefano and Leo both misinterpret me, I realize I failed to > communicate yet again. English truly ought not be counted as my first > language (despite being born a Brit. ;-) > > You triggered off this: > > > As I'm sure you are aware ... there is a strong feeling on this > list that > no > > Java pre-requisite ought exist, so Gump can be run in a 'clean' > environment > > w/o worrying about CLASSPATHs and such. > > But didn't seem to register this, which was part of the same paragraph. > > > (Might seem odd for a Java Builder, > > but Gump may do more/other than Java one day). That said, you > seem to have > > cleverly worked around that. So long as Python Gump generates > it, compiles > > it, and runs it -- I can't see folks objecting. > > where (1) I agree it is odd [I was being polite] for a Java Builder not to > want Java, but then explained it and (2) I agree that this worked > around any > objection. Heck, I never even said they were my objections, I was just > trying to summarize what I understood from prior threads/comments on this > list. > > So, for the record (to try to clear up any miscommunication): > > - I agreed from the start that this was a nice to have. I said that > 'ant --debug' might display it, but that I didn't know how to get it > directly without writing Java. (Seems others don't either.) > - I didn't think this list (from comments I've heard supporting > Python Gump) > wanted to have to configure/install/environment a Java compiler, but they > are happy for Python to auto-discover and use one [clearly]. > - I agreed that this solution is consistent with the purist (some > might say > bootstrap) approach, of starting with pure Python. > - All in all, I agreed this was a good solution to the requirement, and > fitting within what I understood as the philosophy. > > That all said, let's please clarify (because it came up again with C, I > believe) and I don't want to be assuming that I understand the > views of this > community: > > - Do folks want a pure Python Gump, that one can download & run directly? > [This solution investigates and locates tools in the environment and uses > what it finds, even bootstrapping with those to build more of it's own > tools.] > > - Or, are folks ok with Gump having other language components, > and requiring > a build prior to being able to run it. Any such build would need to be > automated so we could deploy remote Gump agents. (Clearly this approach is > achievable, traditional Gump did it, and clearly one could use > ant in order > to build Java, and perhaps C, etc.) > > I prefer the Python approach (even if I do get called a purist and not a > pragmatist, this time. ;). That said, I could live with either. +1. To both of the above sentences. ;-) -- Martin Cooper > > regards, > > Adam > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
