#1346 path/host completion for custom types

This is an early PR for issue https://github.com/remkop/picocli/issues/1346
The goal is to ask for feedback before going further.
I haven't found a CONTRIBUTING.md, therefore I have a few process oriented questions.

What is the java version to use? I saw some java 5 mentioned in the build.gradle, but it seems travis only builds on JDK 8 and above?
Is there a commit/branch/pr naming convention?
How to write tests/which level of testing is deemed acceptable?

Concerning the issue in itself, I used a slightly different approach to avoid to pass the extra argument all the way around in the AutoComplete command.
This has the advantage that in case the auto-complete is embed as a subcommand, it is possible to programmatically register the path completion types as done for the type converters.
The path completion types are directly stored in the CommandLine and not in the Interpreter as I thought it is does not belong to the interpreter. But I'm not 100% sure of what the interpreter is, so let me know if you think I should move it inside.
What remains to be done:

AutoComplete error handling in case the class is not found in the classpath
Writing unit tests for the additional CommandLine methods
Writing additional integration tests (subcommands for example)
Updating documentation to mention this new feature and how to use it

What does not work:

I did a quick test and the completion of path list only works for the first argument. There is no completion given for the second and I suspect it's also not working with a separator. But this is way out of scope of this issue/pr

Let me know what you think of the current approach and I'll move forward with your feedback
Regards,

First, thanks for pointing out the lack of a Contributing document. I just added one to the project. It's a first version, and suggestions for improvement this document are very welcome! 👍 😉
About the PR, my intention was to not reflect this in the CommandLine model, and keep the change limited to the AutoComplete class. If anything, this is a concern of the completion, not the command.
About the new option, I am not sure if there should be a short option. Providing a short option signals to end users that this is a common thing to do, common enough to provide a shortcut. Providing only a long option signals that this is possible but optional; this seems most appropriate.
Can I ask you to change the above?

I did a quick test and the completion of path list only works for the first argument. There is no completion given for the second and I suspect it's also not working with a separator. But this is way out of scope of this issue/pr

That is interesting. Looks like an existing bug. Would you mind raising a separate issue for this? (Ideally with how to reproduce it)

First, thanks for pointing out the lack of a Contributing document. I just added one to the project. It's a first version, and suggestions for improvement this document are very welcome! 👍 😉

👍 Great, I'll take a look

About the PR, my intention was to not reflect this in the CommandLine model, and keep the change limited to the AutoComplete class. If anything, this is a concern of the completion, not the command.

❓ I thought the same but then I wondered how to have this as part of the application when the application having picocli.AutoComplete#GenerateCompletion as a subcommand.
So far, I only see sub-classing picocli.AutoComplete#GenerateCompletion and overriding the run method to set the parameters, but I'm not sure it's a great solution. Do you have a better solution for this?

About the new option, I am not sure if there should be a short option. Providing a short option signals to end users that this is a common thing to do, common enough to provide a shortcut. Providing only a long option signals that this is possible but optional; this seems most appropriate.

👍 I will remove the short option.

I did a quick test and the completion of path list only works for the first argument. There is no completion given for the second and I suspect it's also not working with a separator. But this is way out of scope of this issue/pr

That is interesting. Looks like an existing bug. Would you mind raising a separate issue for this? (Ideally with how to reproduce it)

Sure, that was on my list to create an issue. I will first create a reproducer to ensure I did not had a weird setup leading to this behavor.

❓ I thought the same but then I wondered how to have this as part of the application when the application having picocli.AutoComplete#GenerateCompletion as a subcommand.
So far, I only see sub-classing picocli.AutoComplete#GenerateCompletion and overriding the run method to set the parameters, but I'm not sure it's a great solution. Do you have a better solution for this?

One idea is to have a custom generate-completion command that (in its run method) invokes the built-in picocli.AutoComplete#GenerateCompletion command with the desired options.

One idea is to have a custom generate-completion command that (in its run method) invokes the built-in picocli.AutoComplete#GenerateCompletion command with the desired options.

👍 Ok, I'll write a test to for this too

