You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by "Adam R. B. Jack" <aj...@trysybase.com> on 2004/04/05 17:53:57 UTC
timeout
I've coding 'timeout' into Python Gump (allowing GumpEnvironment to detect
it & register it, and allowing launcher.py:executeIntoResult to use it if
found) as an optional dependency. [I've done this in the hope of helping
Hermes, which (I assume) is still in an uncomfortable situation of having a
rogue child.]
Right now this is a tad ugly, the code is setting a variable on a singleton
(global static) from an instance object, GumpEnv. I think GumpEnv needs to
be moved to a more central point, and just referenced by the Run, but not
today, let's see where this takes us.
BTW: If timeout is available we no longer use the pgrep/kill background
thread. I was tempted to try both, but I was realized this mechanism could
fight the other & kill timeout before it could kill the child.
I realized I needed to go read the source code to satisfy my curiosity on
how even a C program could kill children/grandchildren/etc (and if it could
do it without race condition). It doesn't seem to (from my code read). Oh
well, since timeout is run within the shell (we use system() 'cos no
alternatives seemed to fit, at the time) it (at least) kills the first
child, which is better than killing the shell.
I'll ensure this runs on gump.try.
What is the state of Hermes? Is this a good place to test it?
regards,
Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: timeout
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> I'll ensure this runs on gump.try.
In case this is informative to others I (1) I tried making on a new RHL (2)
I downloaded and ran. See uname for details.
BTW: The URL referenced within the source file is no longer valid, and I
couldn't find it on the gentlemen's site.
That said, I think the changes work, so this is a new option & hopefully
helps Hermes.
regards
Adam
----------------------------------------------------------------------------
----
[ajack@gump gump]$ cd timeout/
[ajack@gump timeout]$ make
gcc timeout.o strsig.o -o timeout
timeout.o(.text+0x199): In function `main':
: undefined reference to `errno'
timeout.o(.text+0x1e1): In function `main':
: undefined reference to `errno'
collect2: ld returned 1 exit status
make: *** [timeout] Error 1
[ajack@gump timeout]
$[ajack@gump timeout]$ ~/bin/timeout
Incorrectly built binary which accesses errno or h_errno directly. Needs to
be fixed.
Usage: /home/ajack/bin/timeout [-signal] seconds program [arg ...]
[ajack@gump timeout]$
[ajack@gump timeout]$ uname -a
Linux gump.try.sybase.com 2.4.21-9.ELsmp #1 SMP Thu Jan 8 17:08:56 EST 2004
i686 i686 i386 GNU/Linux
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: timeout
Posted by Stefano Mazzocchi <st...@apache.org>.
Sam Ruby wrote:
> Adam R. B. Jack wrote:
>
>>
>> BTW: Your request to have xdocs pages (for projects, etc.) built as the
>> come, really ought be doable w/o much change. Calling
>> ForrestDocumenter.documentModule or ForrestDocumenter.documentProject
>> ought
>> have no dependencies. Either we write directly to the log directory
>> (possible) or we write to staging and sync. I don't quite know how to do
>> this to a staging area, and then sync ('cos there are N pages) but I'd
>> like
>> to try, otherwise our site could accumulate a lot of flotsom and jetsom.
>>
>> If you want to have a dig in, feel free. If this area is a little
>> 'convoluted' and you'd like me to have a shot, no problem. I ought be get
>> there within the next week or so.
>
>
> I'm travelling at the moment, and quite frankly until Gump gets back to
> the point where I can experiment on a change with a edit/compile/debug
> cycle measured in minutes instead of hours, all of my contributions will
> be "in the margins". Furthermore, my knowledge of Forrest is nearly
> approximately zero at the moment.
>
> My brief forray into ForrestDocumenter lead me to the conclusion that a
> good percentage of that code is really producing things like tables and
> not particularly Forrest specific.
>
> A way to manage the flotsam and jetsam is to write everything to a
> directory whose name is based on today's date. "latest" can be a
> symbolic link to the current date. At the beginning of the run can be
> some code to create the directory if it doesn't exist (and updating the
> symbolic link as required), and to delete all but the last "n"
> directories that may exist.
>
> Anyway, my suggestion is that if you can get something which
> approximately works, I can help complete it. And we can clearly leave
> the static forrest code in place until there is something worth
> replacing it.
I'll try to install forrest dynamic today on brutus.
--
Stefano.
Re: timeout
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> I'll see what I can do to install dynamic forrest on gump today as soon
> as I receive a password for brutus.
I've forwarded a mail (from Sam) to both you and Stefan.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: timeout
Posted by Stefano Mazzocchi <st...@apache.org>.
Sam Ruby wrote:
> Adam R. B. Jack wrote:
>
>>
>> BTW: Your request to have xdocs pages (for projects, etc.) built as the
>> come, really ought be doable w/o much change. Calling
>> ForrestDocumenter.documentModule or ForrestDocumenter.documentProject
>> ought
>> have no dependencies. Either we write directly to the log directory
>> (possible) or we write to staging and sync. I don't quite know how to do
>> this to a staging area, and then sync ('cos there are N pages) but I'd
>> like
>> to try, otherwise our site could accumulate a lot of flotsom and jetsom.
>>
>> If you want to have a dig in, feel free. If this area is a little
>> 'convoluted' and you'd like me to have a shot, no problem. I ought be get
>> there within the next week or so.
>
>
> I'm travelling at the moment, and quite frankly until Gump gets back to
> the point where I can experiment on a change with a edit/compile/debug
> cycle measured in minutes instead of hours, all of my contributions will
> be "in the margins". Furthermore, my knowledge of Forrest is nearly
> approximately zero at the moment.
>
> My brief forray into ForrestDocumenter lead me to the conclusion that a
> good percentage of that code is really producing things like tables and
> not particularly Forrest specific.
>
> A way to manage the flotsam and jetsam is to write everything to a
> directory whose name is based on today's date. "latest" can be a
> symbolic link to the current date. At the beginning of the run can be
> some code to create the directory if it doesn't exist (and updating the
> symbolic link as required), and to delete all but the last "n"
> directories that may exist.
>
> Anyway, my suggestion is that if you can get something which
> approximately works, I can help complete it. And we can clearly leave
> the static forrest code in place until there is something worth
> replacing it.
I'll see what I can do to install dynamic forrest on gump today as soon
as I receive a password for brutus.
--
Stefano.
Re: timeout
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> I'd like to work on it, as I have used Velocity recently, and of course
> I work on Forrest...
Cheetah seems a blur of Python and template, to ther extends that one can
write templates that become Python classes. I started to wonder why a Python
programmer would need a 'Python shorthand', and then figures I was clearly a
Cheetah philistine, and am glad somebody else will tinker. :)
> but I've still not tried again to run Gump. It's
> unfortunate given that I could do it easily... some time back :-(
If I recall, I think the main issues were portability (and the lack of some
'simple' scripts). Both these ought be resolved.
That, and there are isues with gettign a full Gump environment (the packages
being the main issue) and I don't know how to resolve that for new users. It
didn't hit you before 'cos Gump didn'ty work before, it just loaded
metadata. Maybe we need to work (again) on a minimal workspace.
Sorry, do you mind just trying again & letting us know the issues.
> Ok, so I wanna Gump a subset.
Do you mean trim a workspace, or use a derivative of gump.xml (with local
tweaks) and run a sub-set of the profile? If the later... you ought be able
to pass a comma separated list of project (wildcarded) expressions, e.g.
ant or kry*,xml*.
The --quick (default for most scripts) ought not work on the complete stack,
just the projects/modules it matches.
> Where do I start with the current CVS
> Gumpy given a W2000 system?
I think these are still valid:
http://wiki.apache.org/gump/GumpPython
and:
http://wiki.apache.org/gump/GumpScripts
Please let us have feedback.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: timeout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Adam R. B. Jack wrote:
...
> Yes, basically page after page of paragraphs/lists/tables. In part 'cos that
> is all we get with xdocs, in part that is all I think we need. I wish we
> could abstract the 'data gathering/page forming logic' of this out of class
> (so we could have HTML or xdoc outputs), and I might try. This code isn't
> 'bad', but I have a gut feeling it could be a lot better.
>
> If anybody has an itch to work with Cheetah, I am more than game to help
> build a TemplateDocumenter. I could stub one out, if folks were interested.
I'd like to work on it, as I have used Velocity recently, and of course
I work on Forrest... but I've still not tried again to run Gump. It's
unfortunate given that I could do it easily... some time back :-(
Ok, so I wanna Gump a subset. Where do I start with the current CVS
Gumpy given a W2000 system?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: timeout
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> I'm travelling at the moment, and quite frankly until Gump gets back to
> the point where I can experiment on a change with a edit/compile/debug
> cycle measured in minutes instead of hours, all of my contributions will
> be "in the margins".
Understood. Between TextDocument (ugly&crude, but --text if you want it) and
ForrestDocument (slow) we don't have a nice option for quick runs.
Mind you, there are lots of things you could help with on the margins,
giving us Pythonic/Gumpological input. :-)
> Furthermore, my knowledge of Forrest is nearly
> approximately zero at the moment.
Mine too (of it's internals). I write simple XML docs (it's xdocs, using a
subset of this
http://xml.apache.org/forrest/document-v11.dtdx.html#document, that I coded
into xdocs.py), and Forrest works & generates HTML/sites. That was what I
was hoping for.
It takes too long for any human to care to wait for, which is unfortunately
where things fall down. I never really wanted/expected humans to have/want
to, that is just how they've worked out, since we have poor alternatives.
> My brief forray into ForrestDocumenter lead me to the conclusion that a
> good percentage of that code is really producing things like tables and
> not particularly Forrest specific.
Yes, basically page after page of paragraphs/lists/tables. In part 'cos that
is all we get with xdocs, in part that is all I think we need. I wish we
could abstract the 'data gathering/page forming logic' of this out of class
(so we could have HTML or xdoc outputs), and I might try. This code isn't
'bad', but I have a gut feeling it could be a lot better.
If anybody has an itch to work with Cheetah, I am more than game to help
build a TemplateDocumenter. I could stub one out, if folks were interested.
> A way to manage the flotsam and jetsam is to write everything to a
> directory whose name is based on today's date. "latest" can be a
> symbolic link to the current date. At the beginning of the run can be
> some code to create the directory if it doesn't exist (and updating the
> symbolic link as required), and to delete all but the last "n"
> directories that may exist.
Any chance you could take a look back at my mail with subject '--dated'. (If
you use eyebrowse, be warned, it's index may still be dorked for us.) I was
hoping for something as simple as putting things into a @@DATE@@ directory,
but Nick pointed out that I have RSS and Atom file that ought be kept in a
fixed (dateless) location. [Hmm, maybe 'latest' satisfys this.]
In passing, do you have views on us dotting RSS and Atom files throughout
the hierarchy? I wanted to allow folks to subscribe to multiple channels
(whilst keep coding simple) so I created different files for 'workspace',
'module', 'project' levels. If we didn't have these, we'd have far less
issue with matching hierarchies (for RSS) with dates ones for HTML.
> Anyway, my suggestion is that if you can get something which
> approximately works, I can help complete it. And we can clearly leave
> the static forrest code in place until there is something worth
> replacing it.
Sure, I'll get there, but it comes third. Work work, SVG work (having fun),
then this. I won't forget though, and I'll keep this list abreast of
progress.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: timeout
Posted by Sam Ruby <ru...@apache.org>.
Adam R. B. Jack wrote:
>
> BTW: Your request to have xdocs pages (for projects, etc.) built as the
> come, really ought be doable w/o much change. Calling
> ForrestDocumenter.documentModule or ForrestDocumenter.documentProject ought
> have no dependencies. Either we write directly to the log directory
> (possible) or we write to staging and sync. I don't quite know how to do
> this to a staging area, and then sync ('cos there are N pages) but I'd like
> to try, otherwise our site could accumulate a lot of flotsom and jetsom.
>
> If you want to have a dig in, feel free. If this area is a little
> 'convoluted' and you'd like me to have a shot, no problem. I ought be get
> there within the next week or so.
I'm travelling at the moment, and quite frankly until Gump gets back to
the point where I can experiment on a change with a edit/compile/debug
cycle measured in minutes instead of hours, all of my contributions will
be "in the margins". Furthermore, my knowledge of Forrest is nearly
approximately zero at the moment.
My brief forray into ForrestDocumenter lead me to the conclusion that a
good percentage of that code is really producing things like tables and
not particularly Forrest specific.
A way to manage the flotsam and jetsam is to write everything to a
directory whose name is based on today's date. "latest" can be a
symbolic link to the current date. At the beginning of the run can be
some code to create the directory if it doesn't exist (and updating the
symbolic link as required), and to delete all but the last "n"
directories that may exist.
Anyway, my suggestion is that if you can get something which
approximately works, I can help complete it. And we can clearly leave
the static forrest code in place until there is something worth
replacing it.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: timeout
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> OK, lets get back to this issue. Nobody here seems to know why the
> forrest run takes so long, but it takes a significant fraction of the
> overall run.
Including me. ;-)
> It also produces thousands of web pages, only a small
> fraction of which are likely to ever be looked at.
Agreed.
> And none of these
> pages are produced until the run is complete.
Actually this is because of how long forrest takes, and being clean. To
fully automate a remote Gump we need it to clean up when projects [pages] go
away, and such. As such the xdocs are writing to a work directory, the pages
are built into a clean staging directory, and then the pages moved over. At
least this way the site isn't missing-in-action for the length of the
forrest run.
> A better approach would be to run forrest dynamically, i.e. produce (and
> possibly cache) the web page on demand. I'm not sure what that would
> take to make happen, but it seems to me that the best way to get from
> here to there is to try to do both.
Agreed.
Things are closer than they were a while ago. I added a --xdocs option (that
sets options.isXDocs() to true) that makes forrest.py generate the xdocs,
and not run forrest -- but sync that work directory with the log directory.
BTW: Your request to have xdocs pages (for projects, etc.) built as the
come, really ought be doable w/o much change. Calling
ForrestDocumenter.documentModule or ForrestDocumenter.documentProject ought
have no dependencies. Either we write directly to the log directory
(possible) or we write to staging and sync. I don't quite know how to do
this to a staging area, and then sync ('cos there are N pages) but I'd like
to try, otherwise our site could accumulate a lot of flotsom and jetsom.
If you want to have a dig in, feel free. If this area is a little
'convoluted' and you'd like me to have a shot, no problem. I ought be get
there within the next week or so.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: timeout
Posted by Sam Ruby <ru...@apache.org>.
Adam R. B. Jack wrote:
>
>>It seems that pgrep doesn't exist on FreeBSD. The web site started to
>>materialize once I manually killed the java step that was running.
>
> That I translated to some runaway ant script (we had one recently) and that
> is what caused me to bring up the whole 'timeout' thread. It didn't occur to
> me you were describing the Forrest run. :-)
OK, lets get back to this issue. Nobody here seems to know why the
forrest run takes so long, but it takes a significant fraction of the
overall run. It also produces thousands of web pages, only a small
fraction of which are likely to ever be looked at. And none of these
pages are produced until the run is complete.
A better approach would be to run forrest dynamically, i.e. produce (and
possibly cache) the web page on demand. I'm not sure what that would
take to make happen, but it seems to me that the best way to get from
here to there is to try to do both.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: timeout
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> I see no evidence of a rogue child. What leads you to this conclusion?
>
> Note: hermes was down for a number of hours yesterday due to an operator
> error.
Oh, how funny. I read what you wrote:
> It seems that pgrep doesn't exist on FreeBSD. The web site started to
> materialize once I manually killed the java step that was running.
That I translated to some runaway ant script (we had one recently) and that
is what caused me to bring up the whole 'timeout' thread. It didn't occur to
me you were describing the Forrest run. :-)
Oh well, we now ought have 'timeout' available for platforms w/o pgrep...
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: timeout
Posted by Sam Ruby <ru...@apache.org>.
Adam R. B. Jack wrote:
> I've coding 'timeout' into Python Gump (allowing GumpEnvironment to detect
> it & register it, and allowing launcher.py:executeIntoResult to use it if
> found) as an optional dependency. [I've done this in the hope of helping
> Hermes, which (I assume) is still in an uncomfortable situation of having a
> rogue child.]
I see no evidence of a rogue child. What leads you to this conclusion?
Note: hermes was down for a number of hours yesterday due to an operator
error.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org