Bootstrapping Gump (was: Re: System Info)
Leo Simons wrote: being a pragmatist, if I can "apt-get install gump", that would be perfect, regardless of the dependencies. In case you don't know, apt could download all those dependencies before installing gump. I know that Ant is supposed to be a Java build system but these days it is so powerful that you could easily use it to download everything. Then you would have a two stage bootstrap: 0adownload Java if not available (probably already on the system) 0bset Java path (probably already set) 0cdownload Ant if not available (probably supplied with Java) 0dset Ant path (probably already set) 1download bootstrap-gump.xml 2 type "ant -f bootstrap-gump.xml" You could additionally provide a .jnlp file on the gump website that would do 0c, 0d, 1 and 2 automatically for those that have Java WebStart available. I understand the rationale of not wanting to using non-Java to build Java projects, but can't see any reason to avoid Java for the installation process. After all, Java needs to be in the tin when we come to build (until (fi*) Gump supports non-java builds) and the whole purpose of Java is that it abstracts away other language and OS differencies. The alternative would seem to be: support seperate bootstraps for RedHat, Debian, SUSE, Solaris, MacOS X, Windows and so on write a bootstrap for Gump in python write a python version of Ant (perhaps only supporting the tags we need to use to bootstrap Gump) -- Michael [*1] fi - future tense "if" - is there a proper word for this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: System Info
Adam R. B. Jack wrote: 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're too harsh on yourself dude :-D. I agreed with most of your post, so I snipped it. Just wanting to have everyone aware of everyone's "feelings" ;) - Do folks want a pure Python Gump, that one can download & run directly? that would be nice. It doesn't itch though (I have a working gump, and I can install it from scratch again in 1/2 hour). - Or, are folks ok with Gump having other language components, and requiring a build prior to being able to run it. being a pragmatist, if I can "apt-get install gump", that would be perfect, regardless of the dependencies. In case you don't know, apt could download all those dependencies before installing gump. That won't work on windows of course, but windows is not a concern of mine (hey, you asked for opinions ;). I prefer the Python approach (even if I do get called a purist and not a pragmatist, this time. ;). I prefer the python approach for pragmatic reasons :D That said, I could live with either. me too. -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ --- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: System Info
> These questions are not straightfoward. True. Stepping back, my intention was to to be careful to listen to what folks on the list say today. I've been hacking away alone for far too long, and want to ensure that I don't get too comfortable thinking I know what this community wants/thinks. That said, I did fall into the trap of being too close to my own view on the world, and hence applied spin I wasn't even seeing. > At the moment, Gump has a nearly hard dependency on the CVS head version > of a Java project which can't be built by gump. And the completely > optional dependency on a completely stable and completely free of > dependencies "C" program brings up this discussion. As does the adding > of some code which will optionally provide version information for java > in the case where java happens to be installed. Err, good point. I kinda overlooked that didn't I. ;-) I guess I still have hope that w'll build forrest via Gump, and so can bootstrap it. Still, just for discussion --- it does seem like Forrest (something one has to install) really grates on folks wanting to install/run Gump. Even the smart Apache folks on this list seem to baulk at it, and I can understand that. As such, much as I love what Forrest can do for us (with skins/SVGs, etc) I do recognize that it might be too heavy for Gump & that Gump really ought have no manual installation dependencies. I am game to work towards getting HTML or XHTML or whatever outputs (via Cheetah) and make Forrest optional. Meaning, I apply the same logic to Forrest as I do the 'timeout' (when I stop and think about Forrest). > We each apparently place different weights on different attributes. All > other things being equal, yes I would prefer a pure Python solution. > When things aren't equal, I would tend to yeild first on the language > before yielding on bootstrappability. I think bootstrapability is a 'good thing', and since Gump is (eventually, as some hope) intended to compile more than just Java, maybe languages ought give first. [Am I reading you right on this? I think so.] I wonder if we could (strive towards) separating any Java build login (env vars, compiler commandlines, CLASSPATH?) out into separate classes defining 'Java Building', and allow a peer builder for C. We'd want 'timeout' early on in the process, so we probably couldn't use ant to build it, but maybe we can just detect/launch cc or something. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: System Info
Adam R. B. Jack wrote: 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. These questions are not straightfoward. At the moment, Gump has a nearly hard dependency on the CVS head version of a Java project which can't be built by gump. And the completely optional dependency on a completely stable and completely free of dependencies "C" program brings up this discussion. As does the adding of some code which will optionally provide version information for java in the case where java happens to be installed. We each apparently place different weights on different attributes. All other things being equal, yes I would prefer a pure Python solution. When things aren't equal, I would tend to yeild first on the language before yielding on bootstrappability. - Sam Ruby - 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]
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]
java prerequisite (Re: System Info)
Adam R. B. Jack wrote: 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. I don't see "have a jdk installed and its binary utilities on the PATH" as a troubling prerequisite. Especially not if it is optional for additional java-specific functionality. It's only fair you can't get java debugging information unless you have java. -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ --- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: System Info
Adam R. B. Jack wrote: 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. Gump depends on java anyway for building java stuff, so finding out if java is present and if so, what properties is has, it's a nice thing because, in fact, you *do* need to know that anyway. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
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]
