[BUG] parameter Module - functions_source associative array not working

[BUG] parameter Module - functions_source associative array not working

[Francisco de Zuviría Allende]

Versions 5.3 and 5.5

Can't get functions_source to work.

All of this comes out as empty:

echo "${(@k)functions_source}"
echo "${(@k)functions_source}"
echo $functions_source
echo "${functions_source[@]}"

$functions seem to be working alright

Best regards

Re: [BUG] parameter Module - functions_source associative array not working

[dana]

On 16 Jun 2018, at 22:12, Francisco de Zuviría Allende <franciscodezuviria@gmail.com> wrote:
>Versions 5.3 and 5.5
>
>Can't get functions_source to work.

AFAIK it wasn't introduced until 5.4, so that's probably expected in the former
case.

I can confirm that it behaves strangely in 5.4.2 and 5.5.1 — that seems to be
because it's not marked for auto-loading. The included patch fixes it (along
with dis_functions_source and usergroups); in the mean time you can kick it into
existence by running `zmodload -F zsh/parameter +p:functions_source` (or just
reloading the module entirely).

dana


diff --git a/Src/Modules/parameter.c b/Src/Modules/parameter.c
index 10c47d214..783c36df3 100644
--- a/Src/Modules/parameter.c
+++ b/Src/Modules/parameter.c
@@ -2190,6 +2190,7 @@ static const struct gsu_array dirs_gsu =
 static const struct gsu_array historywords_gsu =
 { histwgetfn, arrsetfn, stdunsetfn };
 