Short option removed
CommandLine modifications reverted
host custom completion added (it's the same mechanism than the path one)

Before moving forward with documentation and better test coverage (Sub-command mode, @Parameters use case), I'd like your opinion on the TypeCompletionRegistry I introduced in the AutoComplete command.
It only handles dynamic completions (path/host) and not static ones CommandLine#completionCandidates().
If you think it would make sense to do so, then the problem is more complicated as the notion of @Options and @Parameters have to be given to the TypeCompletionRegistry method which implies that the return of method TypeCompletionRegistry#forType is not an enum anymore, but an object that knows how to generate the shell autocomplete code.
I don't wanna go all this way for which I see little benefits now, but maybe you have another opinion.
Let me know.

Your TypeCompletionRegistry has got me thinking...
Thank you for putting in all this effort!
This prototyping makes it very concrete and makes it easier to see pros and cons.
I feel a bit guilty that you are putting in all this effort but I don't feel we have arrived at the best solution yet.
Would you mind discussing a bit more and considering more options?
I was thinking... Perhaps it would be nicer to not have to specify type names on the command line. I can see that now.
At the same time, I still believe that this information should not live in the CommandLine or CommandSpec model. (And perhaps I am wrong about this, that is possible. It's just that I want to explore alternative approaches first.)
I thought of an alternative (there may be other ideas too, let me know).
Perhaps we can introduce an annotation like @picocli.AutoComplete.HostCompletion and similar for File/Path, something like that, exact name TBD...
Then applications can annotate the option, something like this:
class MyCommand {

    @picocli.AutoComplete.FileCompletion
    @Option(names = "...")
    List<Repository> repositories;

Not sure if that can be made to work without eventually pulling this into the ArgSpec model...
An alternative is to annotate the custom type itself:
@picocli.AutoComplete.FileCompletion
class Repository { ... }

This would be easier to implement (in the AutoComplete class without changing the ArgSpec model), but perhaps less convenient for users because this type may be not under their control (what if Repository is a library type)...
Thoughts?

Haha, don't worry about this, I totally understand your points and I know of experience things are easy until you get into details.
Also here, it will impact the public API of Picocli, so better put some thoughts into it 😉
I'm not a big fan of the second approach for the exact reason you mentioned. In case you don't have control over the type itself (third-party library). But also for a question of separation of concerns as it would make this type aware of being used in a CLI environment.
Regarding the extra annotation on the options/argument itself, it's nice as it would be possible to only read it in the AutoComplete itself, thus, not affecting the CommandLine nor ArgSpec. However, it forces you to perform this declaration everywhere the type is used as an @Option / @Parameters, which, I will for sure forget somewhere when using it.
An alternative approach which I'm not completely satisfied with, is to put this annotation on implementations of the TypeConverter. At first glance it looks weird, but on the other hand, the TypeConverter acts as a bridge between a custom type and a command line aware type. In some ways, adding the annotation there would indicate how to convert the type to its auto-complete counterpart.
It could also be a default method on it TypeConverter.
But then the AutoComplete command would need the TypeConverters to be given in input as they are not part of the main command.
I tried to summarize below the different approaches with their pros/cons.

CommandLine/CommandSpec:

✅ : centralized
❌ : extra args to the AutoComplete standalone command: --pathCompletionsType,--hostCompletionsType
✅ : no need for extra args to AutoComplete in sub-command modes. The CommandLine is already configured

Independent TypeCompletionRegistry:

✅ : centralized
❌ : extra args to the AutoComplete standalone command: --pathCompletionsType,--hostCompletionsType
❌ : complicated to be used as a sub-command mode (still need to figure out the proper usage pattern).

Arguments annotations (@picocli.AutoComplete.FileCompletion, ...)

❌ : Not centralized. To be repeated for every single @Option/@Parameters of the given type.
✅ : no need for extra args to AutoComplete in standalone command
✅ : no need for extra args to AutoComplete in sub-command modes.

Annotations on the TypeConverter

✅ : Centralized
❌ : extra args to the AutoComplete standalone command: --typeConverters,
✅ : no need for extra args to AutoComplete in sub-command modes. The TypeConverters are already registered

Other solution: ???

PS 1: I did not include the fact you don't like this info to be part of the CommandLine/CommandSpec model simply because I don't really know how to phrase it in the above summary. But we have to keep it in mind.
PS 2: If the solution we go for can also support future evolution (for example a dynamic option that would call the app itself with the current command line context) that would be amazing.

Above force push was to fix the author email in the commits.
Regarding the possibles solutions, I can't think of any other viable/acceptable ones for the moment.
Looking at the previously mentioned ones, my preference goes to the annotations on the TypeConverter approach which allows:

a single declaration of Type to completion mode
no extra fields in the CommandLine/CommandSpec model
a single extra parameter to the AutoComplete: --typeConverters
a compatible approach with the existing AutoComplete in sub-command mode

Regarding the semantics of the TypeConverter, I think it is acceptable to add completions annotations on it. In a way, a TypeConverter explains how to convert the CLI input into a custom type. Auto complete can be IMHO part of what we consider the CLI input in this context.
WDYT?

Sorry for my late reply. It is getting hard recently to find time to sit down and really think about this and other picocli tasks... :-)
Annotations on the TypeConverter
One disadvantage of the TypeConverter idea is that I believe many type converters may be specified as a lambda, like this:
new CommandLine(new MyApp())
    .registerConverter(Cipher.class, s -> Cipher.getInstance(s))
    .execute(args);

...so, many type converters may not be a full-fledged class to begin with - meaning, no place to put an annotation.
It also "feels" a bit like we are conflating two separate concerns here; the job of a type converter is to convert user input Strings into some other type. I can see how it could be made to work, but it seems that there must be a cleaner way to do this that is still convenient for users.
Arguments annotations (@picocli.AutoComplete.FileCompletion, ...)
In your analysis of various approaches and their pros and cons (very helpful, by the way, thank you for that!), about the first point:

x : Not centralized. To be repeated for every single @Option/@Parameters of the given type.

I am not sure how much of a disadvantage this is: I imagine this annotation would only need to be specified on a handful of options (I could be wrong of course).
Your point can also be taken as an advantage: is it possible that some applications want the built-in shell file/host completion for some options and custom completionCandidates for other options of a given custom type? It may be rare, but this design does make it possible, at the cost of diminished convenience. (So I guess the question is: how heavy is this cost vs. how valuable is this flexibility.)

Out of the options we have considered so far, I like argument annotations  (@picocli.AutoComplete.FileCompletion, ...) the best, but I am not sure how easy this would be to implement, or even whether there is another approach/design altogether that we haven't considered yet.

Hello, no problem 😉
Here is some context for: "Not centralized. To be repeated for every single @Option/@Parameters of the given type".
I'm currently working on a project named symly (the name might change) where I have two important notions: Repository and SourceDirectory (here also the names might change).
They both are basically Path and have there type converters here: https://github.com/loicrouchon/symly/tree/main/src/main/java/org/symly/cli/converters.
The project would consist of several subcommands: link, status, add, remove, clean, unlink, ...
In all of those commands I would need to have Repository and SourceDirectory. But not always in the same form, sometimes a list, sometime just one, ... So it makes it not so easy to factorize it.
Having to repeat it is not the end of the world, but testing the auto-complete is properly generated is not super handy. So I fear I'll forget the annotations somewhere and have a not so great auto-complete script.
I know this is a "me" problem 🤣  as I could (and should) test the auto-complete generated script of my CLI.
To summarize: I like the annotations approach. Putting on @Option/@Parameters might be a bit more work for the developers when the type is used a lot in their CLI. But I agree it's not a significant one, so let's go for this approach 🙌
I will give it a few thoughts, this week, but I have a few other questions:

What should we do about the completionCandidates attribute of the existing @Option/@Parameters. Should we mark it as deprecated and ask users to use a new custom annotation for auto-complete?

Regarding the design, how many annotations should there be?

@AutoComplete(kind = FILE|HOST|STATIC, [candidates = {""}])
@AutoComplete.HostCompletion, @AutoComplete.FileCompletion(type = DIRECTORY|FILE, filter="*"), @AutoComplete.StaticCompletion(candidates={""}), [@AutoComplete.DynamicCompletion(cmd = "complete")]

From what I see the general approach in picocli is to have big annotations like @Option/@Parameters, but in this context, I feel the multi annotations approach would be the more flexible/extensible.

I will give it a few thoughts, this week, but I have a few other questions:

What should we do about the completionCandidates attribute of the existing @Option/@Parameters. Should we mark it as deprecated and ask users to use a new custom annotation for auto-complete?
Regarding the design, how many annotations should there be?

@AutoComplete(kind = FILE|HOST|STATIC, [candidates = {""}])
@AutoComplete.HostCompletion, @AutoComplete.FileCompletion(type = DIRECTORY|FILE, filter="*"), @AutoComplete.StaticCompletion(candidates={""}), [@AutoComplete.DynamicCompletion(cmd = "complete")]

Reading your questions I got the strong sense that this approach (annotations on options/parameters) is the right approach. Still a lot to discover and flesh out, but this feels like the right direction!

From what I see the general approach in picocli is to have big annotations like @Option/@Parameters, but in this context, I feel the multi annotations approach would be the more flexible/extensible.

Picocli's @Option/@Parameters annotations are successful because they are simple and intuitive, and make it easy for users to get started and find more detail later as needed. There is still flexibility and extensibility since annotations allow new attributes to be added later (for example, completionCandidates was not there from the beginning). I would like to use the same approach here.

What should we do about the completionCandidates attribute of the existing @Option/@Parameters. Should we mark it as deprecated and ask users to use a new custom annotation for auto-complete?

To me, marking something as deprecated expresses an intention to eventually remove it. I do not have such an intention (picocli is very big on being backwards compatible), so it is not necessary to deprecate the completionCandidates attribute. It is simple and works fine, there is no need to disrupt applications that are currently using it.

Regarding the design, how many annotations should there be?

That question (of what shape the solution should take) will come up at some point, and we are not that far away from that point, but I would like to explore the problem space a bit further first.
(Thinking out loud)
What is the problem we are trying to solve? Perhaps to improve auto-completion in any and all ways we can think of. What kinds of auto-completion exist? I can think of built-in completion by the shell (bash, zsh, other unix shells, jline, ...); any static list of words that is known at compile time (Java enums are a special case of this); a "dynamic" list of words that is not known until runtime. (Is that all kinds of auto-completion? Can you think of another one?)
The "dynamic" one is interesting but needs more thought: This "runtime" we are speaking of, is this not actually auto-completions script generation time (as opposed to truly auto-completion script runtime)? What can we do at completion script generation time, and what can we do at generation script runtime? Can we/Would we want to support an annotation (or annotation attribute) where end users can specify a bash snippet that is executed at auto-completion script runtime to generates completion candidates? (Or zsh, or some other shell scripting language?)

Reading your questions I got a strong sense that this approach (annotations on options/parameters) is the right approach. Still a lot to discover and flesh out, but this feels like the right direction!

:+1:
The problem we are trying to solve:

Allow the specification of File/Host auto-complete for @Option/@Parameters of given custom types.

This can be generalized as:

Allow the specification of the auto-complete behavior for @Option/@Parameters of given custom types.

Which can then be generalized again as:

Allow the specification of the auto-complete behavior for @Option/@Parameters

This means:

It would be possible to override the auto-complete behavior of built-in types (for example, only a subset of enum values can be used in a particular sub-command)
The auto-complete behaviors list has to be defined. What is supported now, what can be in the future.

Possible behaviors
The possible auto-complete behaviors I can think of are:

Default shell completion
Static list of values
Path completion
Host completion
User completion
Group completion
Job completion
Service completion
Signal completion
Shell environment variable completion
Shell variable completion
Dynamic shell completion (executed on <TAB><TAB>)
Dynamic completion (executed on <TAB><TAB>)
Dynamic Picocli completion (executed on <TAB><TAB>)
Custom completion

Default completion
Disable the completion for the @Option/@Parameters.
Useful to disable the built-in completion.
Static list of values
This list could be built automatically (boolean, enum) or manually (completionCandidates).
This list could also be generated at compile time from a user defined source (file list, custom method call, ...).
Path completion
Path completion could be automatically generated for java.io.File and java.nio.file.Path or manually.
When manually specified, it is possible to configure the behavior more in details, it would need to be specified.
The path completion could be customized with the following options:

Specifying a file pattern filter (globpat vs filterpat)
Only match files
Only match directories

Host completion
Host completion could be automatically generated for java.net.InetAddress or manually.
User completion
User completion auto-complete with system user names
Group completion
Group completion auto-complete with system group names
Job completion
Job completion auto-complete with system jobs.
It has to be configured to specify either running or stopped ones.
Service completion
Service completion auto-complete with system service names.
Signal completion
Signal completion auto-complete with system signal names.
Environment variable completion
Environment variable completion auto-complete with shell environment variable names.
Variable completion
Variable completion auto-complete with system shell variable names.
Dynamic shell completion
Dynamic shell completion would allow to execute on <TAB><TAB>, a shell function in the current shell environment, and its output is used as the possible completions.
Part of the current state of the command being written would be passed as arguments to this function.
It also could be supported to allow the user to define shell functions that would be included in the auto-complete shell scripts, so that they can be referenced here.
Dynamic command completion
Dynamic completion would allow to execute on <TAB><TAB>, an arbitrary command in a subshell environment, and its output is used as the possible completions.
Part of the current state of the command being written could be passed as arguments to this function. (feasibility to be assessed).
Dynamic Picocli completion
Dynamic Picocli completion would allow to execute on <TAB><TAB>, an arbitrary picocli command of the current program in a subshell environment, and its output is used as the possible completions.
Part of the current state of the command being written could be passed as arguments to this function. (feasibility to be assessed).
This might be a tricky one to implement but it could give great flexibility in having a sub-command specialized in reacting to <TAB><TAB> events.
Custom completion
Custom completion would allow the user to specify the autocomplete command.
This would be implementation dependent.
Those proposition are based on what is currently possible to implement in bash as per the bash completion documentation.
The above list is for brainstorming only, they might(/should?) not all be implemented, at least, not in this ticket.
I hope this clarifies the list of things that could be supported

@loicrouchon, glad to see this effort, as I'm in need of the "Custom completion" functionality you've described above.
The details of my use case are specific to my application, but for our purposes here, I'm looking to create completion functionality similar to the way git checkout works. It allows the user to tab-complete for available refs:
$ git checkout <tab><tab>
FETCH_HEAD         HEAD               ORIG_HEAD          REBASE_HEAD        main               v2.0.0-prototype

and it allows for tab-completing a partially written ref out to its full name:
$ git checkout v2.<tab>
  ... autocompletes to ...
$ git checkout v2.0.0.-prototype

This is obviously Git-specific functionality, and Git needs to look into its own object database to generate the completion candidates. I need to be able to do something similar in my own application.
Ideally, I'd like to be able to tell Picocli that auto-completion candidates for a given @Option value or for positional parameters to a given @Command should be produced by, let's say, an implementation of Picocli's (proposed new) IAutoCompletionCandidateProvider interface.
I would want to be able to run any arbitrary code in that implementation, and I would want to have access to the Picocli context it's running in, e.g. to have access to the current (sub)command's @Spec, ParseResult, etc.
I would think this most general kind of candidate provider hook would be the first thing to implement, and then more specific conveniences such as the ones @loicrouchon mentioned above could be built on top of it.
@remkop, do you generally agree?  @loicrouchon, do you plan to return to work on this effort? Thanks to you both.

Hello @cbeams
Yes, I would like to continue to work on this. At least on the narrow scope of the path/host completion for custom types. But the dynamic completion will not be part of this pr as it has its own dedicated issue: https://github.com/remkop/picocli/issues/506.
However I feel both issues need some common design which we started to discuss above. As I'm not the owner of the project I can propose ideas, and submit a PR. But I would need some feedback from @remkop to be able to move forward and propose a solution in line with the picocli (great) way of doing things.

Looking at recent comments by @gunnarmorling and @yschimke in https://github.com/remkop/picocli/issues/506, it may be interesting to tie these together.
(Thinking out loud) what if we introduce a new annotation, say AutoComplete.Generator that has a single String value:
public class AutoComplete { // existing class picocli.AutoComplete

    // new nested interface
    @Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.TYPE})
    @Retention(RetentionPolicy.RUNTIME)
    public @interface Generator {
        String value(); // command to be executed by the shell to generate completion candidates

        String shell() default "bash";
    }
   //...

This annotation can be used on any element that is also annotated with @Command, @Option or @Parameters.
The value would be a command that can be executed by the shell when the user triggers command line completion (by pressing <TAB><TAB> in bash, for example). It is the responsibility of this command to print a list of completion candidates to the standard output stream. On Bash this would be a space-separated list of words.
This could then be implemented by a hidden subcommand.
Here is an example of how this annotation could be used:
@Command(name = "mycommand")
public class MyCommand implements Runnable {

    @AutoComplete.Generator("mycommand generateCompletionsForMyCustomType")
    @Option(names = {"-o", "--my-option"})
    MyCustomType myType;

    @Command(hidden = true) // hidden subcommand of mycommand
    public void generateCompletionsForMyCustomType(@Unmatched String[] ignored) {
        String[] myCompletions = dynamicallyGenerateCompletionsForMyCustomType();
        System.out.println(String.join(" ", myCompletions);
    }

    public void run() { // business logic of MyCommand
    }
}

The model would need to be updated to get the CommandLine.Model.GeneratorSpecs for each command, option or positional parameter (there may be multiple, one for each shell). The GeneratorSpec's value would return the annotation value.
The AutoComplete class would need to be updated: if a CommandSpec, OptionSpec or PositionalParamSpec has a GeneratorSpec, then use the value from the GeneratorSpec in the completion script.
One idea (again, just thinking out loud, this may not work...) would be:
// AutoComplete.java
    private static void generateCompletionCandidates(StringBuilder buff, OptionSpec f) {
        GeneratorSpec custom = f.completionGenerator("bash");
        if (custom != null) {
            buff.append(format("  local %s_option_args=$(%s) # %s values\n",
                    bashify(f.paramLabel()),
                    custom.value(),
                    f.longestName()));
        } else {
            buff.append(format("  local %s_option_args=\"%s\" # %s values\n",
                    bashify(f.paramLabel()),
                    concat(" ", extract(f.completionCandidates())).trim(),
                    f.longestName()));
        }
    }

Implementation note: the value of the %s_option_args is still passed to the compgen builtin, so that partial user input is used to filter out completion candidates that do not match the user input.

In the above example, the generator spec value is a picocli subcommand, but it does not have to be, it can be any script or function. For example, for the use case where only a subset of an enum are valid completions for some subcommand, the value could simply use echo:
@Command
public class SomeCommand {
    @AutoComplete.Generator("echo HOURS MINUTES SECONDS")
    @Option(names = "--time-unit")
    TimeUnit timeUnit;
}

Or another use case: a Path option for which we only want to list files with the .txt extension in the current directory:
@Command
public class SomeCommand {
    @AutoComplete.Generator("ls . | grep *.txt")
    @Option(names = "--file")
    Path myFile;
}

This would allow dynamic completion, and developers would not need to modify the generated bash completion script (which is what I believe @gunnarmorling and @yschimke ended up doing in #506).
Thoughts?

Hey @remkop, this looks like a good direction. A few thoughts and questions:
@AutoComplete.Generator("mycommand generateCompletionsForMyCustomType")

It's worth considering that mycommand may not be on the user's $PATH. They may be invoking the command relatively, e.g. with ./mycommand, and in that case, bash is going to error out with mycommand: command not found. Up until now, there's been nothing about the way Picocli's bash completion scripts work that has required the command to be on the $PATH, but that would change now. This may just be something to document as a caveat or limitation, but it would be great if there were some way to support the case of a relatively-invoked command. Something like accessing $0 within a bash script to get the relative path to the script being run.

Regarding shell-specific completion generators and the need for the @AutoCompletion.Generator#shell attribute: what would typically differ between bash and zsh? Would it become the case that hidden generator commands would need to be written for both shells in most / all cases? So far, picocli's autocompletion functionality has been blissfully shell-agnostic from the command author's side. It would be unfortunate to break this abstraction here, though perhaps necessary to do so. In the case where shell-specific generation logic is necessary, would the @Generator annotation be repeated? For example
@AutoComplete.Generator(value="mycommand generateBashCompletionsForMyCustomType", shell="bash")
@AutoComplete.Generator(value="mycommand generateZshCompletionsForMyCustomType", shell="zsh")
@Option(names = {"-o", "--my-option"})
MyCustomType myType;

In the declaration of the hidden generator command, what is the significance or necessity of the @Unmatched String[]here?
public void generateCompletionsForMyCustomType(@Unmatched String[] ignored) {...}

Regarding filtering autocompletion candidates based on partial user input:

Implementation note: the value of the %s_option_args is still passed to the compgen builtin, so that partial user input is used to filter out completion candidates that do not match the user input.

This part is very important to my own use cases. If I understand correctly, you're talking about making sure it's possible to implement filtered completions, a la the way git checkout is able to filter available branch names based on partial user input:
$ git branch foo
$ git branch bar
$ git branch baz
$ git checkout b<tab>
bar baz

You mention that this partial user input is passed to the compgen builtin on the bash side, but shouldn't it also be made available to the completion generator method on the Java side? It may be desirable to do the filtering up front instead of generating and returning all completion candidates to the shell.

Regarding @Generator#value being able to support any command, e.g. echo or ls, I agree that this makes sense and is nice to have, but it should probably come with at least a documentation caveat that doing so binds the implementation to a system that has those commands available. This is perhaps obvious enough, but perhaps worth mentioning that where portability matters, the best practice would be to wrap such functionality in a hidden command that can do the right thing in an os-agnostic way.

Finally, regarding the string value provided to the @Generator annotation:
@AutoComplete.Generator("mycommand generateCompletionsForMyCustomType")
@Option(names = {"-o", "--my-option"})
MyCustomType myType;

Perhaps the fragile string could be avoided by (optionally) allowing the user to provide an implemantion of, say, IAutoCompletionGenerator, e.g.:
@AutoComplete.Generator(type=MyCustomTypeAutoCompletionGenerator.class)
@Option(names = {"-o", "--my-option"})
MyCustomType myType;

where MyCustomTypeAutoCompletionGenerator implements a generate method that produces the same results as the generateCompletionsForMyCustomType method would have, and then under the hood, picocli will automatically register a hidden command whose name is based on convention. The overall functionality would be the same as you've proposed, but without the depending on stringified method names.

It's worth considering that mycommand may not be on the user's $PATH. (...)

Agreed. We should experiment with what gives the most robust result and document that.

Regarding shell-specific completion generators and the need for the @AutoCompletion.Generator#shell attribute: (...) Would it become the case that hidden generator commands would need to be written for both shells in most / all cases?

Possibly yes once support is added for additional completion scripts like Zsh (#294), Fish (#725), Yori (#1062), PowerShell (#922) and clink (#921). This may never happen, but it impacts the API of the model, so I want to build it in up front.

(...) In the case where shell-specific generation logic is necessary, would the @Generator annotation be repeated? For example
@AutoComplete.Generator(value="mycommand generateBashCompletionsForMyCustomType", shell="bash")
@AutoComplete.Generator(value="mycommand generateZshCompletionsForMyCustomType", shell="zsh")
@Option(names = {"-o", "--my-option"})
MyCustomType myType;

Yes, although strictly speaking we may then need to wrap it in a Generators annotation whose value is an array of Generator annotations (repeatable annotations were not introduced until Java 8 and picocli supports Java 5). User code would then look like this:
 @AutoComplete.Generators({
     @AutoComplete.Generator(value="mycommand generateBashCompletionsForMyCustomType", shell="bash"),
     @AutoComplete.Generator(value="mycommand generateZshCompletionsForMyCustomType", shell="zsh")})
 @Option(names = {"-o", "--my-option"})
 MyCustomType myType;

Regarding filtering autocompletion candidates based on partial user input:
(...)
You mention that this partial user input is passed to the compgen builtin on the bash side, but shouldn't it also be made available to the completion generator method on the Java side? It may be desirable to do the filtering up front instead of generating and returning all completion candidates to the shell.

In Bash completion, this is possible by passing  "${curr_word}" to your custom completion generator command:
@AutoComplete.Generator("mycommand generateMyCompletions -- \"${curr_word}\"")

We would need to document this. (See also the answer to your next question below.)

In the declaration of the hidden generator command, what is the significance or necessity of the @Unmatched String[]here?
@Command
public void generateMyCompletions(@Unmatched String[] ignored) {...}

You are right, this is not necessary. I had not thought that through yet when I wrote it.
I was still debating on whether we always pass ${curr_word} to the command or not. However, that may not be desirable to support cases like the echo and ls command I mentioned.
If  "${curr_word}" is passed to your custom completion generator command, then the partial user input would be passed as a positional parameter to the generateMyCompletions command. Your implementation could then use it to filter the output.
You could then write it as:
@Command
public void generateMyCompletions(@Parameters String[] partialInput) {...}

Regarding @Generator#value being able to support any command, e.g. echo or ls, I agree that this makes sense and is nice to have, but it should probably come with at least a documentation caveat that doing so binds the implementation to a system that has those commands available. This is perhaps obvious enough, but perhaps worth mentioning that where portability matters, the best practice would be to wrap such functionality in a hidden command that can do the right thing in an os-agnostic way.

I appreciate that, but another way to look at it is that, since shell completion will always be very shell-specific, we do have some additional freedom that the pure Java world does not have. :-)

Finally, regarding the string value provided to the @Generator annotation:
@AutoComplete.Generator("mycommand generateCompletionsForMyCustomType")
@Option(names = {"-o", "--my-option"})
MyCustomType myType;

Perhaps the fragile string could be avoided by (optionally) allowing the user to provide an implemention of, say, IAutoCompletionGenerator, e.g.:
@AutoComplete.Generator(type=MyCustomTypeAutoCompletionGenerator.class)
@Option(names = {"-o", "--my-option"})
MyCustomType myType;

where MyCustomTypeAutoCompletionGenerator implements a generate method that produces the same results as the generateCompletionsForMyCustomType method would have, and then under the hood, picocli will automatically register a hidden command whose name is based on convention. The overall functionality would be the same as you've proposed, but without depending on stringified method names.

Maybe yes, especially from the point of view of integrating this in a JLine shell. In that scenario, the completion generator will be invoked in the same Java process that is running JLine and in which the command will be executed. This means it is easier to share state between the completion logic and the command, without going to the file system or a database, for example. I have not thought this scenario through enough though.
I am not sure yet about the trade-off between string fragility on the one hand and the complexity of automatically generated hidden commands with some convention-based name on the other hand. The proposed solution has less magic, which may be important since this stuff is already complex enough as it is... :sweat_smile:

Great feedback! Thank you!


fix(zendesk): Fix missing TE description

:star2: What does this PR do?
Fix code to get the TE description based on the current ticket title. Also, a small improvement on the customer navigation button.
:bug: Recommendations for testing

Get a Zendesk account
Open the ticket view
Check if when starting the timer te description is the same as the ticket title

:memo: Links to relevant issues or information
close #1794

But even beside that, I noticed that the button is readily available on a ticket that is in process of being created, but its description is not picked when starting a timer. Only when viewing an already created ticket.

Good catch ❤
This can be possibly fixed by changing const titleElem = elem.querySelector(...) to a function 🤔

Found a bug, when you have more than one ticket open it will always get the values from the first ticket.

Found a bug, when you have more than one ticket open it will always get the values from the first ticket.

It should be fixed now.

But even beside that, I noticed that the button is readily available on a ticket that is in process of being created, but its description is not picked when starting a timer. Only when viewing an already created ticket.

I'm not sure if this is really something that worth doing, we don't have the id of the ticket yet and the user is only creating the ticket that he may or may not start right after. Also, I was unable to find a good selector to get the title 🙈


Fix CI error, use yarn to install semver

Description
NPM is a bit more strict than yarn when checking peer dependencies. We're currently (knowingly) using mistmatching rollup plugin packages because an update hasn't been done by that package yet so when we run npm instal semver NPM is throwing an error. Yarn is graceful about it and only warns so switching to it.
Checklist
n/a
Resolves
n/a

cc: @matteosacchetto

Here's a link to the currently failing github action
https://github.com/rayepps/radash/actions/runs/3381746602/jobs/5615974218

Sorry about this, didn't check with npm, only with yarn and it was simply giving a warning
If you wanted to use npm you could allow this with npm install <whatever> --legacy-peer-deps, but yeah moving to yarn is a good choice.
In case the rollup-esbuild-plugin gives issues in the future we could simply remove it and rely on @rollup/plugin-typescript while we wait for it to be updated. It is slower in the ts to js transpilation but still acceptable
If this will be the case feel free to open an issue and assign it to me, I will happily fix it 😉


[ONBOARDING]  [Update] General Member - Comcast

TODO General Member Onboarding
This is an issue created to onboard new TODO Group General Members.
Organization
Comcast
New Member

Anu Sha

Contact Information

[x] For each representative of the General Member company, collect the
following:

name
pronouns
company email address
GitHub username
whether or not the representative is the primary contact for the company

[ ] Update the members list to included the collected contact information at governance repo

Communication channels
Ensure that member representatives have joined the following:

[x] TODO Group Slack
[ ] Community Mailing List

GitHub

[x] Invite members to the Core GitHub team
(this will send them an invite to the GitHub organization and grant them
access to private repositories)

Private channels
Add members to the following:

[x] General Member mailing list
[x] General Member Slack channel: #private

Meetings and Calls
Google Groups should automatically invites members to meetings, but ensure that
they have invites for the following meetings:

[x] General Members Touchpoint

Resources and initiatives

[x] Ensure members are aware of the General Members onboarding guide

name - Anusha Pavuluri
pronouns- She/Her
company email address -<EMAIL_ADDRESS>GitHub username - anu1025sha
whether or not the representative is the primary contact for the company - No

Thanks for the info @Anu1025sha ! I've given you access to the general member ML with your Gmail email since the Comcast one was giving me an error when adding you to the list. I've also sent you and invite via<EMAIL_ADDRESS>that you would need to accept within 10 days to add you as a member of the core team in the TODO Group GitHub organization.

You can join the community mailing list here: https://lists.todogroup.org/g/community


Remove UnsafeUserParameters

This parameter is a little confusing, after some no luck google attempts,  I found this: https://bugzilla.redhat.com/show_bug.cgi?id=1037941
Zabbix documents are all there, but seems a little disconnected from each other.
UnsafeUserParameters is meant for limiting "Flexible user parameters",
we are using "Simple user parameters" only in this config file. Default
value is safer, and by not setting this at all, it will be easier to
manage when we need to set this in another config file in the future.

Thank you for your pull request! I will merge now :)


mp4 metadata move

I'm trying to play mp4 files over http, but iOS devices download the whole file, because the metadata is at the end of the mp4
Based on this (https://stackoverflow.com/questions/14946421/why-do-webkit-browsers-need-to-download-the-entire-html5-video-mp4-before-play) using the movflags faststart flags for ffmpeg solves the issue
Is there a way, to put the metadata at the beginning of the file?
I'm constructing the file from h264 packets, is there a way to update the metadata, once all the frames are processed?

Take a look at org.jcodec.movtool.WebOptimize. This class will take an existing mp4 and relocate the header to the beginning.

Awesome, sounds like exactly, what I need, thanks :)


bugfix - enable subfolder usage in .htaccess

bugfix - enable subfolder usage in .htaccess

seems like it's now working as expected :(

closed for the moment


Add (dark) themes

It would be nice to have a dark theme to reduce eye strain, especially when using PMS at night.
I've got a basic implementation of a theme switcher feature in my themes branch. At the moment it stores the current theme in local storage (and not in PimpMyStremio-userConfig.json because that would require an additional web request to the server resulting in a slow theme load).
You could add even more themes, or allow the user to customize it completely. I don't know how far you want to go with this, hence why I'm opening an issue first before creating a pull request.

This is really nice, I'm all for themes.
You should also check this line:
https://github.com/sungshon/PimpMyStremio/blob/master/src/web/index.html#L5
More specifically orange-indigo in that line, which indicates the material UI primary and secondary colors. You can see (and play with) the material UI preset colors here:
https://getmdl.io/customize/index.html
We could load this css file dynamically to change the primary and secondary colors of the UI.
My thinking is that themes should obviously have their custom CSS files, for full control over the UI, and also have default values for: background color, text color, primary color and secondary color. Regular users could then also influence the colors to these 4 settings in the settings menu if they wish.

The one thing I'm not entirely sure about is if we should add a button to change light / dark in the header. What I'm worried about here is clogging the header with buttons, as the buttons use icons and are simplistic, the more there are of them, the more confusing it becomes for new users.
We could add a select box in the settings menu though, with options named as: "Light Theme", "Dark Theme", etc. It won't have that flip a switch feeling though..

Btw, also customisation related, due to the very little actual unique text of the project, we could also easily add translation support..

Also another fun idea, not sure how many users would really appreciate it though:
If I make the logo a SVG file, we could even have settings for logo primary / secondary colors :))

