* Added builtins per runtime @ 2010-05-01 16:33 Christoph Kappel 2010-05-01 19:58 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Christoph Kappel @ 2010-05-01 16:33 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Added builtins per runtime 2010-05-01 16:33 Added builtins per runtime Christoph Kappel @ 2010-05-01 19:58 ` Bart Schaefer 2010-05-01 20:17 ` Christoph Kappel 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2010-05-01 19:58 UTC (permalink / raw) To: Christoph Kappel; +Cc: zsh-workers 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Added builtins per runtime 2010-05-01 19:58 ` Bart Schaefer @ 2010-05-01 20:17 ` Christoph Kappel 2010-05-01 20:49 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Christoph Kappel @ 2010-05-01 20:17 UTC (permalink / raw) To: schaefer; +Cc: zsh-workers 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. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Added builtins per runtime 2010-05-01 20:17 ` Christoph Kappel @ 2010-05-01 20:49 ` Bart Schaefer 2010-05-01 21:02 ` Christoph Kappel 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2010-05-01 20:49 UTC (permalink / raw) To: Christoph Kappel; +Cc: zsh-workers 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Added builtins per runtime 2010-05-01 20:49 ` Bart Schaefer @ 2010-05-01 21:02 ` Christoph Kappel 2010-05-02 9:08 ` Bart Schaefer 2010-05-03 18:57 ` Peter Stephenson 0 siblings, 2 replies; 8+ messages in thread From: Christoph Kappel @ 2010-05-01 21:02 UTC (permalink / raw) To: schaefer; +Cc: zsh-workers 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? > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Added builtins per runtime 2010-05-01 21:02 ` Christoph Kappel @ 2010-05-02 9:08 ` Bart Schaefer 2010-05-02 17:28 ` Christoph Kappel 2010-05-03 18:57 ` Peter Stephenson 1 sibling, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2010-05-02 9:08 UTC (permalink / raw) To: Christoph Kappel; +Cc: zsh-workers 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Added builtins per runtime 2010-05-02 9:08 ` Bart Schaefer @ 2010-05-02 17:28 ` Christoph Kappel 0 siblings, 0 replies; 8+ messages in thread From: Christoph Kappel @ 2010-05-02 17:28 UTC (permalink / raw) To: schaefer; +Cc: zsh-workers 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. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Added builtins per runtime 2010-05-01 21:02 ` Christoph Kappel 2010-05-02 9:08 ` Bart Schaefer @ 2010-05-03 18:57 ` Peter Stephenson 1 sibling, 0 replies; 8+ messages in thread From: Peter Stephenson @ 2010-05-03 18:57 UTC (permalink / raw) To: zsh-workers 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-05-03 19:26 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-05-01 16:33 Added builtins per runtime 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 2010-05-03 18:57 ` Peter Stephenson
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).