+/* Make sure to update autofeatures in parameter.mdd if necessary */
 static struct paramdef partab[] = {
     SPECIALPMDEF("aliases", 0,
 	    &pmraliases_gsu, getpmralias, scanpmraliases),
diff --git a/Src/Modules/parameter.mdd b/Src/Modules/parameter.mdd
index a91a5dc09..f71c17a72 100644
--- a/Src/Modules/parameter.mdd
+++ b/Src/Modules/parameter.mdd
@@ -2,6 +2,6 @@ name=zsh/parameter
 link=either
 load=yes
 
-autofeatures="p:parameters p:commands p:functions p:dis_functions p:funcfiletrace p:funcsourcetrace p:funcstack p:functrace p:builtins p:dis_builtins p:reswords p:dis_reswords p:patchars p:dis_patchars p:options p:modules p:dirstack p:history p:historywords p:jobtexts p:jobdirs p:jobstates p:nameddirs p:userdirs p:aliases p:dis_aliases p:galiases p:dis_galiases p:saliases p:dis_saliases"
+autofeatures="p:parameters p:commands p:functions p:dis_functions p:functions_source p:dis_functions_source p:funcfiletrace p:funcsourcetrace p:funcstack p:functrace p:builtins p:dis_builtins p:reswords p:dis_reswords p:patchars p:dis_patchars p:options p:modules p:dirstack p:history p:historywords p:jobtexts p:jobdirs p:jobstates p:nameddirs p:userdirs p:usergroups p:aliases p:dis_aliases p:galiases p:dis_galiases p:saliases p:dis_saliases"
 
 objects="parameter.o"

Re: [BUG] parameter Module - functions_source associative array not working

[Francisco de Zuviría Allende]

Thank you a lot dana,

Sometime next year (when I am not overworked and overassigned) I would
like to host some infrastructure for the zsh project (ticketing, C.I.,
stuff like that), so I might as well start getting some insight on the
dev process now. How does the patch you just submitted get integrated
in the mainline? Did you also make a pull request?

On Sun, Jun 17, 2018 at 4:33 PM, dana <dana@dana.is> wrote:
> On 16 Jun 2018, at 22:12, Francisco de Zuviría Allende <franciscodezuviria@gmail.com> wrote:
>>Versions 5.3 and 5.5
>>
>>Can't get functions_source to work.
>
> AFAIK it wasn't introduced until 5.4, so that's probably expected in the former
> case.
>
> I can confirm that it behaves strangely in 5.4.2 and 5.5.1 — that seems to be
> because it's not marked for auto-loading. The included patch fixes it (along
> with dis_functions_source and usergroups); in the mean time you can kick it into
> existence by running `zmodload -F zsh/parameter +p:functions_source` (or just
> reloading the module entirely).
>
> dana
>
>
> diff --git a/Src/Modules/parameter.c b/Src/Modules/parameter.c
> index 10c47d214..783c36df3 100644
> --- a/Src/Modules/parameter.c
> +++ b/Src/Modules/parameter.c
> @@ -2190,6 +2190,7 @@ static const struct gsu_array dirs_gsu =
>  static const struct gsu_array historywords_gsu =
>  { histwgetfn, arrsetfn, stdunsetfn };
>
> +/* Make sure to update autofeatures in parameter.mdd if necessary */
>  static struct paramdef partab[] = {
>      SPECIALPMDEF("aliases", 0,
>             &pmraliases_gsu, getpmralias, scanpmraliases),
> diff --git a/Src/Modules/parameter.mdd b/Src/Modules/parameter.mdd
> index a91a5dc09..f71c17a72 100644
> --- a/Src/Modules/parameter.mdd
> +++ b/Src/Modules/parameter.mdd
> @@ -2,6 +2,6 @@ name=zsh/parameter
>  link=either
>  load=yes
>
> -autofeatures="p:parameters p:commands p:functions p:dis_functions p:funcfiletrace p:funcsourcetrace p:funcstack p:functrace p:builtins p:dis_builtins p:reswords p:dis_reswords p:patchars p:dis_patchars p:options p:modules p:dirstack p:history p:historywords p:jobtexts p:jobdirs p:jobstates p:nameddirs p:userdirs p:aliases p:dis_aliases p:galiases p:dis_galiases p:saliases p:dis_saliases"
> +autofeatures="p:parameters p:commands p:functions p:dis_functions p:functions_source p:dis_functions_source p:funcfiletrace p:funcsourcetrace p:funcstack p:functrace p:builtins p:dis_builtins p:reswords p:dis_reswords p:patchars p:dis_patchars p:options p:modules p:dirstack p:history p:historywords p:jobtexts p:jobdirs p:jobstates p:nameddirs p:userdirs p:usergroups p:aliases p:dis_aliases p:galiases p:dis_galiases p:saliases p:dis_saliases"
>
>  objects="parameter.o"
>

Re: [BUG] parameter Module - functions_source associative array not working

[dana]

On 27 Jun 2018, at 04:28, Francisco de Zuviría Allende <franciscodezuviria@gmail.com> wrote:
>Sometime next year (when I am not overworked and overassigned) I would
>like to host some infrastructure for the zsh project (ticketing, C.I.,
>stuff like that), so I might as well start getting some insight on the
>dev process now. How does the patch you just submitted get integrated
>in the mainline? Did you also make a pull request?

I just merged it directly since nobody objected. zsh doesn't use PRs for most
changes, just the mailing list. (Oliver had set up a system where people could
submit GitHub/GitLab PRs for completion functions, but i'm not sure how often
it's used.)

I'm a very minor player in this project so my opinion doesn't mean much, but i
do think an issue tracker would be nice, if only as a place to catalogue known
bugs. It's just that most of the people who do the really *heavy* work on the
project prefer the ML. (See workers/37428, users/22326, workers/43054....)
Having a separate tracker going on the side seems like a possibility, but it
raises a lot of maintenance/logistics questions.

Does the ML just get subscribed the to the GH/GL project and linked that way, or
do the tracker maintainers need to act as manual go-betweens? Will the
ML-preferring people want to keep track of both a sequence number and an issue
number, or will again a tracker maintainer need to keep the two processes
synchronised manually? &c.

I don't know, but it would need thought put into it, and several key people
would need to be invested.

dana

Re: [BUG] parameter Module - functions_source associative array not working

[Francisco de Zuviría Allende]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

Then I guess the best way is to keep the ML and have the ticket system
interface with the ML in a bot-like fashion. Ill think about it and propose
something next year... thanks!

On Wed, Jun 27, 2018, 2:08 PM dana <dana@dana.is> wrote:

> On 27 Jun 2018, at 04:28, Francisco de Zuviría Allende <
> franciscodezuviria@gmail.com> wrote:
> >Sometime next year (when I am not overworked and overassigned) I would
> >like to host some infrastructure for the zsh project (ticketing, C.I.,
> >stuff like that), so I might as well start getting some insight on the
> >dev process now. How does the patch you just submitted get integrated
> >in the mainline? Did you also make a pull request?
>
> I just merged it directly since nobody objected. zsh doesn't use PRs for
> most
> changes, just the mailing list. (Oliver had set up a system where people
> could
> submit GitHub/GitLab PRs for completion functions, but i'm not sure how
> often
> it's used.)
>
> I'm a very minor player in this project so my opinion doesn't mean much,
> but i
> do think an issue tracker would be nice, if only as a place to catalogue
> known
> bugs. It's just that most of the people who do the really *heavy* work on
> the
> project prefer the ML. (See workers/37428, users/22326, workers/43054....)
> Having a separate tracker going on the side seems like a possibility, but
> it
> raises a lot of maintenance/logistics questions.
>
> Does the ML just get subscribed the to the GH/GL project and linked that
> way, or
> do the tracker maintainers need to act as manual go-betweens? Will the
> ML-preferring people want to keep track of both a sequence number and an
> issue
> number, or will again a tracker maintainer need to keep the two processes
> synchronised manually? &c.
>
> I don't know, but it would need thought put into it, and several key people
> would need to be invested.
>
> dana
>
>