@sleeyax Can you please create a PR for what you have now? So we have a starting point for this?

Ah yes, opened PR #56

I've split this into 2 new tickets so it's easier to keep track of:

https://github.com/sungshon/PimpMyStremio/issues/62
https://github.com/sungshon/PimpMyStremio/issues/63


Research e-mail API

Email sent with Amazon link for purchase.
MailChimp?

Look into mailchimp? Can just send basic reminders based on time-interval (can get more specific if time/mailchimp allows)

Yeah, I'm not sure Twilio has a free level, but I'll look into it.

Yeah, SendGrid (Twilio) has a free level for e-mail. https://sendgrid.com/en-us/pricing
Twilio proper has no free SMS level:  https://www.twilio.com/en-us/sms/pricing/us

Signed up with MailJet. Awaiting their decision on whether we can actually send e-mails with their service. I told them we'd be sending to our own e-mail addresses.


Can't add more than two alarm

Hi Sir,
Now it can't add more than two alarm.
with first alarm ETHBTC it's ok,
with second alarm LTCBTC it's not ok, it request upgrade to Premium account to get more alarm.

And this is error !

sounds like maybe you need to update your tradingview account
I just pushed some changes that should help fix the timing of some actions


Update Adventure CF Model to use new Enum data type

/mnt/overlay/dam/cfm/models/editor/content/editor.html/conf/wknd/settings/dam/cfm/models/adventure
the fields for adventureType, adventureActivity, adventureDifficulty were created with the old enum data type (v1). would be great to update the models to use the new V2 enum

