From: "merv" <merv@spidernet.com.cy>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] initscripts in python
Date: Thu, 17 Apr 2003 23:05:40 +0300 [thread overview]
Message-ID: <3E9F3344.23068.F7F84A8@localhost> (raw)
In-Reply-To: <1050526455.25760.100.camel@osiris.ripple.be>
Yep, I agree on your two cons:
->a new interpreter would have to reach stable pretty quick since we
are mucking around with pretty system-vital stuff here (and since we
are using python syntax [in this hypothetical instance] to message to
the kernel, a new interpreter and a fairly fundamental re-write of the
shell may be the end result, though it might be politic not to revise what
was not necessary to revise)
->the structure of the interpreter and ways in which it parse shell syntax
of a python dialect would have to be addressed with the aim of
minimising overhead on one-liner files, in particular (small scripts incur
overhead, unavoidably, at least conventionally, but lots of small
python-interpreted scripts might have real potential for runtime bloat)
About your two mitigating factors: indeed, python seems to be
evolving as a native gentoo language (perhaps this is a bit overstating
the point, given that python is built on C APIs, but consider that portage
is a central characteristic and feature of gentoo and that the portage
tree is a testimony to the practical usefulness and potential of python)
so to weave python or python-dialect syntax into a "system-boot
interpreter" would be a natural extension of its role in gentoo and, if
optimised for that purpose at that point, perhaps even a fast, efficient
and inexpensive alternative.
[Maybe it is worth saying at this point that I am trying very deliberately
to drive a line between python the language as it is and python-
language characteristics, such as its clean syntax, it "everything is an
object" approach to life and so on which make it very attractive for
"collective" development where code-readability and recycleability
really begin to matter. I am not suggesting, at this point, a wholesale
transplant of the python language to sh but ways of building-in some of
its features or characteristics to ADD TO sh, to be an addition, rather
than replace sh].
On the issue you raise in your second mitigating factor, a kind of
runtime boot-failover could be one example of the things made
possible by introducing a more "extensible" shell.
Just to note: i envisage several levels of control or options. There
would, perhaps, be an initial build-time option to include python as a
part of an "actively extensible" shell. sh would be default and required.
python could then be toggled on and off at any time during by the use
of command line switches or arguments passed with shell commands.
additionally, optimisation switches could be passed as arguments to
shell commands, or in script files, that enable the python shell syntax
to behave exactly as required in given conditions or environments. For
example, (and these lame suggestions are only for illustrating my
point):
pye -a to activate a python-shell environment
pye -k to kill it and return to sh
pye -a -psh to activate a mixed sh/python shell environment
pye -k psh to kill the mixed environment and return to sh
pye -k psh -p to kill the mixed environment but allow python
shell to persist
pye -a -swoff to activate the python shell environment
(when swap off) except when swap is activated
and performance might be an issue (if the
python shell environment proved to have
performance issues)
etc etc etc...you see my point
of course, the python shell environment could be invoked and killed in
scripts in similar ways.
maybe we would in such cases be faced with the infinitive question of
whether to trade performance for functionality, vice versa, or whether
the trade-off in itself was necessary
the end result would be a new way to think of and use the shell
but now i pontificate :)
On 16 Apr 2003 at 16:54, Justin Whitney wrote:
> Thanks for the arguments thus far.
>
> So added to the cons list is:
>
> *addition of newer less-tested interpreter could add instability
> *very small/short scripts incur overhead
>
> Here are two mitigating arguments to counter the first statement.
>
> First - a separate, stable build of python could be used as the
> system-boot interpreter. it might make sense to statically link it and
> so forth to lower dependencies... perhaps even to optimize it in some
> respects, for its task.
>
> Second, a shell script like the runscript.sh that is already used could
> be used to launch the interpreter and check for a runtime failure. On
> failure it could launch the .sh version of the bootscript. This means
> keeping two copies of the shellscripts obviously (which wouldn't be a
> bad idea anyway...) this would at least have the benefit of salvaging
> the boot...
>
> As for the overhead problem with very small scripts, I don't see that
> going away... in fact converting such scripts would be a waste of time
> in the first place, because it doesn't make use of any of the advantages
> proposed by the change. It would make more sense to set up the boot
> process to be able to run both kinds so you don't waste your time.
>
> --Justin
>
>
> --
> gentoo-dev@gentoo.org mailing list
>
--
Merv Hammer
mailto: merv@spidernet.com.cy
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2003-04-17 19:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-16 1:29 [gentoo-dev] initscripts in python Justin Whitney
2003-04-16 4:09 ` Daniel Armyr
2003-04-16 5:38 ` merv
2003-04-16 7:25 ` Jeff Rose
2003-04-16 8:49 ` merv
2003-04-16 8:19 ` Paul de Vrieze
2003-04-16 8:52 ` Sven Vermeulen
2003-04-16 20:54 ` Justin Whitney
2003-04-17 20:05 ` merv [this message]
2003-04-17 5:49 ` Joseph Carter
2003-04-17 6:27 ` George Shapovalov
2003-04-17 18:25 ` merv
2003-04-17 7:42 ` Paul de Vrieze
2003-04-16 22:44 ` Abhishek Amit
2003-04-17 6:45 ` Sven Vermeulen
2003-04-17 20:56 ` merv
2003-04-17 22:26 ` Caleb Shay
2003-04-17 23:32 ` merv
2003-04-17 18:18 ` merv
2003-04-16 21:08 ` Brad Laue
2003-04-17 6:47 ` Sven Vermeulen
-- strict thread matches above, loose matches on Subject: below --
2003-04-16 11:13 merv
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E9F3344.23068.F7F84A8@localhost \
--to=merv@spidernet.com.cy \
--cc=gentoo-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox