From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27321 invoked by uid 1002); 17 Apr 2003 19:54:28 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 6384 invoked from network); 17 Apr 2003 19:54:26 -0000 From: "merv" To: gentoo-dev@gentoo.org Date: Thu, 17 Apr 2003 23:05:40 +0300 MIME-Version: 1.0 Reply-to: merv@spidernet.com.cy Message-ID: <3E9F3344.23068.F7F84A8@localhost> Priority: normal References: <20030416085248.GD1795@Daikan.pandora.be> In-reply-to: <1050526455.25760.100.camel@osiris.ripple.be> X-mailer: Pegasus Mail for Windows (v4.02) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: Re: [gentoo-dev] initscripts in python X-Archives-Salt: 9a1b7bf0-abb3-49a8-a8e9-63c09dad52c7 X-Archives-Hash: ee1e14dfe962fb6b997b7e752602cadd 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