Some context, many people also deploy WKND to 6.5 and it currently does not support the new enum data type. We are looking at some solutions for backwards compatibility..


Extra command line options for luarocks make is needed.

#327 we made the defaulut cmake build system use cmake detected generator and release build for rocks.
That if fine for module users.
But as a module developer, after a few days of using the new cmake build system, I found that the follow command line option for luarocks make is required:
Choose Debug build from command line

luarocks make --debug

or

luarocks make --config debug

which is better?
As make command is for developer, should debug be the default for make command
and release default for build command?
Overwrite the default generator for cmake
On Mac, it generate Makefile, but I want Xcode project to debug.

add options like luarocks make --pass-args "-G Xcode" (should be a better option name)
or something in ~/.luarocksrc.lua ?
or maybe I did wrong thing that removed the support of cfg.cmake_generator in #327 ?

I just currently can't find the best answer myself.

If you add a --debug flag for luarocks make, then all build backends should support it.
I've given this some thought and the least intrusive and most effective way would be to add the appropriate debugging CFLAGS (-g on Unix; which one on Windows?) when the flag is enabled.

or maybe I did wrong thing that removed the support of cfg.cmake_generator in #327 ?

Yes, I completely missed the fact that you removed that (sorry about not paying enough attention). It should definitely come back. Then you will have solved your problem for Xcode, since you'll be able to set it in ~/.luarocks/config.lua.
If you want you can leave cfg.cmake_generator unset in the MSVC configuration, so that it takes the default, but the other ones should be back in too (including "Unix Makefiles" by default for OSX — that's better for module users).

@hishamhm Sorry for #327 . Revert back in #340 .
for windows MSVC flags would:
   defaults.variables.CFLAGS = {release="/MD /O2", debug="/MD /Od /Ob0 /Zi /D \"_DEBUG\""}
   defaults.variables.LIBFLAG = {release="/dll", debug="/dll /DEBUG"}

Have you got any ideas command backend?
Let build.build_command and build.install_command to handle the --debug option?


ARROW-2554: [Python] fix timestamp unit detection from python lists

Codecov Report

Merging #2118 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2118      +/-   ##
==========================================
+ Coverage   86.35%   86.36%   +<.01%
==========================================
  Files         230      230
  Lines       40513    40535      +22
==========================================
+ Hits        34987    35008      +21
- Misses       5526     5527       +1

Impacted Files
Coverage Δ

python/pyarrow/tests/test_array.py
100% <100%> (ø)
:arrow_up:

cpp/src/arrow/python/builtin_convert.cc
92.1% <100%> (+0.29%)
:arrow_up:

cpp/src/arrow/util/thread-pool-test.cc
98.91% <0%> (-0.55%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e82a34a...b3ab6e1. Read the comment docs.

@xhochy ready :)


Adding option to use PAT token

Hi,
I really like this app, and I like to use it over email to manage the github notifications, for my personal use case I couldn't use the app due to restrictions, so I tried to add option to use PAT token to get notification, and I run a local version of this.
I thought may be it will be a good use-case in general for other users too.
Please let me know what you think ?

@manosim any changes to get this into to code? I would really love this feature :)

