zsh-workers
 help / color / mirror / code / Atom feed
From: Christoph Kappel <unexist@dorfelite.net>
To: <schaefer@brasslantern.com>
Cc: <zsh-workers@zsh.org>
Subject: Re: Added builtins per runtime
Date: Sun, 02 May 2010 19:28:55 +0200	[thread overview]
Message-ID: <1285a104694.8937591875337474210.6157890075618154029@dorfelite.net> (raw)
In-Reply-To: <x2t691a5d911005020208k4a4c8981ub3b7745048f44999@mail.gmail.com>


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 returns the
result and another one that creates a new builtin. The first new builtin works w/o
problems, any further is either unknown or zsh segfaults so I need some more
code reading/testing there.

Looks like this:

~> zmodload zsh/ruby                  
~> reval "RUBY_VERSION"                
"1.9.1"
~> rdef 'def bar(n); "-" * n.to_i; end'        
~> bar 20
"--------------------"
~>

Basically I am just maintaining an array of builtins myself and call addbuiltins()
inside of my module whenever a new builtin should be added. Due the 
BINF_ADDED flag the builtins will be defined once which is fine.

---- On Sun, 02 May 2010 11:08:21 +0200 Bart Schaefer <schaefer@brasslantern.com> wrote ---- 

>On Sat, May 1, 2010 at 2:02 PM, Christoph Kappel <unexist@dorfelite.net> wrote: 
>> 
>> That was exactly my question. Can a module change it's features per runtime? 
> 
>There doesn't appear to be any reason that a module could not provide 
>a builtin (or even, I suppose, a parameter) that modifies the module's 
>own features array on the fly. The effect would need to be the same 
>as if "zmodload -F" had been invoked to enable the newly-materialized 
>feature. 
> 
>> Generally the use of the word feature in the doc is really confusing, reading the 
>> coding makes it's even worse when a feature struct contains lists of builtins, 
>> condistions etc. which are called features too. 
>> 
>> The doc also doesn't make very clear what abstracts. 
> 
>The concept of features (as in the feature struct) was only recently 
>introduced, and was layered on top of the existing implementation of 
>builtins/parameters/etc. The abstraction may therefore be a bit less 
>clean than one would find if it had been designed from scratch. 
> 
>> I basically want to provide a builtin/feature/whatever that provides a way to add 
>> actions in another language - ruby in my case. 
> 
>I suspect that what you mean by this is that you intend to link a ruby 
>interpreter to zsh, and you want to permit interpreted functions 
>defined in ruby to appear on the fly as builtin commands from the 
>point of view of the zsh interpreter. It might be possible to do 
>that, because the same C function defined in the module can be called 
>under multiple names. However, I'd suggest that you start by having a 
>single builtin that invokes the ruby interpreter and pass it the name 
>of the ruby function as its first argument, rather than attempt to 
>create a new builtin for every function.
>


  reply	other threads:[~2010-05-02 17:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-01 16:33 Christoph Kappel
2010-05-01 19:58 ` Bart Schaefer
2010-05-01 20:17   ` Christoph Kappel
2010-05-01 20:49     ` Bart Schaefer
2010-05-01 21:02       ` Christoph Kappel
2010-05-02  9:08         ` Bart Schaefer
2010-05-02 17:28           ` Christoph Kappel [this message]
2010-05-03 18:57         ` Peter Stephenson

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=1285a104694.8937591875337474210.6157890075618154029@dorfelite.net \
    --to=unexist@dorfelite.net \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).