Added builtins per runtime

Added builtins per runtime

[Christoph Kappel]

Hello list,

I am new to zsh module devel and would like to know if I can add builtins per runtime in a module? 

I have read about the abstract features a module can have but haven't found any further docs about this.

Can I just call addbuiltin() to add a builtin?

Wbr

Christoph

Re: Added builtins per runtime

[Bart Schaefer]

On Sat, May 1, 2010 at 9:33 AM, Christoph Kappel <unexist@dorfelite.net> wrote:
>
> I am new to zsh module devel and would like to know if I can add builtins per runtime in a module?

Yes, of course.

Look at Etc/zsh-development-guide, there's an entire section on Modules.

Also look at Src/Modules/example.* for code samples.

Re: Added builtins per runtime

[Christoph Kappel]

I did, but this doc isn't really helpful - it's just talking about abstracts without further
explaining what this are. The example.c only defines the builtins on start and never
changes them. 

I want to add new ones per runtime.I am currently trying to maintain a second list 
and call addbuiltin() when I need to add one.

Wbr

Christoph

---- On Sat, 01 May 2010 21:58:03 +0200 Bart Schaefer <schaefer@brasslantern.com> wrote ---- 

>On Sat, May 1, 2010 at 9:33 AM, Christoph Kappel <unexist@dorfelite.net> wrote: 
>> 
>> I am new to zsh module devel and would like to know if I can add builtins per runtime in a module? 
> 
>Yes, of course. 
> 
>Look at Etc/zsh-development-guide, there's an entire section on Modules. 
> 
>Also look at Src/Modules/example.* for code samples.
>

Re: Added builtins per runtime

[Bart Schaefer]

On Sat, May 1, 2010 at 1:17 PM, Christoph Kappel <unexist@dorfelite.net> wrote:
>
> I want to add new ones per runtime.I am currently trying to maintain a second list
> and call addbuiltin() when I need to add one.

I guess I'm not understanding the question, then.  Can you give an
example of what it means to you to "add new ones per runtime"?  What
would it mean for example.c to "change" the builtins that it defines?

Modules define features, which can be several different kinds of
things including builtins.  None of a module's features is available
until the module is loaded.  Once a module is loaded, you can't alter
the set of features it provides, though the zmodload command can
enable and disable specific features to make them visible or invisible
to the shell.

So typically a module would define several features and the calling
shell script/program would determine which ones it wishes to enable or
disable.  How does that differ from what you are attempting to
accomplish?

Re: Added builtins per runtime

[Christoph Kappel]

That was exactly my question. Can a module change it's features per runtime? 
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.

I basically want to provide a builtin/feature/whatever that provides a way to add
actions in another language - ruby in my case.

---- On Sat, 01 May 2010 22:49:48 +0200 Bart Schaefer <schaefer@brasslantern.com> wrote ---- 

>On Sat, May 1, 2010 at 1:17 PM, Christoph Kappel <unexist@dorfelite.net> wrote: 
>> 
>> I want to add new ones per runtime.I am currently trying to maintain a second list 
>> and call addbuiltin() when I need to add one. 
> 
>I guess I'm not understanding the question, then. Can you give an 
>example of what it means to you to "add new ones per runtime"? What 
>would it mean for example.c to "change" the builtins that it defines? 
> 
>Modules define features, which can be several different kinds of 
>things including builtins. None of a module's features is available 
>until the module is loaded. Once a module is loaded, you can't alter 
>the set of features it provides, though the zmodload command can 
>enable and disable specific features to make them visible or invisible 
>to the shell. 
> 
>So typically a module would define several features and the calling 
>shell script/program would determine which ones it wishes to enable or 
>disable. How does that differ from what you are attempting to 
>accomplish?
>

Re: Added builtins per runtime

[Bart Schaefer]

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.

Re: Added builtins per runtime

[Christoph Kappel]

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.
>

Re: Added builtins per runtime

[Peter Stephenson]

On Sat, 01 May 2010 23:02:28 +0200
Christoph Kappel <unexist@dorfelite.net> wrote:
> That was exactly my question. Can a module change it's features per runtime? 

I think the interface you want in the C code is probably
handlefeatures() or thereabouts.  You can get similar effects from shell
code with zmodload, for example:


# Load the zsh/stat module, enabling (only) the zstat builtin
% zmodload -F zsh/stat b:zstat
% which zstat
zstat: shell built-in command

# Disable the zstat builtin
% zmodload -F zsh/stat -b:zstat
% which zstat
zstat not found

# Reenable it
% zmodload -F zsh/stat +b:zstat
% which zstat
zstat: shell built-in command


This is under user control, i.e. the zstat builtin is always there to be
enabled from the command line.  If you want to change what builtins or
other feature are actually offered, you need to be a bit more careful.
I *think* you can get away with doing the C equivalent of disabling a
feature, and after that not showing it --- the interface between the
main shell and a module doesn't remember the feature list, it queries
the module every time, so if you present it a different list of features
each time it doesn't care.  However, if a builtin is linked into the
shell, it will be called whatever zmodload sees, which is why I think
you need to ensure you disable the feature before presenting a list with
it missing.

In other words, to disable a builtin (or parameter, math function, or
condition) in a way that doesn't allow the user to reenable it (i) call
handlefeatures() with an appropriate array indicating what you want to
be enabled.  That should probably be an "and" of what is actually
enabled together with zeros for the features you no longer want to
present (ii) next time there's a call from zmodload into your function,
only present the set of features / array of enabled features shortened
so that it doesn't include the feature you want to disappear.  The only
tricky bit is to make quite sure the two arrays are the same length with
the appropriate element missing.  (The point of the interface the way it
is is that the Features array is expected to be invariant while the
array of integers will change each time; your case is atypical.)  I think
that should work, but I have not tried.  If it doesn't work, it's
probably a bug that should be fixed (though I reserve the right to say,
"oh yeah, I never expected it to do *that*" at infuriating points).

I don't think you should be doing this at the level below that of
generic features, the interface isn't as powerful, so even if you're
just interested in builtins, create a list of features with the lists of
feature types other than builtins set to NULL and pass that to handlefeatures().

If you'd like more documentation, please be explicit (though not
necessarily detailed) about where in the documentation it should go and
what it should talk about.  The developer's guide is certainly not for
the faint of heart (and isn't supposed to be), but is capable of
expansion.

Good luck.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/