Hi everyone, apologies for the late reply! Gitify went through a major refactor recently (moved from redux to using React context, hooks etc) so unfortunately this PR would need lots of work to get it working after these changes. The good news is that with the major refactor, I was able to implement this feature in a very short amount of time and also made it support GitHub for Enterprise. Planning to release tomorrow so fingers crossed! @abhishektaneja thank you so much for your PR, really appreciate it 🙌

Hi @manosim , thanks a lot for your reply and also implementing the feature in the app itself.


[ 🚧 WIP ] Convert Binary to Octal

Why:

Closes #521
Closes #494
What's being changed:
Created a python program to convert binary into octal

Hey @AyushSrivastava27
Please comment !assign on linked issue #494 (to prevent any conflict)
!assign

On hacktoberfest website From yesterday it is showing waiting and the progress of merge is not showing.
Can u please help me in this


Provisioning profile "match AppStore com.MyCompany.MyApp-test<PHONE_NUMBER>" doesn't include signing certificate "iPhone Developer: Bob Trotter (JM345FJUTSB)"

New Issue Checklist

[✅ ] Updated fastlane to the latest version
[✅ ] I have read the Contribution Guidelines

Issue Description
Hey, I seem to be having issues with fastlane match. I am currently running the command fastlane beta:
desc "Submit a new Beta Build to Apple TestFlight"
  desc "This will also make sure the profile is up to date"
  lane :beta do
    match(type: "appstore")
    gym(scheme: "MyApp UAT") # Build your app - more options available
    pilot

    # sh "your_script.sh"
    # You can also use other beta testing services here (run `fastlane actions`)
  end

My match file contains this:

git_url "https://github.com/MyApp/ios-certificates.git"
type "appstore" # The default type, can be: appstore, adhoc, enterprise or development
username<EMAIL_ADDRESS>app_identifier "com.MyCompany.MyApp-test"

My Appfile contains:
app_identifier "com.MyCompany.MyApp-test" # The bundle identifier of your app
apple_id<EMAIL_ADDRESS># Your Apple email address
team_id "********" # Developer Portal Team ID

I end with the error

Provisioning profile "match AppStore com.MyCompany.MyApp-test<PHONE_NUMBER>" doesn't include signing certificate "iPhone Developer: Bob Trotter (JM345FJUTSB)".

Oddly enough if I run match match(type: "development") there are no code signing issues and it seems to be using the correct certificates, obviously I can't distribute to the App Store for test flight with this tho 😛 . Any ideas what I am doing wrong here?
Complete output when running fastlane, including the stack trace and command used

You can use: --capture_output as the last commandline argument to get that collected for you

