Re: Problems running gump (both trunk and live)

[Stefano Mazzocchi]

Peter Janes wrote:
Stefano Mazzocchi wrote:
The status of the gump.py file in the root is *up in the air* at best 
and totally untested for a lot of things. In short, it's a mess.
[...]
So, for now, use the cron script or you can help me out and fix 
the bugs :-)

Love to, but I think I've exhausted my Python knowledge.  If I get a 
chance I'll submit a patch for the getting started page though. :)
the wiki awaits you :-)
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Problems running gump (both trunk and live)

[Peter Janes]

Stefano Mazzocchi wrote:
The status of the gump.py file in the root is *up in the air* at best 
and totally untested for a lot of things. In short, it's a mess.
[...]
So, for now, use the cron script or you can help me out and fix the 
bugs :-)
Love to, but I think I've exhausted my Python knowledge.  If I get a chance 
I'll submit a patch for the getting started page though. :)
--
Sometimes the Universe needs a change of perspective.
  --J. Michael Straczynski


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Problems running gump (both trunk and live)

[Stefano Mazzocchi]

Peter Janes wrote:
Gareth Webbley wrote:
The way I got around this problem was to cd to the cron directory and 
either run gump.sh in that directory or python gump.py.  There is 
another copy of gump.py in the cron directory which works differently 
to the one in the root directory.  I think this is the one used in the 
official runs.

That seems to do it, thanks.
Oddly, the "getting started" page gives instructions on installing and 
configuring Gump, but stops just short of actually *running* it. :)
I know, it's confusing as hell and I'm totally sorry for you I went thru 
the same pain.

we'll fix this soon.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Problems running gump (both trunk and live)

[Stefano Mazzocchi]

Gareth Webbley wrote:
Hi Peter,
I have had the same problem.  When executing a command the gump.py in the root 
directory (of gump) creates a list and passes that as the options to the 
command.  However the command is not expecting a list.

The way I got around this problem was to cd to the cron directory and either 
run gump.sh in that directory or python gump.py.  There is another copy of 
gump.py in the cron directory which works differently to the one in the root 
directory.  I think this is the one used in the official runs.
correct!
the official gump runs with the cron/gump.sh script.
The status of the gump.py file in the root is *up in the air* at best 
and totally untested for a lot of things. In short, it's a mess.

The internals of gump have not being changed (in fact it works as 
before) but my user-friendly CLI work is not finished and I was 
sidetracked by my day job + work on dynagump.

I'll get back to that soon since I now have dynagump in a state where I 
need gump to start populating the relational database for real.

So, for now, use the cron script or you can help me out and fix the 
bugs :-)

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Problems running gump (both trunk and live)

[Peter Janes]

Gareth Webbley wrote:
The way I got around this problem was to cd to the cron directory and either 
run gump.sh in that directory or python gump.py.  There is another copy of 
gump.py in the cron directory which works differently to the one in the root 
directory.  I think this is the one used in the official runs.
That seems to do it, thanks.
Oddly, the "getting started" page gives instructions on installing and 
configuring Gump, but stops just short of actually *running* it. :)

--
Sometimes the Universe needs a change of perspective.
  --J. Michael Straczynski


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Problems running gump (both trunk and live)

[Gareth Webbley]

Hi Peter,

I have had the same problem.  When executing a command the gump.py in the root 
directory (of gump) creates a list and passes that as the options to the 
command.  However the command is not expecting a list.

The way I got around this problem was to cd to the cron directory and either 
run gump.sh in that directory or python gump.py.  There is another copy of 
gump.py in the cron directory which works differently to the one in the root 
directory.  I think this is the one used in the official runs.

HTH

Gareth Webbley


On Monday 08 November 2004 02:41, Peter Janes wrote:
> I've recently synced both the trunk and live branch of Gump (which are
> identical as of revision 56892) and have a problem running both of them. 
> If I
>
> execute "python2.3 gump.py build" I get the following traceback:
> > Traceback (most recent call last):
> >   File "gump.py", line 118, in ?
> > main(sys.argv)
> >   File "gump.py", line 108, in main
> > getattr(command, "process")(options,arguments)
> >   File
> > "/home/pjanes/devel/tempo/thirdparty/gump-live/python/gump/commands/build
> >.py", line 41, in process workspace =
> > WorkspaceLoader(options.isCache()).load(ws)
> > AttributeError: 'list' object has no attribute 'isCache'
>
> I think it's a scope problem--gump.core.run.options is imported, but the
> process() method takes an argument named "options"--but I'm at a loss to
> explain why my version doesn't run and the Apache one does.  Any takers?
>
> Also, I notice that http://gump.apache.org/gettingstarted.html directs new
> users to check out the trunk (i.e. potentially unstable) version instead of
> the "live" branch.  Would it be more appropriate to send them to "live"
> instead?
>
> Thanks,
> Peter J.

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

Problems running gump (both trunk and live)

[Peter Janes]

I've recently synced both the trunk and live branch of Gump (which are 
identical as of revision 56892) and have a problem running both of them.  If I 
execute "python2.3 gump.py build" I get the following traceback:

Traceback (most recent call last):
  File "gump.py", line 118, in ?
main(sys.argv)
  File "gump.py", line 108, in main
getattr(command, "process")(options,arguments)
  File 
"/home/pjanes/devel/tempo/thirdparty/gump-live/python/gump/commands/build.py", 
line 41, in process
workspace = WorkspaceLoader(options.isCache()).load(ws)
AttributeError: 'list' object has no attribute 'isCache'
I think it's a scope problem--gump.core.run.options is imported, but the 
process() method takes an argument named "options"--but I'm at a loss to 
explain why my version doesn't run and the Apache one does.  Any takers?

Also, I notice that http://gump.apache.org/gettingstarted.html directs new 
users to check out the trunk (i.e. potentially unstable) version instead of 
the "live" branch.  Would it be more appropriate to send them to "live" instead?

Thanks,
Peter J.
--
"Fighting a war is easy.  Destroying is easy.  Building a new world out of
 what's left of the old, that is what's hard."  -- J. Michael Straczynski
Lenni Jabour and The Third Floor - 
 Petroglyphs - 
 Sirens - 


smime.p7s
Description: S/MIME Cryptographic Signature

Problems running gump (both trunk and live)

[Peter Janes]

I've recently synced both the trunk and live branch of Gump (which are 
identical as of revision 56892) and have a problem running both of them.  If I
execute "python2.3 gump.py build" I get the following traceback:

Traceback (most recent call last):
  File "gump.py", line 118, in ?
main(sys.argv)
  File "gump.py", line 108, in main
getattr(command, "process")(options,arguments)
  File 
"/home/pjanes/devel/tempo/thirdparty/gump-live/python/gump/commands/build.py", 
line 41, in process
workspace = WorkspaceLoader(options.isCache()).load(ws)
AttributeError: 'list' object has no attribute 'isCache'
I think it's a scope problem--gump.core.run.options is imported, but the 
process() method takes an argument named "options"--but I'm at a loss to 
explain why my version doesn't run and the Apache one does.  Any takers?

Also, I notice that http://gump.apache.org/gettingstarted.html directs new 
users to check out the trunk (i.e. potentially unstable) version instead of 
the "live" branch.  Would it be more appropriate to send them to "live" instead?

Thanks,
Peter J.
--
Sometimes the Universe needs a change of perspective.
  --J. Michael Straczynski
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]