From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20821 invoked by alias); 2 May 2010 17:29:06 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 27944 Received: (qmail 5997 invoked from network); 2 May 2010 17:29:03 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_FRT_ADULT2 autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at dorfelite.net does not designate permitted sender hosts) Date: Sun, 02 May 2010 19:28:55 +0200 From: Christoph Kappel To: Cc: Message-ID: <1285a104694.8937591875337474210.6157890075618154029@dorfelite.net> In-Reply-To: References: <12854b73c24.-5662614641985446414.-6364714751911043221@dorfelite.net> <1285584468e.-5976807992945925025.-2686280647114173652@dorfelite.net> <12855ad6dba.6318419370147111815.5595086135333789265@dorfelite.net> Subject: Re: Added builtins per runtime MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail I stopped relying on the docs and started reading the code as I should have= done from start directly - it's FOSS after all and the docs of my project aren't= even close of being accurate too. ;) I currently have two builtins, one just evals ruby code in the vm and retur= ns the result and another one that creates a new builtin. The first new builtin wo= rks w/o problems, any further is either unknown or zsh segfaults so I need some mor= e code reading/testing there. Looks like this: ~> zmodload zsh/ruby =20 ~> reval "RUBY_VERSION" =20 "1.9.1" ~> rdef 'def bar(n); "-" * n.to_i; end' =20 ~> bar 20 "--------------------" ~> Basically I am just maintaining an array of builtins myself and call addbui= ltins() inside of my module whenever a new builtin should be added. Due the=20 BINF_ADDED flag the builtins will be defined once which is fine. ---- On Sun, 02 May 2010 11:08:21 +0200 Bart Schaefer wrote ----=20 >On Sat, May 1, 2010 at 2:02 PM, Christoph Kappel w= rote:=20 >>=20 >> That was exactly my question. Can a module change it's features per runt= ime?=20 >=20 >There doesn't appear to be any reason that a module could not provide=20 >a builtin (or even, I suppose, a parameter) that modifies the module's=20 >own features array on the fly. The effect would need to be the same=20 >as if "zmodload -F" had been invoked to enable the newly-materialized=20 >feature.=20 >=20 >> Generally the use of the word feature in the doc is really confusing, re= ading the=20 >> coding makes it's even worse when a feature struct contains lists of bui= ltins,=20 >> condistions etc. which are called features too.=20 >>=20 >> The doc also doesn't make very clear what abstracts.=20 >=20 >The concept of features (as in the feature struct) was only recently=20 >introduced, and was layered on top of the existing implementation of=20 >builtins/parameters/etc. The abstraction may therefore be a bit less=20 >clean than one would find if it had been designed from scratch.=20 >=20 >> I basically want to provide a builtin/feature/whatever that provides a w= ay to add=20 >> actions in another language - ruby in my case.=20 >=20 >I suspect that what you mean by this is that you intend to link a ruby=20 >interpreter to zsh, and you want to permit interpreted functions=20 >defined in ruby to appear on the fly as builtin commands from the=20 >point of view of the zsh interpreter. It might be possible to do=20 >that, because the same C function defined in the module can be called=20 >under multiple names. However, I'd suggest that you start by having a=20 >single builtin that invokes the ruby interpreter and pass it the name=20 >of the ruby function as its first argument, rather than attempt to=20 >create a new builtin for every function. >