[https://kits-crashlytics-com.s3.amazonaws.com/fastlane/standalone/latest.zip
[16:54:44]: -------------------------------------------------
[16:54:44]: --- Step: Verifying required fastlane version ---
[16:54:44]: -------------------------------------------------
[16:54:44]: Your fastlane version 2.28.3 matches the minimum requirement of 2.27.0  ✅
[16:54:44]: ------------------------------
[16:54:44]: --- Step: default_platform ---
[16:54:44]: ------------------------------
[16:54:44]: Driving the lane 'ios beta' 🚀
[16:54:44]: ------------------------------
[16:54:44]: --- Step: register_devices ---
[16:54:44]: ------------------------------
[16:54:48]: Successfully registered new devices.
[16:54:48]: -----------------------
[16:54:48]: --- Step: cocoapods ---
[16:54:48]: -----------------------
[16:54:48]: $ pod install
[16:54:59]: ▸ Analyzing dependencies
[16:54:59]: ▸ Downloading dependencies
[16:54:59]: ▸ Using AMPopTip (1.4.1)
[16:54:59]: ▸ Using Alamofire (4.3.0)
.............................
16:55:23: ▸ Sending stats
16:55:23: ▸ Pod installation complete! There are 36 dependencies from the Podfile and 45 total pods installed.
16:55:23: --- Step: match ---
16:55:23: -------------------
16:55:23: Successfully loaded '/Users/kekearif/Documents/MyApp/ios-app/fastlane/Matchfile' 📄
+----------------------+--------------------------------------+
|         Detected Values from './fastlane/Matchfile'         |
+----------------------+--------------------------------------+
| git_url              | https://github.com/MyApp/i  |
|                      | os-certificates.git                  |
| username             |<EMAIL_ADDRESS>              |
| app_identifier       | com.MyCompany.MyApp-test              |
+----------------------+--------------------------------------+
+-----------------------+--------------------------------------+
|                   Summary for match 2.28.3                   |
+-----------------------+--------------------------------------+
| type                  | appstore                             |
| git_url               | https://github.com/MyApp/i  |
|                       | os-certificates.git                  |
| username              |<EMAIL_ADDRESS>              |
| app_identifier        | com.MyCompany.MyApp-test              |
| git_branch            | master                               |
| keychain_name         | login.keychain                       |
| readonly              | false                                |
| team_id               | 47Y3VGLMTK                           |
| verbose               | false                                |
| force                 | false                                |
| skip_confirmation     | false                                |
| shallow_clone         | false                                |
| force_for_new_devices | false                                |
| skip_docs             | false                                |
| platform              | ios                                  |
+-----------------------+--------------------------------------+
16:55:23: Cloning remote git repo...
[16:55:29]: 🔓  Successfully decrypted certificates repo
[16:55:29]: Verifying that the certificate and profile are still valid on the Dev Portal...
[16:55:32]: Installing certificate...
+-------------------+----------------------------------------------------------+
|                            Installed Certificate                             |
+-------------------+----------------------------------------------------------+
| User ID           | 47Y3VGLMTK                                               |
| Common Name       | iPhone Distribution: MyCompany Holding Limited (34543DWER) |
| Organisation Unit | 34543DWER                                               |
| Organisation      | MyCompany Holding Limited                                   |
| Country           | US                                                       |
| Start Datetime    | Apr 21 08:32:46 2017 GMT                                 |
| End Datetime      | Apr 21 08:32:46 2018 GMT                                 |
+-------------------+----------------------------------------------------------+
[16:55:34]: Installing provisioning profile...
+---------------------+------------------------+------------------------+
|                    Installed Provisioning Profile                     |
+---------------------+------------------------+------------------------+
| Parameter           | Environment Variable   | Value                  |
+---------------------+------------------------+------------------------+
| App Identifier      |                        | com.MyCompany.MyApp-te  |
|                     |                        | st                     |
| Type                |                        | appstore               |
| Platform            |                        | ios                    |
| Profile UUID        | sigh_com.MyCompany.MyApp  | 3f383bb2-b3ff-4813-8d  |
|                     | -test_appstore       | fb-9fb1ec75acb1        |
| Profile Name        | sigh_com.MyCompany.MyApp  | match AppStore         |
|                     | test_appstore_prof  | com.MyCompany.MyApp-te  |
|                     | ile-name               | st<PHONE_NUMBER>          |
| Profile Path        | sigh_com.MyCompany.MyApp  | /Users/kekearif/Libra  |
|                     | test_appstore_prof  | ry/MobileDevice/Provi  |
|                     | ile-path               | sioning                |
|                     |                        | Profiles/3f383bb2-b3f  |
|                     |                        | f-4813-8dfb-9fb1ec75a  |
|                     |                        | cb1.mobileprovision    |
| Development Team ID | sigh_com.MyCompany.MyApp  | 47Y3VGLMTK             |
|                     | test_appstore_team  |                        |
|                     | -id                    |                        |
+---------------------+------------------------+------------------------+
[16:55:35]: All required keys, certificates and provisioning profiles are installed 🙌
[16:55:35]: Setting Provisioning Profile type to 'app-store'
[16:55:35]: -----------------
[16:55:35]: --- Step: gym ---
[16:55:35]: -----------------
[16:55:35]: $ xcodebuild -list -workspace ./MyApp.xcworkspace
[16:55:37]: $ xcodebuild clean -showBuildSettings -workspace ./MyApp.xcworkspace -scheme MyApp\ UAT
+----------------------+--------------------------------------+
|                   Summary for gym 2.28.3                    |
+----------------------+--------------------------------------+
| scheme               | MyApp UAT                          |
| export_method        | app-store                            |
| workspace            | ./MyApp.xcworkspace                |
| destination          | generic/platform=iOS                 |
| output_name          | MyApp                              |
| build_path           | /Users/kekearif/Library/Developer/X  |
|                      | code/Archives/2017-04-23             |
| clean                | false                                |
| output_directory     | .                                    |
| silent               | false                                |
| skip_package_ipa     | false                                |
| use_legacy_build_api | false                                |
| buildlog_path        | ~/Library/Logs/gym                   |
| xcode_path           | /Applications/Xcode.app              |
+----------------------+--------------------------------------+
[16:55:39]: $ set -o pipefail && xcodebuild -workspace ./MyApp.xcworkspace -scheme MyApp\ UAT -destination 'generic/platform=iOS' -archivePath /Users/kekearif/Library/Developer/Xcode/Archives/2017-04-23/MyApp\ 2017-04-23\ 16.55.39.xcarchive archive | tee /Users/kekearif/Library/Logs/gym/MyApp-MyApp\ UAT.log | xcpretty
[16:55:44]: ▸ Building Pods/AMPopTip [Release]
[16:55:44]: ▸ Check Dependencies
[16:55:44]: ▸ Processing Info.plist
[16:56:40]: ▸ Compiling AMPopTip+Animation.m
[16:56:41]: ▸ Compiling AMPopTip+Draw.m
[16:56:41]: ▸ Compiling AMPopTip+Entrance.m
[16:56:41]: ▸ Compiling AMPopTip+Exit.m
[16:56:41]: ▸ Compiling AMPopTip-dummy.m
[16:56:41]: ▸ Compiling AMPopTip.m
[16:56:42]: ▸ Compiling AMPopTip_vers.c
[16:56:42]: ▸ Compiling AMPopTip+Animation.m
[16:56:42]: ▸ Compiling AMPopTip+Draw.m
[16:56:42]: ▸ Compiling AMPopTip+Entrance.m
[16:56:42]: ▸ Compiling AMPopTip+Exit.m
[16:56:43]: ▸ Compiling AMPopTip-dummy.m
[16:56:43]: ▸ Compiling AMPopTip.m
..................................................
▸ Building MyApp/Myapp UAT [Release]
▸ Check Dependencies
❌  Provisioning profile "match AppStore com.MyCompany.MyApp-test<PHONE_NUMBER>" doesn't include signing certificate "iPhone Developer: Bob Trotter (JM345FJUTSB)".
❌  Code signing is required for product type 'Application' in SDK 'iOS 10.2']
Environment
Please run fastlane env and copy the output below. This will help us help you :+1:
If you used --capture_output option please remove this block - as it is already included there.
[🚫 fastlane environment 🚫
Stack

Key
Value

OS
10.12.1

Ruby
2.2.4

Bundler?
false

Git
git version 2.10.1 (Apple Git-78)

Installation Source
~/.fastlane/bin/bundle/bin/fastlane

Host
Mac OS X 10.12.1 (16B2657)

Ruby Lib Dir
~/.fastlane/bin/bundle/lib

OpenSSL Version
OpenSSL 1.0.2g  1 Mar 2016

Is contained
true

Is homebrew
false

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
8.2.1

System Locale

Variable
Value

LANG
en_US.UTF-8
✅

LC_ALL
en_US.UTF-8
✅

LANGUAGE
en_US.UTF-8
✅

fastlane files:
`./fastlane/Fastfile`
# Customise this file, documentation can be found here:
# https://github.com/fastlane/fastlane/tree/master/fastlane/docs
# All available actions: https://docs.fastlane.tools/actions
# can also be listed using the `fastlane actions` command

# Change the syntax highlighting to Ruby
# All lines starting with a # are ignored when running `fastlane`

# If you want to automatically update fastlane if a new version is available:
# update_fastlane

# This is the minimum version number required.
# Update this, if you use features of a newer version
fastlane_version "2.27.0"

default_platform :ios

platform :ios do
  before_all do
    register_devices(devices: {
      "Keke's iPhone" => "6e5cf429c3d7e150f64ef273aac2b17ee5c7c891"
    })
    # ENV["SLACK_URL"] = "https://hooks.slack.com/services/..."
    cocoapods

  end

  desc "Runs all the tests"
  lane :test do
    scan
  end

  desc "Submit a new Beta Build to Apple TestFlight"
  desc "This will also make sure the profile is up to date"
  lane :beta do
    match(type: "appstore")
    gym(scheme: "Snapask UAT") # Build your app - more options available
    pilot

    # sh "your_script.sh"
    # You can also use other beta testing services here (run `fastlane actions`)
  end

  desc "Deploy a new version to the App Store"
  lane :release do
    # match(type: "appstore")
    # snapshot
    gym(scheme: "Snapask UAT") # Build your app - more options available
    deliver(force: true)
    # frameit
  end

  # You can define as many lanes as you want

  after_all do |lane|
    # This block is called, only if the executed lane was successful

    # slack(
    #   message: "Successfully deployed new App Update."
    # )
  end

  error do |lane, exception|
    # slack(
    #   message: exception.message,
    #   success: false
    # )
  end
end

# More information about multiple platforms in fastlane: https://github.com/fastlane/fastlane/blob/master/fastlane/docs/Platforms.md
# All available actions: https://docs.fastlane.tools/actions

# fastlane reports which actions are used
# No personal data is recorded. Learn more at https://github.com/fastlane/enhancer

`./fastlane/Appfile`
# This is configured for appstore and devlopment on test bundle now (UAT)
app_identifier "com.appedu.snapask-test" # The bundle identifier of your app
apple_id<EMAIL_ADDRESS># Your Apple email address
team_id "47Y3VGLMTK" # Developer Portal Team ID

# you can even provide different app identifiers, Apple IDs and team names per lane:
# More information: https://github.com/fastlane/fastlane/blob/master/fastlane/docs/Appfile.md

fastlane gems

Gem
Version
Update-Status

cert
2.0.0
✅ Up-To-Date

credentials_manager
1.0.0
✅ Up-To-Date

deliver
2.0.1
✅ Up-To-Date

fastlane
2.28.3
✅ Up-To-Date

fastlane_core
1.0.0
✅ Up-To-Date

frameit
4.0.0
✅ Up-To-Date

gym
2.0.0
✅ Up-To-Date

match
1.0.0
✅ Up-To-Date

pem
2.0.0
✅ Up-To-Date

pilot
2.0.0
✅ Up-To-Date

produce
2.0.0
✅ Up-To-Date

scan
1.0.0
✅ Up-To-Date

screengrab
1.0.0
✅ Up-To-Date

sigh
2.0.1
✅ Up-To-Date

snapshot
2.0.0
✅ Up-To-Date

spaceship
1.0.0
✅ Up-To-Date

spaceship
0.38.4
🚫 Update available

supply
1.0.0
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems

Gem
Version

CFPropertyList
2.3.4

activesupport
<IP_ADDRESS>

addressable
2.5.0

babosa
1.0.2

bigdecimal
1.2.6

bundler
1.13.6

claide
1.0.1

cocoapods
1.1.1

cocoapods-core
1.1.1

cocoapods-deintegrate
1.0.1

cocoapods-downloader
1.1.2

cocoapods-plugins
1.0.0

cocoapods-search
1.0.0

cocoapods-stats
1.0.0

cocoapods-trunk
1.1.1

cocoapods-try
1.1.0

colored
1.2

colored2
3.1.2

commander
4.4.0

commander-fastlane
4.4.4

concurrent-ruby
1.0.2

credentials_manager
1.0.0

domain_name
0.5.20161129

dotenv
2.1.1

escape
0.0.4

excon
0.54.0

faraday
0.10.0

faraday-cookie_jar
0.0.6

faraday_middleware
0.10.1

fastimage
1.6.8

fastlane_core
1.0.0

fourflusher
2.0.1

fuzzy_match
2.0.4

gh_inspector
1.0.2

google-api-client
0.9.20

googleauth
0.5.1

highline
1.7.8

http-cookie
1.0.3

httpclient
<IP_ADDRESS>

hurley
0.2

i18n
0.7.0

io-console
0.4.3

json
1.8.1

jwt
1.5.6

krausefx-shenzhen
0.14.11

libxml-ruby
2.9.0

little-plugger
1.1.4

logging
2.1.0

memoist
0.15.0

mime-types
3.1

mime-types-data
3.2016.0521

mini_magick
4.5.1

minitest
5.4.3

molinillo
0.5.4

multi_json
1.12.1

multi_xml
0.5.5

multipart-post
2.0.0

nanaimo
0.2.3

nap
1.1.0

net-sftp
2.1.2

net-ssh
3.2.0

netrc
0.7.8

nokogiri
1.5.6

os
0.9.6

plist
3.2.0

power_assert
0.2.2

psych
2.0.8

public_suffix
2.0.4

rake
10.4.2

rdoc
4.2.0

representable
2.3.0

retriable
2.1.0

rouge
1.11.1

rubygems-update
2.5.2

rubyzip
1.1.7

security
0.1.3

signet
0.7.3

slack-notifier
1.5.1

sqlite3
1.3.12

terminal-notifier
1.7.1

terminal-table
1.4.5

test-unit
3.0.8

thread_safe
0.3.5

tty-screen
0.5.0

tzinfo
1.2.2

uber
0.0.15

unf
0.1.4

unf_ext
<IP_ADDRESS>

unicode-display_width
1.1.1

word_wrap
1.0.0

xcode-install
2.0.9

xcodeproj
1.4.4

xcpretty
0.2.4

xcpretty-travis-formatter
0.0.4

generated on: 2017-04-23
]

This is a code signing issue.  Your developer certificate is not included in the provisioning profile.
If you're trying to create an ipa for the appstore, then you need the distribution certificate in your keychain.

I have the same problem, with the development certificate though. Should match add the certificate to the keychain?


Fix GetUserName() and its test

Signed-off-by: David Gageot<EMAIL_ADDRESS>

@nathanleclaire wdyt?

It might work, but I'm still highly skeptical due to the cgo issues mentioned.  https://groups.google.com/forum/#!msg/Golang-nuts/LB71rodPxP0/xoAlpgOsPoQJ seems to indicate there won't be a problem until runtime.

@dgageot I can confirm these x-compiling darwin from linux generates a binary that returns  from user.Current()

So, I think we are unable to merge this.  Sorry @dgageot -- I would love to be able to use native Go stuff instead of the hacky way.

@dgageot alternatively we could consider cross-building with CGO.
That's more involved, but we might consider it.
Also, look at what libcontainer does:
https://github.com/docker/libcontainer/blob/83a102cc68a09d890cce3b6c2e5c14c49e6373a0/user/user.go
or dbus:
https://github.com/docker/libcontainer/tree/83a102cc68a09d890cce3b6c2e5c14c49e6373a0/vendor/src/github.com/godbus/dbus
I'm pretty there are some tricks with build flags / direct sys calls.

@dmp42 @nathanleclaire Don't you think that a pretty huge problem we are facing? Code that compiles and passes the tests can fail at runtime because of cross-compilation issue and we don't freak out?

Reopening the PR since I'd like to discuss about solutions and maybe change the code.

The code in this PR is not the real problem. There are ways to make it work:

We could release on each of our target platforms instead of relying on basic cross-compilation
We could cross-compile with CGO enabled. There's a docker image that does that and it seems to work for user.Current() https://github.com/karalabe/xgo
If we decide to not fix the release process, we should at least have tests that protect us against this dangerous standard libraries. Can we detect those calls? We could cross-compile on osx and test on linux.

In the mean time, I've pushed an implementation that relies on whoami to fix the issue. @nathanleclaire Can you take a look at it?

For starters, what problem with the current code are we trying to solve?  This isn't clear to me from the discussion.  If it's just that tests fail when run in a container, adding ENV USER in the Dockerfile (which we had before) will solve that problem easily without needing to change our build toolchain.
@dmp42 I don't see how any of the linked code will help with the problem?  The libcontainer one seems pretty Linux-specific and I'm not sure which part of the dbus package you're referencing.

Don't you think that a pretty huge problem we are facing? Code that compiles and passes the tests can fail at runtime because of cross-compilation issue and we don't freak out?

The issues with the standard library package that require cgo are well-known and the reason why libraries like https://github.com/mitchellh/homedir exist.  As long as we're using Go native build, there's nothing to be done about it except avoid the problematic packages.

We could release on each of our target platforms instead of relying on basic cross-compilation

I'm not sure what this means.  Build with cgo for each platform?

We could cross-compile with CGO enabled. There's a docker image that does that and it seems to work for user.Current() https://github.com/karalabe/xgo

It clocks in at about 2.3GB in image size (vs. ~500MB in golang:1.5) and is an additional upstream dependency to integrate into our build tooling, debug, and to maintain if the maintainer disappears.  Also, I'm not sure how it would integrate with our reliance on build tags, etc.

If we decide to not fix the release process, we should at least have tests that protect us against this dangerous standard libraries. Can we detect those calls? We could cross-compile on osx and test on linux.

I'm in favor of static checking for these problematic packages where available, but I don't think it's super necessary.  The maintainers are generally pretty aware of these issues.
I'm really skeptical about cgo in general, the current cross-compilation method is trivial (especially with Go 1.5) and I think modifying our build toolchain heavily at this point just to get proper username lookups will not deliver value for us.  Granted, not having native DNS lookups and access to the system certificate store is annoying, but doesn't seem to be causing us a dramatic amount of pain so far.
As for this PR, this code has been humming along working fine for several releases now, so I'm inclined towards not changing it.

@nathanleclaire Thank you for your feedback. You are right that we have to focus on the root problem.
You say that GetUsername() is fine in the real-world, so let's not change it. Do you mind if I add a user in the Dockerfile to fix the in-container build?
Are you ok if I investigate the cross-compilation subject? We can either:

Don't change anything
Compile our binaries on target platforms instead of relying on cross-compilation
Cross-compile with CGO enabled. For the record, xgo was just something I found, not the ideal solution.
I'd like to really understand what each solution has to bring and also would like to take a look at how the other projects solve this problem.

You say that GetUsername() is fine in the real-world, so let's not change it. Do you mind if I add a user in the Dockerfile to fix the in-container build?

Not at all - go for it.
As for investigating using cgo, go ahead and do some research, but my tentative forays have always seemed to indicate that it may be more hassle than its worth.  The utility of being able to generate binaries for each target platform and architecture with one command is really hard to beat.


Scrollable log view

Dear Odd-box team,
I hope this message finds you well. I have been using Odd-box and have found it to be a valuable tool in my daily tasks. I would like to express my appreciation for the effort you put into creating such a user-friendly interface.
While navigating the log view, I've encountered a small usability concern. Currently, scrolling up with the mouse in the log view seems to be unavailable. I believe that incorporating this feature would enhance the overall user experience, making it even more efficient and intuitive.
I understand that your team is continually working to improve the product, and I appreciate the dedication you invest in addressing user feedback. If possible, I kindly request the consideration of implementing mouse scroll functionality for upward navigation in the log view.
Thank you for your time and attention to this matter. I look forward to the possibility of experiencing this enhancement in future updates.
Best regards,
Jesper Kinder
You know where to find me.

https://github.com/OlofBlomqvist/odd-box/releases/tag/v0.0.4


[BACKLOG-34405] Moved password restrictions to security.properties (9.1)

:white_check_mark: Build finished in 36m 47s
Build command:
mvn clean verify -B -e -Daudit -amd -pl core,engine

:ok_hand: All tests passed!
Tests run: 4878, Failures: 0, Skipped: 7    Test Results

:information_source:  This is an automatic message


Sign [magic, hash] instead of [magic, data]

See neo-project/neo#2314. This is quite radical, though it should simplify things for us.

We should remove Network field from our structures here, because the hash is gonna be the same for different networks, but signed hash will be different and this difference is quite easy to account for when signing/verifying, that context usually has the network already.


Setting defaultView/view to "week" sets day view with an empty heading

Hi, not sure whether it's for me, but v0.12.1-v0.12.3 have this bug. I've seen that you have no issues with the demo, but for me i have to force a setTimeout(()=> this.setState({view:'week'})) in order to change view at init.
My code looks like:
import React, {Component} from 'react';
import 'react-big-calendar/lib/css/react-big-calendar.css';
import BigCalendar from 'react-big-calendar';
import moment from 'moment';
import './MyCalendar.scss';

BigCalendar.setLocalizer(
    BigCalendar.momentLocalizer(moment)
);

class MyCalendar extends Component {
    state = {view: 'week'}

   // componentDidMount(){
   //     setTimeout(()=> this.setState({view:'week'}))
   // }

    render(){
        let today = moment();
        let am8 = today.set('hour', 8).set('minutes', 0).toDate();
        let pm8 = today.set('hour', 21).set('minutes', 0).toDate();

        return (
            <div>
                <BigCalendar
                    events={[]}
                    min={am8}
                    max={pm8}
                    views={['month', 'week', 'day']}
                    view={this.state.view}
                    formats={{timeGutterFormat: 'h A', dayFormat:'ddd D'}}
                    step={30}
                    onView={(view)=>{
                        this.setState({view})
                    }}
                />
            </div>
        );
    }
}

export default MyCalendar

Hi! From the docs on the view prop:

controlled by: onView, initialized with: defaultView

Try adding defaultView='week' as a prop to the calendar.

Same result, as mentioned in issue's heading setting neither "defaultView={"week"}" nor "view={'this.state.view'} onView={(view)=>this.setState({view})}" is not helping, they both result in a broken "day" view. I've even tried "defaultView={'week'} view={'this.state.view'} onView={(view)=>this.setState({view})}".
Is there anything else i could try ?

Sorry, I must have missed reading the title. If that doesn't work I don't know what the problem is. I think both should work. @jquense How do you handle the defaultView prop? I can't seem to find it in the source.
@555ea I'm unable to reproduce this, can you point to a repo showing it?

@tobiasandersen here you are, the bug is reproduced here
https://github.com/555ea/react-big-calendar-view-week-bug

Oh I see, thanks for the link. I actually think this is a duplicate of https://github.com/intljusticemission/react-big-calendar/issues/128.

Is there any solution other than setTimeout ? It's pretty critical

i'll take a look at your repo. up until this point we haven't had anything reproducing the bug so no workarounds.

too a quick look. It's clear that the component is getting rendered before the css for the component has loaded which is messing up the gutter width calculation (its measuring the unstyled content). This is more an issue with how webpack imports css without extract css.
The immediate workaround is to load the css in a <link> tag in the head instead of importing it with style-loader

I also encountered this (with other libraries as well) when trying to render before my data pull from a db is completed. Waiting until the data is actually pulled to render fixes this for react-big-calendar as well as other libraries.


Replace knox with aws-sdk

Replace the no longer maintained knox library with aws-sdk. Actively maintained by AWS over at https://github.com/aws/aws-sdk-js

CC :  opencollective/opencollective#1880

Seems to be working fine against some manual local tests & the repo's unit tests I ran against a personal AWS bucket

Looks good to me. Just have small feedback. We should be able to merge tomorrow.

Hi @znarf , made the small changes. Should be good now.

Hi again, fixed the naming mistakes. More than happy to squash these commits if that's alright with you?

Hi @znarf, submitted an expense for this. https://opencollective.com/engineering/expenses/8176


Test Elasticsearch related tests

This PR should fix Elasticsearch related tests

test for :trino-elasticsearch is green, test for :trino-phoenix is red, as expected.


port from Python/py-school-match to Rust/matchmaker

https://github.com/cfm/proxy-solver-api/blob/3fe7b27c47830d3cccb1a2c59c9b0e1cf10a0442/README.md?plain=1#L5-L21

Thank you, @legoktm!  All very useful feedback, especially to make my Pythonisms more Rustlike, that I'll implement soon.


Update profig to 3.4.17

About this PR
📦 Updates com.outr:profig from 3.4.14 to 3.4.17
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.outr", artifactId = "profig" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.outr", artifactId = "profig" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #48.


chore(package.json): update packge scripts

exclude newly added helper from code coverage
bump up closuure, commitizen dependency version
update wallaby configuration

set of minor, minor changes to enhance ergonomics slightly.

I can check in this myself, but will do after got agreement on build_test (and some other) behavior changes to skip es6 build.

I can check in this myself, but will do after got agreement on build_test (and some other) behavior changes to skip es6 build.

That's fine. I agree, there's no reason to do the es6 build first.

Merged with 92a247d .


Implement enrollments converters

Purpose
LMS xAPI profile supports statements templates for course registration activities.
Enrollment events from Edx can be converted in xAPI
Proposal

[x] Converter models for edx.course.enrollment.activated and edx.course.enrollment.deactivated
[x] Tests for converter models

@Leobouloc Oh it can be quite confusing, but only the last commit concerns the enrollment converter. Sorry for the misunderstanding, the previous commits come from the PR about LMS profile

@Leobouloc Oh it can be quite confusing, but only the last commit concerns the enrollment converter. Sorry for the misunderstanding, the previous commits come from the PR about LMS profile

Ah ok ! Then I (mentally) transfer my comments to the LMS profile PR.
Also, perhaps we can have this point to the LMS profile branch then, to only have the diff linked to this PR ? (I let you do it in case I misunderstood your comment)

@SergioSim yes, it is removed in PR #431

Looks Good) 👍 Apropos, do we keep or remove the CONTEXT_EXTENSION_SCHOOL_ID, CONTEXT_EXTENSION_COURSE_ID and CONTEXT_EXTENSION_MODULE_ID from the BaseXapiConverter?


Running error

ASSERT: "false" in file qasciikey.cpp, line 501
Aborted (core dumped)

I have the same problem. Have you solved it?

ASSERT: "false" in file qasciikey.cpp, line 501
Aborted (core dumped)

I have the same problem. Have you solved it?

ASSERT: "false" in file qasciikey.cpp, line 501
Aborted (core dumped)

I have the same problem. Have you solved it?

A workaround in MobaXterm is to uncheck "Unix-compatible keyboard" in X11 settings.