Can't reset date value after form submit

I have an autoform with a date field that defaults to today, and is editable by a user. After submitting the form I want to reset the date field to today. When I try to do this though, the date is just always left empty after submitting the form.
I'm trying this:
 Template.tasks.events({
   'submit form': function(event, template) {
     event.target.due.value = moment().format("YYYY-MM-DD");
   }
 });

I also tried this:
 AutoForm.addHooks('newTaskForm', {
   onSuccess: function(operation, result, template) {
     template.$('[due]').first().val(moment().format("YYYY-MM-DD"));
     // Incidentally, this focus doesn't work either.
     // Trying to reset focus to the first input field after submit.
     // template.$('[summary]').first().focus();
   }
 });

I also have the field defined with the value set from a helper:
{{> afQuickField name="due" value=today}}
... where today looks like this:
  Template.tasks.helpers({
    today: function() {
      return moment().format("YYYY-MM-DD");
    });

Nothing has worked so far. Am I doing this wrong? Or is this not supported?

Try wrapping with setTimeout at 0ms:
AutoForm.addHooks('newTaskForm', {
   onSuccess: function(operation, result, template) {
     setTimeout(function () {
       template.$('[due]').first().val(moment().format("YYYY-MM-DD"));
       // Incidentally, this focus doesn't work either.
       // Trying to reset focus to the first input field after submit.
       // template.$('[summary]').first().focus();
     }, 0);
   }
 });

Nope. Didn't work. Any suggestions of insight or context that you think would be helpful in understanding what/why this isn't working?

Please provide a full reproduction in the form of a cloneable repo or MeteorPad so we can figure out a solution.

I got this to work by setting the timeout to 100.
onSuccess: function (formType, result) {      setTimeout(function () {           $("input[data-schema-key='keyName']").first().focus();       }, 100); }


Sometimes the code dont send a comment on post

Describe the bug
Some post of my bot have comment and others dont have. i have 100% i send the message
To Reproduce
Please indicate all steps that lead to this bug:

Make Login with username and password
Send a photo with caption (comment)

const postToInsta = async (texto, id) => {

    const imageBuffers = fs.readFileSync(`./new_image${id}.jpg`);
    console.log(`./new_image${id}.jpg || ${texto}`); // check if function receive all values

    await ig.publish.photo({
        file: imageBuffers,
        caption: texto, // text
    });
    await new Promise(resolve => setTimeout(resolve, 15000)); //make a setimeout to conclude all other posts.
}

Version

Node.js version 20.11.0
Lib version 1.45.3
OS (especially if you use Windows) Windows

Additional context
With comment: https://www.instagram.com/p/C2LRoItrrsL/
With out comments: https://www.instagram.com/p/C2LRoVCrCqA/

It is still works. Maybe spam words in caption


Potential Versioning Issue

Hi,
When installing using composer require spatie/pdf-to-image, it appears to be defaulting to version v2.x-dev. This version appears to rank higher than all other versions and falls within the constraint ^2.0. See example:

I may be talking nonsense, but can someone please confirm?
A side effect of this can be seen here: https://github.com/spatie/pdf-to-image/issues/145#issuecomment-632368119

The rank has no effect to which version composer selects for installing.
Try adding prefer-stable to your composer.json.
Example: https://github.com/spatie/freek.dev/blob/master/composer.json#L128

Ah, that makes sense. Thanks Freek!

Just a quick one @freekmurze, I checked and prefer-stable was set to true. I am sure I'm not the only one and why this issue exists: https://github.com/spatie/pdf-to-image/issues/145


Provide command to export downloaded models

Is there any way to import and export downloaded models? In this way, there is no need to use ollama pull to download again on another local machine.
Thanks

Hi @biandayu, I used it on Ubuntu.
Important files are saved in the .ollama folder, so you can simply copy it to your new device.
The full path is:
/home/UserName/.ollama/models/
There are two folders:
manifests and blob.
The manifests folder contains metadata for the models, and the blob folder contains the models themselves.

BTW, maybe using a custom PATH or import/export models command would be helpful for users? If the maintainer agrees, I can try to implement it.

Thanks @horw, I use it on WSL(ubuntu).
The model files are in /usr/share/ollama/.ollama. I've tried copy them to a new PC. The ollama list command does display the newly copied models, but when using the ollama run command to run the model, ollama starts to download again.

What about this directory, /home/UserName/.ollama/models/? Do you have any files here?

There is no such files & dir under HOME.

I just checked the code, and Ollama actually has an option to set up a custom path for the models directory using the OLLAMA_MODELS environment variable. On the other hand, if you don't set it up, it will look to the HOME environment variable.
// modelsDir returns the value of the OLLAMA_MODELS environment variable or the user's home directory if OLLAMA_MODELS is not set.
// The models directory is where Ollama stores its model files and manifests.
func modelsDir() (string, error) {
	if models, exists := os.LookupEnv("OLLAMA_MODELS"); exists {
		return models, nil
	}
	home, err := os.UserHomeDir()
	if err != nil {
		return "", err
	}
	return filepath.Join(home, ".ollama", "models"), nil
}

You can check this one: https://github.com/jmorganca/ollama/blob/41434a7cdcf33918ae2d37eb23d819ef7361e843/docs/faq.md?plain=1#L94

@conradax 我在使用pycharm远程主机上传时遇到了同样的问题，然后我以命令行使用sftp上传就解决了

Merging this with https://github.com/ollama/ollama/issues/335


Fixes for version 3.7.0

Fixed tables
Added markdown import & export notifications

The following content will cause parsing errors:
---
kanban-plugin: board
---

It's trying to parse an Obsidian plugin, which we don't currently support. We could consider adding a way to handle or ignore Obsidian plugins. I'll add the Kanban board as an idea to the roadmap since it might be worth implementing in the future.

It's trying to parse an Obsidian plugin, which we don't currently support. We could consider adding a way to handle or ignore Obsidian plugins. I'll add the Kanban board as an idea to the roadmap since it might be worth implementing in the future.

The following content will cause parsing errors too:
---
---

This is unrelated to whether it is an Obsidian plugin.

In this case, I'll modify the code to parse --- as horizontal rules, as that's how it's parsed in Markdown.

I've added support for --- and other methods to insert horizontal rules in the markdown parser with commit 7f1f0ec.

I think we might be ready for a release after all.


active_low: support added

added support for setting gpio to active_low.
replaced rustc serializer with serde.
updated cargo deps.

hey @posborne @nastevens finished the active low additions to gpio-uils. Also moved over to using serde for the config parsing

Any chance the package version updates could be split from the serde changes and updates? Or did you basically have to update dependencies just to get serde to build?

@nastevens I'll try to minimize the cargo updates. I may be able to get away with removing rustc_serializer and adding the serde stuff.

Anything holding this merge up @posborne?


Cannot shim constructor for value type

This is evident if attempting the following:
Shim.Replace(() => new DateTime()).With(() => new DateTime(2004, 1, 1));

The above is simply the default constructor. However, GetMethodFromExpression cannot find the constructor for said constructor. It fails in the validation phase because the original method to shim (the constructor) is null. I suspect this is due to it being the default constructor because the following works--insofar as it passes the validation phase.
Shim
    .Replace(() => new DateTime(Is.A<int>(), Is.A<int>(), Is.A<int>()))
    .With((int y, int m, int d) => new DateTime(2004, 1, 1));

The above is no longer the default constructor, and GetMethodFromExpression successfully finds the intended constructor. During the isolation, I can also see that the breakpoint in the replacement is called as expected.
However, the replacement value is never actually present in the resulting code. See the following example.
var s = Shim
    .Replace(() => new DateTime(Is.A<int>(), Is.A<int>(), Is.A<int>()))
    .With((int y, int m, int d) => new DateTime(2004, 1, 1));

    var dateTimeShim = Shim.Replace(() => DateTime.Now).With(() => new DateTime(2004, 1, 1));

    PoseContext.Isolate(()=>
    {
        var dt = new DateTime(2023, 1, 1);
        Console.WriteLine(dt); // <-- This prints '01-01-0001 00:00:00'
    }, s);

I've explicitly not labelled this as a bug since I don't know whether this is due to a limitation in the CLR.


JWT token acceptance check if expires

Sometimes we get duplicated entry in repo-list which generally means, if timestamp is different, that user clicked more then once on confirmation link sent by pec. We should check if that token expires once it gets used.

This still holds, we need to have a stronger check @sebbalex


Adjust codebase for Java 21 warnings

This PR concerns a warning (possible 'this' escape before subclass is fully initialized) which appears when using OpenJDK 21. This PR will future-proof the project for Java 21 by addressing it on the necessary files (please view changes).
However, there is one file:

state-machine-bug-finder/target/generated-sources/javacc/se/uu/it/smbugfinder/encoding/javacc/LabelParserTokenManager.java

that I have not been able to fix. It is created from javacc.
@pfg666 please suggest what can be done because I am not familiar with the specifics of javacc.
This means that there is still one warning left and thus I have silenced all warnings of this kind in pom.xml

Just saw that a test fails. This is because it is trying to compile on Java-17 which didn't support this warning (which in turn means that the Xlint flag for it is not supported in the pom.xml).
I suggest we wait for Paul if he has anything in mind regarding the warning on LabelParserTokenManager.java and if he can fix it we can get rid of the suppression altogether.

Unfortunately, JavaCC is working against us here. There is not a lot you can do to configure the automatically generated classes other than saving them (with edits) in the repo, and preventing javacc from generating them. Hence, I added the LabelParserTokenManager class, with tweaks to address the Java 21 warning. This does mean that we might have to re-generate this class going forward as JavaCC progresses. But that's the best we can do.
I think it is nice to be Java 21 compatible, though I would hesitate to require Java 21 compatibility, which is what adding '-this-escape' does. Plus, we may want to perform that check anyway.
With the LabelParserTokenManager added, building works both on JDK 17 and on JDK 21.

@kritonios01 Please confirm that it works on your end. Once you do, Squash and Merge to main. Note that I 'squashed' two of your commits into one. That was in order to make rebasing easier. :))


Add description and tags to public key

LGTM.
However, it seems to me that so far, our KMS ideas conceive of keys mainly as asymmetric and as signing/verification mechanisms. Do we need encryption keys (symmetric, asymmetric) as a distinct concept?


Hide children you don't have access to.

With this, IIIF collections won't show manifests or collections you
don't have access to.

Coverage remained the same at 100.0% when pulling db0386e8f2d4ccd6178d59cc1079064c58b21f1b on manifest_permissions into 54942b0c92e231a59f10af79301bac727d9a97f5 on master.


Adds Object based resolver

A slightly different style of name resolution. Makes the logistics a bit easier with multiple base endpoints meeting the same API spec.

Could you explain the purpose/use case and add tests?

I'd love to use it as soon as it gets merged. Any news when this will become available?

@dannypurcell are you still interested in merging this PR? If so please provide tests and documentation, including what use cases this solve and how this works.

I'm closing this PR for now (as it's pretty old and there are no recent updates).


Update UG

Change exisiting prefix table to point form

Codecov Report
Base: 65.44% // Head: 65.44% // No change to project coverage :thumbsup:

Coverage data is based on head (7fcdd7b) compared to base (1354293).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #187   +/-   ##
=========================================
  Coverage     65.44%   65.44%
  Complexity      640      640
=========================================
  Files           101      101
  Lines          2402     2402
  Branches        291      291
=========================================
  Hits           1572     1572
  Misses          719      719
  Partials        111      111

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[LevelDB 1.22] ERROR_UNABLE_TO_REMOVE_REPLACED 1175

levelDB 1.22
windows 10 x64
levelDB is throwing above mentioned error.
We use a C# wrapper for a unity project, where this is the case nearly 100% of the time, but it can be reproduced by this code:
#include <iostream>

#include <cassert>
#include "leveldb/db.h"
#include "leveldb/env.h"

int main()
{
  std::cout << "Hello World!\n";

  for (int i = 0; i < 50; ++i) {
	  leveldb::DB* db;
	  leveldb::Options options;
	  options.create_if_missing = true;
	  leveldb::Status status = leveldb::DB::Open(options, "...somepath....\\TESTDIR", &db);

	  assert(status.ok());

	  std::string value;
	  status = db->Put(leveldb::WriteOptions(), "key123", "5");
	  assert(status.ok());

	  status = db->Get(leveldb::ReadOptions(), "key123", &value);
	  assert(status.ok());
	  assert(value.compare("5") == 0);
	  std::cout << value;

	  status = db->Delete(leveldb::WriteOptions(), "key123");
	  assert(status.ok());

	  delete db;
  }
}

the error happens on leveldb::DB::Open
and a stacktrace would be:
leveldb::DB::Open > VersionSet::LogAndApply  > SetCurrentFile > env_windows.cc RenameFile
line 542 return WindowsError(src, replace_error);
where the replace error with code 1175 is returned
src = TESTDIR/LOG
target = TESTDIR/LOG.old

this is also the case for alternating folder names:
    std::stringstream ss;
    ss << "C:\\Users\\boliver\\Documents\\leveldb\\MyOwnTest\\TESTDIR";
    ss << i;

    leveldb::Status status = leveldb::DB::Open(options, ss.str(), &db);

the error also appears when running the benchmarks

Hello!
This bug is also reproduced by creating some LevelDB's bases in a loop like this:
#include <iostream>
#include "leveldb/db.h"
#include "leveldb/options.h"

int main()
{
    leveldb::DB* ptr_db = nullptr;
    leveldb::Options options;
    options.create_if_missing = true;

    for (int i = 0; i < 1000;i++)
    {
        leveldb::Status status = leveldb::DB::Open(options, "c:\\temp\\db" + std::to_string(i), &ptr_db);
        if (!status.ok())
        {
            std::cout << "error" << std::endl;
            continue;
        }
        delete ptr_db;
    }
    return 0;
}

This is because the RenameFile method (in env_windows.cc) uses a call sequence that does not always work.
It's easily reproduced by the following example:
#include <windows.h>

int main()
{
    for( int i = 0;i < 100;i++ )
    {
        // creating two files
        std::string from = "c:\\1.txt";
        std::string to = "c:\\2.txt";
        auto handle = CreateFileA( from.c_str(), GENERIC_ALL, 0, nullptr, CREATE_ALWAYS, 0, nullptr );
        CloseHandle( handle );
        handle = CreateFileA( to.c_str(), GENERIC_ALL, 0, nullptr, CREATE_ALWAYS, 0, nullptr );
        CloseHandle( handle );

        // trying to replace file
        auto rez = ReplaceFileA( to.c_str(), from.c_str(), nullptr, REPLACEFILE_IGNORE_MERGE_ERRORS, nullptr, nullptr );
        if( !rez )
            std::cout << i << ": " << GetLastError() << std::endl;
    }
    return 0;
}

Thus, it seems to me that WinApi RenameFile method is the reason for this behavior.

Windows 10, x64


Jekyll frontmatter

I have a markdown file:
---
title: "SpaceVim lang#java layer"
---

# [SpaceVim Layers:](https://spacevim.org/layers) lang#java

which I hope the title only shown in the top of the browser, but remark will change it to:
* * *

## title: "SpaceVim lang#java layer"

# [SpaceVim Layers:](https://spacevim.org/layers) lang#java

Use a plugin: remark-frontmatter.

@wooorm sorry, I can not understand how to use the frontmatter in cli. I use neoformat in vim. and the default command is
function! neoformat#formatters#markdown#remark() abort
    return {
            \ 'exe': 'remark',
            \ 'args': ['--no-color', '--silent'],
            \ 'stdin': 1,
            \ }
endfunction

I think I should change it to
function! neoformat#formatters#markdown#remark() abort
    return {
            \ 'exe': 'remark',
            \ 'args': ['--no-color', '--silent', '--use', 'remark-frontmatter
'],
            \ 'stdin': 1,
            \ }
endfunction

Correct, but you have to install the plugin with npm.
Also, the getting started guide comes with some examples on how to use the CLI.
Note that this issue tracker is for questions and issues with remark, not for projects like neoformat and how to use remark in it. neoformat has its own issue tracker!


Add third-party Licenses

[ ] Check for any conflicts in the license for Care and its dependent packages.

Some tools -

[ ] https://github.com/wrapp/licensecrawler
[ ] https://github.com/mwittig/npm-license-crawler

@tellmeY18 You'll be taking this up right?

Yea I'll ✅

@tellmeY18 can you link your PR here?


Show the language on a repository page, too

Dear Linguist contributor,
This is not a request for Linguist, but for GitHub. However, this is related to showing a repository's language - the Linguist's mission.
Currently, only https://github.com/userName or https://github.com/organizationName show the repo languages. The actual repository page doesn't. For example, https://github.com/github shows 'Ruby' for Linguist. But https://github.com/github/linguist doesn't, unfortunately.
Why show the language on a repository page, too? Could you see that it would help users to realise whether a repository matches their programming language. It would simplify their search for a project that they can use or where they can contribute.
If I reported it directly to GitHub, it wouldn't be trackable... Also, you (or if you are a volunteer contributor, then your peers working at GitHub) may know whom to address to get it actioned.
Thank you for Linguist. Imagine how awesome it would be if GitHub showed Linguist's result on every repository page.

Currently, only https://github.com/userName or https://github.com/organizationName show the repo languages. The actual repository page doesn't.

Oh, but it does. 😁
The common misconception is GitHub.com shows "a repository language", which is doesn't, and never has. There is no place within GitHub.com where you can specify a "repository language".  Instead, GitHub uses a concept of "this repo contains these languages in X, Y and Z proportions", and these proportions are determined by Linguist based on the bytes of code found within the repository.  This is detailed in the README:

The result of this analysis is used to produce the language stats bar which displays the languages percentages for the files in the repository.

https://github.com/userName or https://github.com/organizationName showing a language is only showing the most prominent language detected within the repo, determined by Linguist - this is not necessarily the "repository language".
With this mind...

Imagine how awesome it would be if GitHub showed Linguist's result on every repository page.

... it already is. Linguist is 100% responsible for all language representation and determination of a repo.
The closest you can get to marking a repo as an explicit language, regardless of what Linguist has determined, is by setting applicable topics on the repo, which are searchable.

Hi Colin or his friend,
Thank you for explaining.
Yes, github.com/organisationName shows the most prominent language at the bottom left of each repo item. For example 'Ruby' for https://github.com/github > Linguist:

However, github.com/organisationName/repoName (for example https://github.com/github/linguist) doesn't. People are missing out. That's where Linguist's result could help.

However, github.com/organisationName/repoName (for example https://github.com/github/linguist) doesn't. People are missing out. That's where Linguist's result could help.

It does, you just need to click on the bar at the top of the repository:

Hi Paul,
Thank you.
I set up several GitHub organisations, many repositories, browsed through even more... But never realised that the bar was clickable. It's so hidden.
Dear GitHubbers,
Imagine how you'd help people to see results of Linguist, and to find a project relevant to their programming language faster, if you made the "clickability" of the bar obvious.
Yes, it changes the mouse pointer on mouseover. But it's so thin and unexpected that most people won't notice. I guess UI designers want to save the screen space. There must be another way and more indicative.

@peter-kehl You raise a valid point that it's not immediately obvious that the bar is clickable. Unfortunately, there's absolutely nothing we can do about it from Linguist's perspective.
If you'd like to get your suggestion in front of the 👀 of the peeps who do have influence on this, I'd recommend either contacting our support team using the "Contact GitHub" link at the bottom of any page on GitHub.com or try the community forum at https://github.community/.

Hi Colin and Paul,
Thank you.
Anyone who agrees that the language indicator should be easier to see: Could you comment/add kudo to https://github.community/t5/Welcome/Easier-indication-of-a-repository-s-language-s/m-p/11541#M1721.


[BUG] Unable to access specified image title after saving it to the gallery

Describe the bug
I have a project where in one Dart file, I am saving a network image to the iOS gallery with a specified title (in my case, a hashcode). In another Dart file, I need to access that title that I specified, but widget.asset.title and widget.asset.titleAsync are not returning the title I set. Let's say when I am saving the network image, I set the title to be "55775351". In another screen, which displays asset entities from the iOS gallery, when I return the title, I get something like "IMG_3430" instead of the title I specified.
To Reproduce
Steps to reproduce the behavior:

Save a network image with a specific title.
final AssetEntity? entity = await PhotoManager.editor.saveImage(rawData, title: hashString + ".png");

Print the ID of this AssetEntity and you will see that it is not the specified title, even though in the camera roll you can see the title you specified.
String s = await entity.titleAsync;
print(s);

Expected behavior
Returning the Asset title should give the string you specified when you saved it. If you look in the iOS device gallery (since iOS now lets you swipe up and see metadata), you can see that the title you specified is being saved. But, if you try to retrieve that title, it outputs something different.
Screenshots
https://imgur.com/a/LAoryLe
In the screenshot from my iOS camera gallery, you can see that the title is 55775351, but when I fetch the title for this asset, it returns "IMG_3430" (this title follows sequentially from previous photos, so internally iOS is somehow rewriting it I guess - still, the title that I set displays, so should I not be able to access it?)
Flutter version
Flutter Version 2.10.3
Smartphone (please complete the following information):

Device: iPhone 12 Pro Max
OS: 15.3
Browser: Doesn't matter here, but Firefox

I should note, I read a similar issue where someone was having a similar problem, where they set a path but the newly created AssetEntity had an empty title - basically, the title they set was not being written in. This issue was marked as CLOSED but I could not find any solution in that thread. If you can, instead of just linking that issue since I already read it, could you please explain how to fix this? Thank you.

The title will be use in next code:
https://github.com/fluttercandies/flutter_photo_manager/blob/a8c193ed320bed5e833fcb7a93998e1652f9fec8/ios/Classes/core/PMManager.m#L1006
The apple document
Description in the official document: this field is the original name of the resource.

Thanks for the quick response.
I am having a little trouble understanding though. Does this mean it is impossible to access the title I set because Apple is overwriting it? If so, why can I see the title I set in the iOS camera gallery?
Basically, I am just wondering if someone can give me a clear-cut way to access the title I set since I am able to view it in the camera gallery.
Thank you for your help!

I know why this happened.
https://github.com/fluttercandies/flutter_photo_manager/blob/a8c193ed320bed5e833fcb7a93998e1652f9fec8/ios/Classes/core/PHAsset%2BPM_COMMON.m#L71-L96
I get the title of iOS asset with kvo, the method is fast.
The originalFilename can only be obtained through PHAssetResource, which is very slow.
If you need to obtain originalFilename in batch, the performance may not be satisfactory.

Clarification - originalFilename is what I set, right? So if I want to access the hashcode I have embedded in the title field, I will need to use PHAssetResource?

Now that it's not provided, we should modify the titleAsync property to provide the originalFileName.

Perfect, this seems like it should work - I'll look into this tomorrow and let you know. Thank you so much for all this help!

There are a couple of cases that get involved after the PR lands:

With a photo that you just saved, the getter should return the exact title as you used to save it.
With a photo that's edited, e.g. cropped, applied with filters, the method will try to find the edited resource, and return its originalFilename, and it could be different from your title.
With a Live Photo, the getter will return according to the subtype you requested (titleAsync or titleAsyncWithSubtype). It can return the originalFilename of the resource, or the originalFilename of the paired resource.

If an accurate title is not frankly necessary in your case, title is still preferred.


No amplifyconfiguration file

Hello,
I created a new iOS project following the official guide. I successfully added Auth and pushed everything to the cloud.
However, the CLI doesn't generate any amplifyconfiguration for me, however the awsconfiguration gets created, any suggestions?

Best Regards

Hi @nkb1337, amplify -v should show you 4.22.0 if you just installed the latest version.
Was version 1 of the CLI previously installed on your machine? If you uninstall the CLI and type amplify -v, what happens?

Hi @nkb1337, amplify -v should show you 4.22.0 if you just installed the latest version.
Was version 1 of the CLI previously installed on your machine? If you uninstall the CLI and type amplify -v, what happens?

Hi thnaks for the reply and sorry for my late response.
After I uninstalled it via npm it showed nothing. I even checked for any leftovers but it seems that iwas correctly uninstalled.
I found the amplify configuration things I needed on github in some other questions.
However, since this is not related to the amplify cli and an issue on my side I'll close this and fix this npm issue.
Best Regards and thanks for the help
Niko


Check for empty classes.

Empty classes that directly extend Object (like class FooType {} and class BarType implements Runnable {}) have no meaning.
I can't think of a use case for them. (Correct me if I'm wrong.)
They are stateless and should be represented as constant values.
It'd be cool if Error Prone could check for such misused types.

I have totally used these a few times in ways I don't think could be done any other way.
The main one that comes to mind is that I was testing memory consumption of collection data structures.  So I had a class Element {} where I could produce as many as I'd like, they'd retain the default reference equality and hashCode implementation so they were all distinct, but I didn't want to include the memory overhead of the elements themselves in the total measurement, so the memory tester stopped walking the object tree if it found an instanceof Element.

That makes sense, yep. It'd be too much boilerplate at the least to do that otherwise.
Thanks, I'll remember that!


elevation_mapping process has died

This is very useful however I was getting stuck on the elevation_mapping node, when I run:
rosrun elevation_mapping elevation_mapping
the process simple died immediately... saying: core dumped...
Even I define each topic name using "simple_demo.launch", it still does not run.
Is it because I was missing part of the topic? I did provide pointcloud2 pose and tf though.
Any suggestion on what should I try next?
Thanks!

I found a solution: you need to build the package with -DCMAKE_BUILD_TYPE=Release argument, so for me it was catkin build elevation_mapping -DCMAKE_BUILD_TYPE=Release.
The node will stop throwing the segmentation fault error and work properly. I found it by following the node debug procedures and ended up on this issue page.

@Nurgak Thank you so much! I will give it a try today and let you guys know how it goes. Hopefully we can close this issue soon.

Dear @baishibona and @Nurgak, thanks for reporting and investigating this. This is a problem I cannot currently solve as it is related to a problem with PCL/Boost and Debug mode/C++11. I will re-open this issue to keep track of the situation.

I also ran into this issue, which as Peter said appears to be related to https://github.com/PointCloudLibrary/pcl/issues/619. For reference, this is the backtrace I'm getting:
(gdb) bt
#0  0x00007ffff1f46ae0 in boost::math::lanczos::lanczos_initializer<boost::math::lanczos::lanczos17m64, long double>::init::init() ()
   from /usr/lib/libpcl_sample_consensus.so.1.7
#1  0x00007ffff1f1e5ce in ?? () from /usr/lib/libpcl_sample_consensus.so.1.7
#2  0x00007ffff7dea10a in call_init (l=<optimized out>, argc=argc@entry=3,
    argv=argv@entry=0x7fffffff8348, env=env@entry=0x7fffffff8368)
    at dl-init.c:78
#3  0x00007ffff7dea1f3 in call_init (env=<optimized out>,
    argv=<optimized out>, argc=<optimized out>, l=<optimized out>)
    at dl-init.c:36
#4  _dl_init (main_map=0x7ffff7ffe1c8, argc=3, argv=0x7fffffff8348,
    env=0x7fffffff8368) at dl-init.c:126
#5  0x00007ffff7ddb30a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6  0x0000000000000003 in ?? ()
#7  0x00007fffffff87bc in ?? ()
#8  0x00007fffffff8801 in ?? ()
#9  0x00007fffffff881b in ?? ()
#10 0x0000000000000000 in ?? ()

Would a temporary fix be adding https://github.com/ethz-asl/pcl_catkin to the workspace and thus compiling PCL from source?

Any updates/ideas for this problem? It seems it's gotten worse (?) for us, with getting loops of std::bad_alloc segfaults even when compiled in Release mode on multiple (but not all) machines we tried.

@skohlbr Have you tried building pcl from source with C++11? According to here this should solve the problem. It's strange that the problem has gotten worse for you, especially since the problem is related to the Debug mode. Are you sure that this is the same problem?

I have kinect and binocular camera, can tell me how to use these two devices running it, please, I need your detailed instructions @pfankhauser @baishibona @dljsjr

@wojiaojiao I think there is "starleth_kinect_demo.launch" which you might try with kinect, however not sure what to do with stereo cameras(depending on the driver for that), you might want to adjust your topic name for point cloud msg.
good luck.

@baishibona thank you ,but i only have kinect1,but no IMU or GPS and so on，Can I run out？

@baishibona @Nurgak @skohlbr @dljsjr i use kinect1 roslaunch starleth_kinect_demo.launch.but in rviz have nothing,the terminal show:
[ERROR] [1489454583.211567394]: Could not get pose information from robot for time<PHONE_NUMBER>.211551. Buffer empty?
[ERROR] [1489454583.211595878]: Updating process noise failed.
how can i solve it, Please help me


Add redux dev tools plugin

Hello guys, just discovered your library which looks very close to something I did on my own previously. Before I discovered this approach I worked at some big product with Redux and TypeScript. There I faced thare a problem with tones of JS and TS boilerplate which such an approach helps to eliminate.
Despite Redux introduce a huge overhead, it also has a nice community and good things such as https://github.com/zalmoxisus/redux-devtools-extension. Those tools are very popular and help a lot with app debugging.
So I'd like to propose to you an integration with redux dev tools. Actually those tool has API which allows integrations with any state machine.
Those integration looks like this:

and here you can see how it works:

So what do you think?

Hello @andregardi, @davityavryan, could you please take a look at this?

@iRON5 great addition!

@iRON5 One question, wouldn't this feature break when we store non-serializable variables (i.e. like it does when using Redux see the Redux docs)? I currently use Redux for most of my global state, and this hook for all non-serializable objects.

@rickstaa I think yes, as dev tools do not support it, this integration also will not work for non-serializable objects
The reason is in this line
https://github.com/use-global-hook/use-global-hook/pull/69/files#diff-5f201082d50c43761977bd925b83659cbc8738e2857d016ed9b0fc773558e585R21

@iRON5 No problem, it should return an empty object if I'm correct, so should not cause any problems. For my case, I can just keep the DevTools disabled.

Nice job. I will review this ASAP. ;)

@iRON5 Maybe we should add a line in the documentation similar to Redux so that people know that Redux DevTools doesn't work with non-serialized objects.

@rickstaa I think this is a very special use-case so maybe it does not makes much sense to duplicate it
But perhaps that would be handful to add the entire guide link to the doc so that would be helpful to wider range of people.
What do you think?

@iRON5 My idea was just to add one single line to the documentation. Something like:

Please note that the Redux-Dev tools only work with serializable objects.

On the other hand if people do store non-serializable objects there is not much hurt. It does not case any errors. The only thing is that those objects show up as empty in the dev tools and the time travel feature doesn't work.

would love to see this merged!


How to handle notification received and app opened by user tapping the notification

Hey @EddyVerbruggen
Not sure how to phrase this, so will just give it a go.
How do I handle the various use cases for receiving the notification? For example:
If the app is already in the foreground, or if opened by the user clicking on the notification (app closed or in background)...
I wrote a piece of code that navigates to an 'article' page based on the id and type in the 'data' payload of the notification, the catch is this:

when app not in foreground, the error is that the notification can't be received as the navigate property cannot be read of undefined -> this makes sense as the app is not 'open' at that point. I didn't know the code would execute (or attempt to) when the app is not open in foreground, other than displaying the notification.

When app is in foreground, the app automatically redirects/navigates to the 'article' page, which will annoy users endlessly when they're on a page and the app just navigates away.

How would we circumvent this? I'd like to be able to receive the notifications as normal, but only once the user taps on them does the handler execute (regardless of whether the app is in foreground or not). Any idea?

Is there anything in the Pushy docs / SDK that we can leverage to check whether or not the app was launched by tapping the notification? Because I don't see it.
What we could do is add a foreground: boolean property to the notification payload that's passed to your app. It will be true if the notification was received while the app was in the foreground.
On iOS that's easy to implement, but I'm looking for the best way to do it on Android.

@EddyVerbruggen I've spoken with John from Pushy (one of the main devs there) and he mentioned that the SDK they create wasn't for Nativescript and that I'd need to  chat to you about it. They don't officially support Nativescript. I think a foreground Boolean would be fine in terms of stopping the app from automatically redirecting, but how do we ascertain whether the app was opened by clicking/tapping the notification? When tapping the notification, the handler needs to be executed nce the app opens, and there I have no clue how to implement that.

@EddyVerbruggen I've sent John an email to see if he has any ideas too. Will advise when I have his feedback :)

@delanick That's a weird statement by John. Of course their SDK wasn't created for NativeScript, but the problem is not NativeScript-specific, is it? Even native iOS and Android apps will have the same challenges as the one you described.

@delanick You could check their suggestion for their Cordova implementation to achieve this: https://github.com/pushy-me/pushy-cordova/issues/16 -- so add pause/resume listeners the NativeScript way and use that to determine whether or not you should navigate.

@EddyVerbruggen I may have paraphrased a bit, but yeah, it would have the same limitations on their Native SDKs. I was asking him in the context of NativeScript and he responded in the same context, until he told me to ask you as they don't provide support for NativeScript. I've asked him for clarity and advice in context of their SDK now - so hoping he'll be able to advise us on a way forward.
I think go ahead with the foreground property so long as it will help either way when building the notification handler.
Only thing is, on iOS if the app is in foreground the notification isn't displayed, despite it and all its data being received, so we may need to display local notifications to the user with the data in it so that the user doesn't miss them. And then (if possible) handle the local notification tapped event to redirect the app... Really not sure.

@delanick You could check their suggestion for their Cordova implementation to achieve this: pushy-me/pushy-cordova#16 -- so add pause/resume listeners the NativeScript way and use that to determine whether or not you should navigate.

I did try that. Didn't work. The app goes through various states once you click on the notification, especially when killed and not active at all. I still have all my code written for it, just commented out. If you want I can send it to you. Maybe you can get it working.

To display a notification on iOS when in the foreground you have to do this. If the SDK doesn't handle it we could probably add some logic to the plugin to make it work.

To display a notification on iOS when in the foreground you have to do this. If the SDK doesn't handle it we could probably add some logic to the plugin to make it work.

@EddyVerbruggen yeah I wouldn't even know where to add that. But will check it out.

I understand, it's more of a "note to self" ;)

@EddyVerbruggen LOL, cool :) I panicked a bit there.... had no clue what to do.

@EddyVerbruggen Let me know if I can help in any way, even if just to get info from John them.

@EddyVerbruggen I sent you John's response to your Gmail address.
Let me know if this all helps.

@EddyVerbruggen Did you change the permission request for the Android part? My app now asks for permission to access photos and media on the device, but on Android only, iOS still asks for permission to send notifications.

@delanick Yes, @delanick John's reply helped. I will release a new version today or tomorrow and you can rely on the new appLaunchedByNotification and foreground properties for routing logic.
Regarding the permissions, it was added based on recommendations in the Pushy SDK Android docs to not exhaust your account because this way your device saves the token locally and can reuse it when the app is reinstalled. On iOS they leverage the keychain to get the same behavior.

Also see the update docs @ https://github.com/EddyVerbruggen/nativescript-pushy#setnotificationhandler

@delanick Yes, @delanick John's reply helped. I will release a new version today or tomorrow and you can rely on the new appLaunchedByNotification and foreground properties for routing logic.
Regarding the permissions, it was added based on recommendations in the Pushy SDK Android docs to not exhaust your account because this way your device saves the token locally and can reuse it when the app is reinstalled. On iOS they leverage the keychain to get the same behavior.

@EddyVerbruggen Apologies, only saw these now, was man-down this weekend (still am) with flu. Thanks so much for all if your help, you're an absolute legend bro!


Compilation fails due to possible source code syntax errors

When building version 3.6.0 using the example in the README, compilation fails with errors like:
[  5%] Building C object src/CMakeFiles/wi4mpi_MPICH_MPICH.dir/preload/gen/mpi_translation_c.c.o
In file included from /nishome/gsm/freeware_build/wi4mpi/src/common/mappers.h(137),
                 from /nishome/gsm/freeware_build/wi4mpi/src/preload/gen/mpi_translation_c.c(139):
/nishome/gsm/freeware_build/wi4mpi/src/preload/header/MPICH_MPICH/app_mpi.h(936): error: identifier "predefined" is undefined
                                           predefined error class */
                                           ^

Many more similar errors follow.  It looks as if there might be a comment character out of place somewhere, or that my compiler is not interpreting multi-line comments correctly.
I rolled back to 5294a6c and was then able to complete the build without issue.

Many thanks for your feedback, we gonna check!
@Clement-Fontenaille do you have any idea? Maybe the new generator?

Hi ,
Thanks for your input !
We fixed a couple of errors. Can you retry using that new version ?
I am currently attempting to reproduce your error.


BIP9 Failure and Warning

The following BIP9 failure and warning need to be resolved.
{
"chain": "main",
"blocks": 37406,
"headers": 37406,
"bestblockhash": "000000000000023c05d87eddaef4d5ecfdb29a0da15c6870f1737e30c9501f41",
"difficulty": 6401567.652339974,
"mediantime":<PHONE_NUMBER>,
"verificationprogress": 0.9999903406737708,
"initialblockdownload": false,
"chainwork": "00000000000000000000000000000000000000000000000a7a9f7b13d73f4365",
"size_on_disk": 20951089,
"pruned": false,
"softforks": {
"bip34": {
"type": "buried",
"active": true,
"height": 1
},
"bip66": {
"type": "buried",
"active": true,
"height": 1
},
"bip65": {
"type": "buried",
"active": true,
"height": 1
},
"csv": {
"type": "buried",
"active": true,
"height": 1
},
"segwit": {
"type": "buried",
"active": true,
"height": 1
},
"testdummy": {
"type": "bip9",
"bip9": {
"status": "failed",
"start_time": 0,
"timeout": 0,
"since": 36,
"min_activation_height": 0
},
"active": false
},
"taproot": {
"type": "bip9",
"bip9": {
"status": "failed",
"start_time": 0,
"timeout": 0,
"since": 36,
"min_activation_height": 0
},
"active": false
}
},
"warnings": "Unknown new rules activated (versionbit 0)"
}

This is potentially caused by /contrib/signet/miner, L:326:
INTERVAL = 600.0*2016/2015 # 10 minutes, adjusted for the off-by-one bug
This will require adjustment to match target block interval * miner confirmation window / ?
If we are to retain v22.0.9 miner confirmation window;
240.0*18/17
Else, if we revert to OG miner confirmation window (safe);
240.0*2016/2015

Resolved
"warnings": "Unknown new rules activated (versionbit 0)" is now resolved.
Most likely culprits:
-/contrib/signet/miner, L:326.
OR
-src/chainparams.cpp: checkpoints lacking prefix "0x".


Handle duplicate private classes

I have three *.ts files, each of which exports a single class but also has a non-exported utility class (TestScreen). The utility classes all have the same constructor signature and inherit from the same (exported) class (Screen), but perform different functions and have different documentation comments.
TypeDoc has trouble handling this:

The Screen documentation shows three different TestScreen subclass links, but they all go to the same testscreen.html page
The single testscreen.html page seems to merge all three classes' attributes and documentation comments

I would expect TypeDoc to create three separate *.html pages for the three private classes.
Confirmed with TypeDoc version 0.9.0 with TypeScript 2.4.1, and TypeDoc version 0.11.1 with TypeScript version 2.7.2. Workaround is to give each private class a different name.

It sounds like you are generating with --mode file, this mode pretends every module is in the global scope and will get very confused since you have multiple conflicting definitions. If you are using modules you should be using --mode modules The library mode (soon... #639) will provide an alternative that I expect will be better for most projects.


PCM-1693

I'm not sure how urgent these changes are but this will have conflicts with the PR I have up for enabling softphone calls so it'll probably have to wait until that gets merged.


Can mutation.event return the full path of the changed value in the $subscribe callback

What problem is this solving
A example:
import { defineStore } from 'pinia'

export const useFormData = defineStore('formData', {
  state: () => {
    return {
        arr: [{a:1}],
        obj: {a: 1}
    }
  }
})

import { useFormData } from '...'

export default {
  setup() {
    const formDataStore = useFormData()
    formDataStore.$subscribe((mutation, state) => {
       console.log(mutation, state)
    })
  },
}

now, if  i change formData.arr[0].a = 2, mutation will callback mutation.event.key = 'a', but i want get full path like arr[0].a
Proposed solution
Can add an attribute to mutation.event to identify the direct's full path?
Describe alternatives you've considered
No response

events come from Vue: https://vuejs.org/guide/extras/reactivity-in-depth.html#reactivity-debugging
Note this is development only, it will be empty in production, it's only for debugging purposes
There are plans to make the display of it better in devtools already (See #732)


Add support for adding static objects to plots

Color-code bounding boxes in scene plots, mapping labels to colors.

Stub started https://github.com/justinshenk/traja/blob/master/traja/frame.py#L156


Emit warnings for mistyped options : "brew commands --options"

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[x] Have you successfully run brew tests with your changes locally?

For the Homebrew command commands:
Previously, when running brew commands --SomeInvalidOption, the command would run without notifying the user that he/she has typed an invalid option. This PR resolves that and now when a brew commands is run with an invalid option, the command does not execute and it notifies the user that he/she has typed an invalid option.
Some example test cases after the changes are described below.
run: brew commands --include-aliases --blah --blah2
output:
Error: Invalid options provided:
--blah
--blah2
Valid options are:
--quiet
--include-aliases

run: brew commands --include-aliases
output: runs smoothly as it would before
run: brew commands --quiet
output: runs smoothly as it would before
run: brew commands --quite
output:
Error: Invalid options provided:
--quite
Valid options are:
--quiet
--include-aliases

Check the brew style failures and consider enabling Rubocop integration in your text editor.
In general I think these need to be part of a DSL which can also be used (although doesn't need to be in this PR) by the manpage generator.

@MikeMcQuaid can you please elaborate more when you say these need to be part of the DSL. From what I understand, DSL is kind of like a template of a function. Am I right? Can you point me to some resources which explain the DSL concept in more detail? Thanks

@raza15 Sorry, I mean we should have something like the formula DSL that allow the e.g. specification of options for commands and descriptions for them and not have the logic be in every command. This may also involve adding a DSL for commands themselves.

@MikeMcQuaid made the changes you requested and brew style and rubocop app spec Library/Homebrew/cmd/commands.rb show no failures

Added 1 more thing: deciding whether to put "options" or "option" in the error message depending on the number of incorrect arguments provided by user

@raza15 Just FYI that I'd like to see a DSL in some form before we merge this.

Also, for printing the error message, what should be done for the following use case:
brew commands --uq --pop --pop

Should the invalid option --pop be counted once or twice?
Right now in the latest commit https://github.com/Homebrew/brew/pull/2420/commits/f5c61bec3069255a95c869bb96463acf05167874, it is being counted twice and the following error message is printed:
Error: 3 Invalid Options Provided: --uq --pop --pop
Only 2 Options Valid: --quiet --include-aliases

Let me know if it should be counted as once only. Thanks!

It should probably be counted only once. Please remember to address @MikeMcQuaid’s comment above: we’d like to see a DSL to handle this instead of re-implementing the same logic to all commands. How would you generalize this code to work for all commands given the valid options for one command? How/where would we write each command’s valid options?

@bfontaine  I believe writing a global function which will take the valid_options as input and that function will be doing the error checking and error printing. Since ARGV  is already a global variable so that will be available to that function. The function will return a value indicating if there is an error or not. (I think this is what is meant by implementing a new DSL. Please correct me if I am wrong. What I know so so far about the DSL is that it is kind of a template. For example, the bottle do...end block is a DSL. And it has certain fields which are set by each different command.)
This function will be called by each command during the beginning in each command. The valid_options will have to be declared in each command and passed to that global function.
I am thinking of implementing this global function in the following file: /usr/local/Homebrew/library/Homebrew/brew.rb. This function can then be called by each brew command present in /usr/local/Homebrew/library/Homebrew/cmd/ directory. (I implemented a demo function in brew.rb and called it from commands.rb file and it worked)
Please correct me if I am wrong anywhere. Thanks!

I believe writing a global function which will take the valid_options as input and that function will be doing the error checking and error printing.

We would probably rather this wasn't global and was a Homebrew::Commands or similar and a DSL like command do is present in each command file.

Since ARGV is already a global variable so that will be available to that function.

ARGV should be passed as a parameter to reduce the amount of global state we rely on.

For example, the bottle do...end block is a DSL. And it has certain fields which are set by each different command.)

Yup.

I am thinking of implementing this global function in the following file: /usr/local/Homebrew/library/Homebrew/brew.rb.

This would not be a good place.

This function can then be called by each brew command present in /usr/local/Homebrew/library/Homebrew/cmd/ directory.

Yep.
Note as well as valid/invalid options the DSL should also be capable of being used to generate documentation of each option.

Hi @MikeMcQuaid. How about implement this function in the directory: usr/local/Homebrew/library/Homebrew/commands.rb ?
So to check how this works, I did the following and it works.
In the Commands module, I implemented a new function:
  def self.raza(argu)
    puts argu
  end

Then this function is called from individual commands in /cmd/ directory as follows:
    require 'commands'
    Commands.raza("I am awesome")

Currently I am trying to figure out how the bottle DSL is implemented.

Currently I am trying to figure out how the bottle DSL is implemented.

https://github.com/Homebrew/brew/blob/2ba53eb272ec56d806bcdc62b02a8ab1b3c92e52/Library/Homebrew/software_spec.rb#L289-L356

Hi @MikeMcQuaid & @bfontaine! I've added the DSL. Let me know your comments on it. Thanks!

One thought for future reference:
For a particular command in cmd/ directory:
Instead of declaring valid_options manually in each command.rb, write a function which reads that command.rb and builds the valid_options itself by reading the first few commented lines from the command.rb (P.S. This is the same text that is outputted by brew command --help). All the words preceded by -- are valid options. Maybe also include words preceded by - in valid options (but, confirm with maintainers first)

Instead of declaring valid_options manually in each command.rb, write a function which reads that command.rb and builds the valid_options itself by reading the first few commented lines from the command.rb (P.S. This is the same text that is outputted by brew command --help). All the words preceded by -- are valid options. Maybe also include words preceded by - in valid options (but, confirm with maintainers first)

It’s probably better to declare them manually, then use that info to generate brew <command> --help’s output. They have to be declared somewhere anyway; let’s do that directly in code instead of writing comments that are then parsed by another piece of code.

Ok thanks @bfontaine ! What do you think of the DSL?

1 note regarding the DSL:
The reason I put this code:
def check_for_incorrect_options(&block)
  incorrect_options_for_brew_commands = IncorrectOptionsForBrewCommands.new
  incorrect_options_for_brew_commands.instance_eval(&block)
 end

in Homebrew/brew.rb is so that check_for_incorrect_options do...end block is called from the Homebrew/cmd/commands.rb file. If that function was placed in, for example, the module Commands in file  Homebrew/commands.rb, then the DSL block in Homebrew/cmd/commands.rb file will have to be called like this:
require 'commands'
Commands.check_for_incorrect_options do
...
end

If this is fine with you, I can move the check_for_incorrect_options(&block) function out of Homebrew/brew.rb to Homebrew/commands.rb

Please ignore the above comment https://github.com/Homebrew/brew/pull/2420#issuecomment-292552832. I've made changes that renders that comment useless.

What do you think of the DSL?

I think it’s on the right track; but I was thinking more of something at the command level, some way to tell Homebrew “this command accepts those options”. The current code works if you want to check for invalid options, but it doesn’t really take advantage of the possibilities offered by a DSL.
What if it were written in a more declarative way? Not “check for these options” but “here are the valid options”. Then we could use that info not only to check for invalid options but also generate help or command-line autocomplete. See e.g. Trollop for inspiration.

@bfontaine I've made the DSL more declarative in https://github.com/Homebrew/brew/pull/2420/files. Let know if this is what you had in mind. Thanks!

Sample output as of commit https://github.com/Homebrew/brew/pull/2420/commits/6dbc797ed3c4c47457639b4ae4b610958f2cb2e6
Error: 1 Invalid Option Provided: --pop
Only 2 Options Valid: --quiet --include-aliases

    --quiet:  List only the names of commands without the header
    --include-aliases:  The aliases of internal commands will be included

Improved error messages a bit.
Sample error messages as of commit https://github.com/Homebrew/brew/pull/2420/commits/19754bcdd226da8aed7028a51ec7eed5537ea5aa
$brew commands --lol --pop:
Error: 2 invalid options provided: --lol --pop
<commands> has only 2 valid options: --quiet --include-aliases

    --quiet:  List only the names of commands without the header
    --include-aliases:  The aliases of internal commands will be included

$brew commands --lol (if it has no valid options):
Error: 1 invalid option provided: --lol
<commands> has no valid options

Hi @MikeMcQuaid! It would be great if i could get your feedback :) Thanks!

I've been away with work, I'll look at this as soon as I can.

Can’t we remove the call to check_invalid_options? Is there a case when we’d want to declare a block of valid options without checking for invalid ones?

Hi @bfontaine!

Can’t we remove the call to check_invalid_options? Is there a case when we’d want to declare a block of valid options without checking for invalid ones?
From what i can think of right now, if you want to remove the call to check_invalid_options, it can be done if we give the options as an array. Like the following:

options do
    valid_options ["option 1", "option 2"]
end

Because then we can call the check_invalid_options at the end of the function valid_options (I don't think that this is what we need).
Do let me know if you have any other ideas in mind on how to achieve this :)

We could do it when the options do block ends?
def self.options(&block)
  options_for_brew_commands = OptionsForBrewCommands.new
  options_for_brew_commands.instance_eval(&block)
  # <--- here
end

@bfontaine Done. I don't know why I didn't do this previously.

Thanks @raza15. Beside my two other comments; I think this should be defined somewhere outside the def commands method so that we could retrieve a command’s options without actually calling that command’s method.
That’s probably way too advanced compared to the small change intended by this PR but at some point I experimented with a “one class per command” implementation, e.g.
module Homebrew
  class CommandsCommand < Command
    desc "that command do foo and bar"
    option "foo", "do more foo"
    option "quiet", "be quiet"

    def run(*args)
      # run the actual code
    end
  end
end

I'm really liking the direction this is going. Glad someone is finally giving it some attention! :)

Hi @MikeMcQuaid & @bfontaine, I've made all the requested changes. Let me know if there are any more.
@bfontaine, I'll look into this in a couple of days (after I get free from my exams)

I think this should be defined somewhere outside the def commands method so that we could retrieve a command’s options without actually calling that command’s method.

That’s probably way too advanced compared to the small change intended by this PR but at some point I experimented with a “one class per command” implementation, e.g.
module Homebrew
class InstallCommand < Command
desc "install stuff"
option "foo", "do foo"
option "quiet", "be quiet"
def run(*args)
  # run the actual code
end

end
end

I'd love to see some unit tests for the CommandOptions class — you've already identified some test cases, but it would be nice if they could be automated. Shout if you need a hand!

@alyssais I'll add them in a few days :) I have an exam on Monday :) Plus, in which file can I add the unit tests?

Make a new file Library/Homebrew/test/command_options_spec.rb, and call into your class from there. You might find the other spec files useful in figuring out what you do, but if you get stuck, just ask. :)
Good luck with the exam!

Great. Thanks @alyssais! :)

Hi @alyssais, I've added the tests. Let know your comments on it. Also, do let me know which format of the tests do you prefer: (test 4 & 5) or (test 6).
Thanks!

@raza15 Just so you know I am following along but just letting @alyssais lead the way for now.

Hi @alyssais, I've added 2 tests that test the variables in the CommandOptions class like you said. Are these enough or should I add more tests?
Also, should I remove all the brew commands tests from line 48 onwards?
Thanks again for your feedback! :)

Also, for all the other tests that invoke brew, I have tried to make all of these generic such that they can work for any brew <command>. Also, even if the options changes in any of the command files, this will not make the tests fail because the options are not hardcoded but fetched from the command file in real time.
Let me know if you still want to just remove these tests that invoke brew... :)
Thanks!

Hi @alyssais, I have added tests for the CommandOptions() class such that they check the error messages on custom commands without calling the brew....
I guess now we don't need the brew... tests but I think they will be useful to check the implementation of the options DSL when it is extended to other commands. Let me know if we should remove them.
Also do let me know your comments on the CommandOptions() tests and if there's any other things I can add.
Thanks!

Hi @alyssais, I have removed all the brew... tests as well as their helper functions :)

I think this should be defined somewhere outside the def commands method so that we could retrieve a command’s options without actually calling that command’s method.

That’s probably way too advanced compared to the small change intended by this PR but at some point I experimented with a “one class per command” implementation, e.g.

module Homebrew
class InstallCommand < Command
desc "install stuff"
option "foo", "do foo"
option "quiet", "be quiet"

def run(*args)
  # run the actual code
end

end
end

I think this should be defined somewhere outside the def commands method so that we could retrieve a command’s options without actually calling that command’s method.
That’s probably way too advanced compared to the small change intended by this PR but at some point I experimented with a “one class per command” implementation

Hi @bfontaine! I have written a method that can get a particular command's options without calling the command's methods. Let me know if we can use this to accomplish what you had in mind.
def get_valid_options(cmd)
  # parses the #{cmd}.rb file and extracts the valid options defined in the options DSL
  content = File.readlines "cmd/#{cmd}.rb"
  inside_options_block = false
  valid_options = {}
  content.each do |line|
    if inside_options_block == true
      if line.include? "option"
        line_splitted = line.scan(/"([^"]*)"/)
        option = line_splitted.first.first
        option_description = line_splitted.last.first
        valid_options[option] = option_description
      end
      break if line.include? "end"
    end
    inside_options_block = true if line.include? "options do"
  end
  return valid_options
end

(i.e. get a particular command's options without calling the command's method).

We'll also need this so we (not in this pull request but part of GSoC if you're accepted) have brew install --help use this DSL to avoid duplicating option descriptions.

We'll also need this so we have brew install --help use this DSL to avoid duplicating option descriptions.

@MikeMcQuaid and we cannot use the get_valid_options(cmd) method (in the above comment) for this purpose too? Will a new DSL have to be implemented following the "one class per command" implementation?

@raza15 Something like that should be able to made to work, yep.

Hi @MikeMcQuaid. So I implemented a feature that suggests the user the closest valid option for each invalid option provided. For this, I used the Levenshtein algorithm ([https://rosettacode.org/wiki/Levenshtein_distance#Ruby]), which does a fuzzy string matching to known strings and generates a value based on how many characters need to be changed/added/deleted for the fuzzy-string to match the known-string.
Do let me know if I can include this in the error message.
Sample output:
Wrong options provided. Did you mean?
    	"--foo" instead of "--Foo"
	"--bar" instead of "--BAR!"
	"--quiet" instead of "quit"

Code:
def levenshtein_distance(a, b)
  a, b = a.downcase, b.downcase
  costs = Array(0..b.length) # i == 0
  (1..a.length).each do |i|
    costs[0], nw = i, i - 1  # j == 0; nw is lev(i-1, j)
    (1..b.length).each do |j|
      costs[j], nw = [costs[j] + 1, costs[j-1] + 1, a[i-1] == b[j-1] ? nw : nw + 1].min, costs[j]
    end
  end
  costs[b.length]
end

def find_closest_options(valid_options, invalid_options)
  closest_options = {}
  invalid_options.each do |invalid_option|
    min_distance = nil
    corresponding_option = nil
    valid_options.keys.each do |valid_option|
  	  dist = levenshtein_distance(valid_option, invalid_option)
      if min_distance == nil
        min_distance = dist
        corresponding_option = valid_option
      elsif dist < min_distance
        min_distance = dist
        corresponding_option = valid_option
      end
    end
    closest_options[invalid_option] = corresponding_option
  end
  closest_options
end

def test_case()
  valid_options = {"--foo": "do foo", "--bar": "go to bar", "--quiet": "be quiet"}
  invalid_options = ["--Foo", "--BAR!", "quit"]
  closest_options = find_closest_options(valid_options, invalid_options)
  puts <<-EOS
  Wrong options provided. Did you mean?
    	#{closest_options.map { |k, v| "\"#{v}\" instead of \"#{k}\"" }.join("\n	")}
  EOS
end

test_case()

Something like that should be able to made to work

Also @MikeMcQuaid, by something like that, do you mean use the get_valid_options(cmd) method or implement the one class per command DSL ?
Thanks!

@raza15 Probably b); rereading and parsing the file shouldn't be necessary if we can just query a class from Ruby.

Thanks @MikeMcQuaid. Also, can I include the "valid suggestions" for invalid options provided by user as indicated in this comment https://github.com/Homebrew/brew/pull/2420#issuecomment-298253956 ?

@raza15 I think using that algorithm would be a great addition but I think it's lower priority than getting a command DSL working end-to-end for a single command (i.e. handles invalid options, provides documentation of options with --help, outputs in manpage).

Hi @alyssais, I've made all the requested revisions :) Do let me know if there are any more :) Thanks!

Thanks @alyssais! :)

Just FYI for everyone following along @raza15 was accepted into our GSoC 🎉

Thanks @MikeMcQuaid! I should now get started with the "one class per command" implementation as was pointed out by @bfontaine in the following comment: https://github.com/Homebrew/brew/pull/2420#issuecomment-295419433. Any suggestions/pointers on how to get started with this? And how should the commands.rb look like?

I believe what @bfontaine meant was this:
Lets take the example of commands.rb. It should look something like this:
module Homebrew
  def InstallCommand < CommandOptions
    option "foo", "do foo"
    option "quiet", "be quiet"

    def commands
      # the code when brew commands is run
    end
  end
end

Should I go ahead with this?

def InstallCommand < CommandOptions

This should be a module or a class. Otherwise, yep 👍

CC @woodruffw To help and review here as @raza15's mentor.

Also @MikeMcQuaid @woodruffw , now i'll get started with providing documentation with --help command and outputs in manpage as suggested by Mike in the comment: https://github.com/Homebrew/brew/pull/2420#issuecomment-298874529.
Any suggestions on how to get started with this?

Any suggestions on how to get started with this?

I think the core changes will be in dev-cmd/man.rb and cmd/help.rb, since those are where we parse the #: lines for manpages and --help respectively.
I'll need to finish reading through your code, but I think we'll probably want to translate the command (e.g., install) to a classname (e.g. InstallCommand) and then call help or man on that (e.g., InstallCommand.help).

Hi guys, I have added the support for --help documentation directly derived from class. Let me know what you think of it.
Output for running brew commands --help:
brew commands [--quiet][--include-aliases]
    --quiet:  List only the names of commands without the header
    --include-aliases:  The aliases of internal commands will be included

Hi @MikeMcQuaid @bfontaine @woodruffw, I have added the support for --help documentation which can be derived directly from the class, as was suggested by Bfontaine. I would love your guys feedback on it. Thanks!

Looks like a good approach at first glance; I'll take some time to review more thoroughly this weekend. Thanks @raza15!

Hi @alyssais! Thanks for the detailed review :) I've made all the requested changes. Do let me know of any more changes(if any). Thanks!

Hi @bfontaine! Thanks for the review. Is this the DSL you had in mind when you initially mentioned it? Would you like any other features added to it?

Yep; this is great! :tada:
I think when all commands use the new system we should be able to auto-detect them by e.g. looking at child classes of Command.

Hi @MikeMcQuaid, you mentioned that we need to update manpage also (https://github.com/Homebrew/brew/pull/2420#issuecomment-298874529). Can you please elaborate what updates should be made to the manpages when we run brew man.
Running brew man, updates these files:
Writing markdown to /usr/local/Homebrew/docs/Manpage.md
Writing man page to /usr/local/Homebrew/manpages/brew.1
Writing man page to /usr/local/Homebrew/manpages/brew-cask.1

What specific updates to these files you had in mind?

@raza15 The output should be identical but the input should be from the DSL rather than from the #: lines at the top of the file.

Hi @MikeMcQuaid @bfontaine @alyssais , I have also added a new function for brew man which reads directly from the DSL class, if there is one, otherwise reverts to the old way of fetching the #: lines (this is to prevent failures until the classes for all the commands is added).

Just for my future reference before this PR is merged:
A few things that need to be added to the current DSL Command:

a variable desc
support for options that are only relevant when some other option is provided. For example, with the commands options, --include-aliases is only relevant if --quiet is passed

Hi @MikeMcQuaid, it would be great if I could get your feedback on it. Thanks!

Hi guys! I am implementing the following feature in the Command DSL:

support for options that are only relevant when some other option is provided. For example, with the commands options, --include-aliases is only relevant if --quiet is passed

I wanted to confirm if its fine if the CommandsCommand class looks like this: (passing the parent option for each option)
  class CommandsCommand < Command
    def initialize
      super
      desc "Show a list of built-in and external commands"
      option "--quiet", "List only the names of commands without the header"
      option "--include-aliases", "The aliases of internal commands will be included", :parent => "--quiet"
    end
  end

Or do you prefer some other way?
CC: @MikeMcQuaid @bfontaine @alyssais

That looks pretty good! Do you think you could do this at the class level, like we do with formulae?
class CommandsCommand < Command
  desc "Show a list of built-in and external commands"
  option "--quiet", "List only the names of commands without the header"
  option "--include-aliases", "The aliases of internal commands will be included", :parent => "--quiet"

  # ...
end

Hi @MikeMcQuaid, i've tried to make most of the changes requested by you like removing the initialize, etc and making it more like the bottle DSL, adding support for sub-options, making the output to manpages similar as before, outputting the help result in the same manner as before. However, I'll fix the brew style warnings tomorrow.
Please do let me know what you think of the code now. Thanks!

@raza15 Some other thoughts (@woodruffw, @bfontaine and others feel free to agree/disagree):

when talking about being more like bottles I think option do is an improvement but I was thinking the whole thing could be a method definition inside the Homebrew module e.g. command "commands" do. This means it could be more easily evaluated multiple times whereas a class can only be evaluated once. I don't feel strongly about this, though.
I think the goal (doesn't need to be in this PR but it should be part of this project) that there's no specific calls to ARGV anywhere in a command class/method; these should be inside the Command base class and then the Command class queried for the options used rather than ARGV. This is a big reason for refactoring command classes in the first place; we want to reduce then eliminate the number of places in Homebrew/brew than ARGV is used for global state and instead switch to accessors on our own classes.

Library/Homebrew/global.rb

@raza15 Just a note that I'd make sure to fix conflicts (and brew style) every time you push changes. This makes it easier for people to review your work and see how the tests are looking.

make sure to fix conflicts
@MikeMcQuaid got it :)

I was thinking the whole thing could be a method definition inside the Homebrew module e.g. command "commands" do. This means it could be more easily evaluated multiple times whereas a class can only be evaluated once. I don't feel strongly about this, though.

@MikeMcQuaid I’m not sure I’m following you here. How would you separate the options definition and the code actually running the command?

I think the goal (doesn't need to be in this PR but it should be part of this project) that there's no specific calls to ARGV anywhere in a command class/method; these should be inside the Command base class and then the Command class queried for the options used rather than ARGV. This is a big reason for refactoring command classes in the first place; we want to reduce then eliminate the number of places in Homebrew/brew than ARGV is used for global state and instead switch to accessors on our own classes.

Agreed.

Hi @MikeMcQuaid I have added that options block and updated how the man and help outputs are generated accordingly. Let me know what you think! Thanks!
(P.S. i will be removing the commented out code and fixing brew style in a while)
Hi @woodruffw , Thanks for the review! I'll make the changes in a while.

All brew style warnings have been fixed

Hi @MikeMcQuaid, please let me know what you think of the code now. Thanks!
CC: @woodruffw @bfontaine

@raza15 Can you please make sure brew tests passes locally before you push changes? It makes it easier to review with green CI. Thanks!

Hi @woodruffw please do let me know your comments on the newly added feature: mehtods for checking valid options in ARGV.
Thanks!

@raza15 Sorry, I was AFK for a few days.
I agree with @MikeMcQuaid - we should transform options like --foo-bar into methods like foo_bar. Additionally, it'd be amazing to transform boolean/toggle options into predicates, e.g. --verbose into verbose?, although I'm not sure how practical that would be in terms of the DSL.

Hi @woodruffw, I've made the above 2 changes you requested. Please do let me know further your further comments on it. Thanks!

@raza15 Can we start to squash this down to a few commits, preferably one per feature?

@woodruffw Sure! I'll look into how to do that :)

Hi @woodruffw, I have completed the implementation of handling --foo=2 options.
Test Case:
    options do
      command "commands"
      desc "Show a list of built-in and external commands."
      option name: "quiet", desc: "list only the names of commands without the header." do
        option name: "include-aliases", desc: "the aliases of internal commands will be included."
      end
      option name: "prune", value: "days", desc: "remove all cache files older than <days>."
      option name: "prune1", value: "days", desc: "remove all cache files older than <days>."
    end

Running brew commands --foo --pop --quiet --prune= --prune1 --lol=20, generates the following result:
Error: 3 invalid options provided: --foo --pop --lol
--prune requires a value <days>
--prune1 requires a value <days>

Correct usage:
brew commands [--quiet [--include-aliases]][--prune=days][--prune1=days]:
    Show a list of built-in and external commands.

    If --quiet is passed, list only the names of commands without the header.
    With --include-aliases, the aliases of internal commands will be included.
    If --prune=days is specified, remove all cache files older than days.
    If --prune1=days is specified, remove all cache files older than days.

I'll add these tests to the spec file in a while. Please let me know your comments. Thanks!

Some more test cases:
Running brew commands --lol --pop --quiet, produces:
Error: 2 invalid options provided: --lol --pop
Correct usage:
brew commands [--quiet [--include-aliases]][--prune=days][--prune1=days]:
    Show a list of built-in and external commands.

    If --quiet is passed, list only the names of commands without the header.
    With --include-aliases, the aliases of internal commands will be included.
    If --prune=days is specified, remove all cache files older than days.
    If --prune1=days is specified, remove all cache files older than days.

Running brew commands --quiet --prune=20, successfully runs the commands.
Running brew commands --quiet --prune, produces:
Error: 0 invalid options provided:
--prune requires a value <days>

Correct usage:
brew commands [--quiet [--include-aliases]][--prune=days][--prune1=days]:
    Show a list of built-in and external commands.

    If --quiet is passed, list only the names of commands without the header.
    With --include-aliases, the aliases of internal commands will be included.
    If --prune=days is specified, remove all cache files older than days.
    If --prune1=days is specified, remove all cache files older than days.

Running brew commands --quiet --lol=50, produces:
Error: 1 invalid option provided: --lol
Correct usage:
brew commands [--quiet [--include-aliases]][--prune=days][--prune1=days]:
    Show a list of built-in and external commands.

    If --quiet is passed, list only the names of commands without the header.
    With --include-aliases, the aliases of internal commands will be included.
    If --prune=days is specified, remove all cache files older than days.
    If --prune1=days is specified, remove all cache files older than days.

Hi @MikeMcQuaid & @woodruffw! In the command cleanup, there is -s (option with a single preceding -. What are these called?) I was thinking of adding their functionality too. Should I go ahead with it? In the options block, this could have another method, like, smaller_option name: "s", desc: "scrub the cache".
Also, the help for cleanup looks like this: cleanup [--prune=<days>] [--dry-run] [-s] [<formulae>], how can I add the feature of including this [<formulae>] in the DSL? Maybe in the options block, have something like:
options
  include_formulae_in_help :true
  option name: "foo", desc: "do foo"
end
What do you think?

Thanks!

What are these called?

Switches. The thing about these is that they can be concatenated, i.e. if you have, --debug/-d and --scrub/-s, -ds, -sd, -d -s and -s -d have to behave the same.

Great. Thanks @reitermarkus!

Also, the help for cleanup looks like this: cleanup [--prune=] [--dry-run] [-s] [<formulae>], how can I add the feature of including this [<formulae>] in the DSL? Maybe in the options block, have something like

I'm of the opinion that we should just let trailing arguments come from an array of some sort, possibly just argv or args per command class (to distinguish from ARGV). No need for a DSL component for those, just make sure that they're available as an array in each command class.

Looking through man brew again, I've noticed that we have a few commands that don't obey the --foo-bar style and use --foo bar instead.
In particular, brew create uses the latter style:
create URL [--autotools|--cmake|--meson] [--no-fetch] [--set-name name]
       [--set-version version] [--tap user/repo]

And brew tests uses both styles:
tests [--verbose] [--coverage] [--generic] [--no-compat]
      [--only=test_script[:line_number]] [--seed seed] [--online] [--official-cmd-taps]

That's something we need to handle, unless we want to break compatibility and switch to a uniform style (thoughts @MikeMcQuaid?)

I'm in favour of options with =.

What are these called?

We call them flags internally/in ARGV. I think this naming is confusing and 👍 to @reitermarkus' switches.

Should I go ahead with it? In the options block, this could have another method, like, smaller_option name: "s", desc: "scrub the cache".

Yes, please.

I'm of the opinion that we should just let trailing arguments come from an array of some sort, possibly just argv or args per command class (to distinguish from ARGV). No need for a DSL component for those, just make sure that they're available as an array in each command class.
Alternatively, if others feel strongly about specifying trailing arguments in the DSL, possibly something like arguments :formulae and argument :formula, which would produce an array formulae and single string formula respectively (and handle cases where the argument(s) are missing).

I don't feel super strongly but I think having all argument be named would be good.

That's something we need to handle, unless we want to break compatibility and switch to a uniform style (thoughts @Homebrew/maintainers?)

I don't think we can break compatibility here.

I don't think we can break compatibility here.

Cool. We'll need to support both forms then, @raza15. If we could do it in a single method, this would actually have the nice advantage of making both --foo=bar and --foo bar work for all commands.

Hi @MikeMcQuaid, I have a question: The command brew desc [-s|-n|-d] (text|/text/) has 2 parts:

[-s|-n|-d]: Only 1 out of 3 -n,-s,-d options can be given.
(text|/text/): certain parameters given in round brackets.

How do you suggest we handle each of these? As in, what should the options block look like for them?

[-s|-n|-d]: Only 1 out of 3 -n,-s,-d options can be given.

You could provide some array argument to a flag which specifies what other flags cannot be used simultaneously. Alternatively, you could have some other container structure which implies exclusivity between the contents.

(text|/text/): certain parameters given in round brackets.

I think this was intended to state the parameter was optional but we may be inconsistent with how we output them. As long as we have a consistent form for required vs. optional parameters I'm open to using whatever results in the smallest difference to our output.

As a general comment, there's now a lot of code/changes in this PR and it's quite hard to review. I think it's worth thinking about how this can be split into smaller, independent PRs (which can build on each other) which will make this easier to review and merge. I'd like to see something small merged before the first evaluation period, if at all possible. Thanks @raza15, you're doing good work 👏

[-s|-n|-d]: Only 1 out of 3 -n,-s,-d options can be given.

IMO, we should handle mutually exclusive switches during command "execution", not within the argument parsing period via DSL specification.
It's relatively simple to make N flags or options exclusive, but it'll quickly get very complicated with suboptions, mixed exclusivity, and so forth. That'll probably be hard to represent succinctly in a DSL, and will subsequently make the DSL for each command harder to read and write.
I can think of two reasonable ways to handle mutually exclusive options during "execution," although there are probably others:

Fail if given, telling the user that only one may be supplied at a time.
Select the first mutually exclusive option, warn the user, and continue onwards.

(text|/text/): certain parameters given in round brackets.

I think this was intended to state the parameter was optional but we may be inconsistent with how we output them.

For this calling form of brew desc, the text|/text/ argument is mandatory.
I think the parentheses (round brackets) are simply there to indicate grouping (association), and don't imply optionality. Just like how parentheses are used to indicate precedence in mathematical expressions. (In this case, the parens mean that just text and /text/ are alternated between, instead of /text and everything to the left of the |. The | normally has high precedence.) Optionality is indicated by square brackets instead of parentheses. This is a common convention for man pages, and is what I've seen elsewhere in brew. (It's similar to Extended Backus Naur Form.)

Hi Raza! This is looking good so far.
Here's something to consider:
In some cases, the short switches are just abbreviations for other options, and have the same functionality, so should probably share the same help text. (And we do not include the short switch form in the synopsis.) For example, in brew install, '-dis short for--debug, -sfor--build-from-source, -ishort for--interactive, and so on. See brew help install` for how those are incorporated in the descriptions.
Maybe it would be good to have a form of the options DSL that took a list of aliases or abbreviations for an option? Something like:
   option [ "debug", "d" ], "enables interactive debugging session when brewing fails"
   option [ "interactive", "i" ], "download and patch formula, then open a shell"

I think the parentheses (round brackets) are simply there to indicate grouping (association), and don't imply optionality. Just like how parentheses are used to indicate precedence in mathematical expressions

To elaborate on this: I think we use parentheses in the man pages for a purely practical reason: ronn(1) has a bug where it doesn't emit <mandatory> options correctly if they're also valid HTML tags. I came up with my own very ugly solution to this for my own projects, but I think sticking to parentheses for mandatory options is fine as long as we're consistent.

FYI, here's an old PR from when I made an attempt at converting brew commands to be defined with objects. It didn't get merged because it didn't have DSL support like you're working on, but it may still give you some ideas. In particular, it has code for doing the implementation-switching trick for simultaneously supporting new class-based and old function-based commands.
https://github.com/Homebrew/brew/pull/28

In some cases, the short switches are just abbreviations for other options, and have the same functionality, so should probably share the same help text. (And we do not include the short switch form in the synopsis.) For example, in brew install, '-dis short for--debug,-sfor--build-from-source,-ishort for--interactive, and so on. Seebrew help install` for how those are incorporated in the descriptions. Maybe it would be good to have a form of the options DSL that took a list of aliases or abbreviations for an option?

Hi @apjanke, this feature is already implemented in the code :) So, in the commands.rb, if I give all the options of the install command and run brew commands --help, the following result is outputted:
brew commands [--debug] [--env=std] [--ignore-dependencies|--only-dependencies] [--cc=compiler] [--build-from-source] [--force-bottle] [--devel] [--HEAD] [--keep-tmp] [--build-bottle] formulae:
    Show a list of built-in and external commands.

    If --debug or -d is passed, open an interactive debugging session with access to IRB or a shell inside the temporary build directory.

    If --env=std is specified, use the standard build environment instead of superenv.

    If --ignore-dependencies is passed, skip installing any dependencies of any kind. If they are not already present, the formula will probably fail to install.

    If --only-dependencies is passed, install the dependencies with specified options but do not install the specified formula.

    If --cc=compiler is specified, attempt to compile using compiler. compiler should be the name of the compiler's executable, for instance gcc-4.2 for Apple's GCC 4.2, or gcc-4.9 for a Homebrew-provided GCC 4.9.

    If --build-from-source or -s is passed, compile the specified formula from source even if a bottle is provided. Dependencies will still be installed from bottles if they are available.

    If --force-bottle is passed, install from a bottle if it exists for the current or newest version of macOS, even if it would not normally be used for installation.

    If --devel is passed, and formula defines it, install the development version.

    If --HEAD is passed, and formula defines it, install the HEAD version, aka master, trunk, unstable.

    If --keep-tmp is passed, the temporary files created during installation are not deleted.

    If --build-bottle is passed, prepare the formula for eventual bottling during installation.

And the options DSL looks like this:
    options do
      command "commands"
      desc "Show a list of built-in and external commands."
      argument :formulae
      option "d", "debug", desc: "open an interactive debugging session with access to IRB or a shell inside the temporary build directory."
      option "env", value: "std", desc: "use the standard build environment instead of superenv."
      option "ignore-dependencies", desc: "skip installing any dependencies of any kind. If they are not already present, the formula will probably fail to install."
      option "only-dependencies", desc: "install the dependencies with specified options but do not install the specified formula."
      mutually_exclusive_options "ignore-dependencies", "only-dependencies"
      option "cc", value: "compiler", desc: "attempt to compile using <compiler>. <compiler> should be the name of the compiler's executable, for instance `gcc-4.2` for Apple's GCC 4.2, or `gcc-4.9` for a Homebrew-provided GCC 4.9."
      option "s", "build-from-source", desc: "compile the specified formula from source even if a bottle is provided. Dependencies will still be installed from bottles if they are available."
      option "force-bottle", desc: "install from a bottle if it exists for the current or newest version of macOS, even if it would not normally be used for installation."
      option "devel", desc: "and <formula> defines it, install the development version."
      option "HEAD", desc: "and <formula> defines it, install the HEAD version, aka master, trunk, unstable."
      option "keep-tmp", desc: "the temporary files created during installation are not deleted."
      option "build-bottle", desc: "prepare the formula for eventual bottling during installation."
    end

To me, mutually_exclusive_options is kind of a long name for a DSL item. What do folks think about something like options_conflict

I still this we should avoid doing this in the DSL altogether. However, if it's okay with others, options_conflict or even just conflicts sounds good to me.

As a general comment, there's now a lot of code/changes in this PR and it's quite hard to review. I think it's worth thinking about how this can be split into smaller, independent PRs (which can build on each other) which will make this easier to review and merge. I'd like to see something small merged before the first evaluation period, if at all possible.

@raza15 I'd like to highlight this point as the first evaluation period is coming very close. Additionally, as also requested earlier: please verify brew style, brew tests and brew man are run and pass successfully before every commit you push and prioritise that over other work.

solving brew style

This is still failing, FYI.

 @description = nil

 @command_name = nil

 @help_output = nil

 @man_output = nil

These all default to nil

Hi @MikeMcQuaid, i think this is necessary because when running the test cases in spec file, when different commands are run, these variables need to be set to nil, otherwise they just have the value from the previous command (because they are class variables as opposed to instance variables)

when different commands are run, these variables need to be set to nil, otherwise they just have the value from the previous command (because they are class variables as opposed to instance variables)

This smells a bit like we aren't using classes in a sensible fashion and instead should initialise them as instances and have a e.g. .instance-style singleton/factory method.

@raza15 Can you fix brew style when pushing here, thanks!

Closing this in favor of smaller PRs


Problem with configuration multiple interface, only one is possible in "create container" section.

Problem is with configuration multiple interface, only one is possible in "create container" section.
Yoy have posibility to add multiple network interface, but only one is possible to configure when you edit container.

Ticket update by Bala Natarajan<EMAIL_ADDRESS>Hi
Assuming its swarm setup. if its swarm service, its possible to attach to
multiple networks. for an individual container, after creating container, it
can join an existing network. pl let us know if it helps


Maya: Fix look assigner showing no asset if 'not found' representations are present

Changelog Description
Fix Maya Look assigner failing to show any content if it finds an invalid container for which it can't find the asset in the current project. (This can happen when e.g. loading something from a library project).
There was logic already to avoid this but there was a bug where it used variable _id which did not exist and likely had to be asset_id.
I've fixed that and improved the logged message a bit, e.g.:
// Warning: openpype.hosts.maya.tools.mayalookassigner.commands : Id found on 22 nodes for which no asset is found database, skipping '641d78ec85c3c5b102e836b0'

Example not found representation in Loader:

The issue isn't necessarily related to NOT FOUND representations but in essence boils down to finding nodes with asset ids that do not exist in the current project which could very well just be local meshes in your scene.
Note:
I've excluded logging the nodes themselves because that tends to be a very long list of nodes. Only downside to removing that is that it's unclear which nodes are related to that id. If there are any ideas on how to still provide a concise informational message about that that'd be great so I could add it. Things I had considered:

Report the containers, issue here is that it's about asset ids on nodes which don't HAVE to be in containers - it could be local geometry
Report the namespaces, issue here is that it could be nodes without namespaces (plus potentially not about ALL nodes in a namespace)
Report the short names of the nodes; it's shorter and readable but still likely a lot of nodes.

@tokejepsen @LiborBatek any other ideas?
Testing notes:

Load something with invalid asset ids (not existing in current project)

e.g. load from another library project
or secretly change the cbId value on nodes changing the asset part of the id (which is the part BEFORE the : separator)

In Look Manager try to list the looks for all nodes (or selected nodes when having the faulty nodes selected)

Well prepared the testing scenario with unknown asset loaded in the workfile

And when in Look Assigner still all listed as would be normally without any unknown nodes present...

So all working fine...
P.S. I was in the middle of testing this PR while it already got merged, so enclosing these findings just as a prove all working good

Note:
I've excluded logging the nodes themselves because that tends to be a very long list of nodes. Only downside to removing that is that it's unclear which nodes are related to that id. If there are any ideas on how to still provide a concise informational message about that that'd be great so I could add it. Things I had considered:
1. Report the containers, issue here is that it's about asset ids on nodes which don't HAVE to be in containers - it could be local geometry

2. Report the namespaces, issue here is that it could be nodes without namespaces (plus potentially not about ALL nodes in a namespace)

3. Report the short names of the nodes; it's shorter and readable but still likely a lot of nodes.

I still wonder if we should do anything about this in a separate PR then.


Fix markdown to properly display metadata

https://docs.microsoft.com/en-us/powershell/azure/overview doesn't display metadata properly.

:warning: Validation status: warnings

File
Status
Preview URL
Details

azurermps-4.4.1/AzureRM.DataFactories/index.md
:warning:Warning

Details

azureps-cmdlets-docs/ResourceManager/docs-conceptual/overview.md
:white_check_mark:Succeeded

azurermps-4.4.1/AzureRM.DataFactories/index.md

[Warning] Failed to extract file creator information from git history.
[Warning] Uid(AzureRM.DataFactoryV2) has already been defined in azurermps-4.4.1/AzureRM.DataFactoryV2/index.md.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Agnostic crypto backend

I would like to use this library but not have to rely on sodiumoxide for key generation and signing.
My proposal is to put KeyPair behind a feature flag and keep it as a default feature.
Then create a Signer trait that can be implemented by a user of this library. KeyPair will implement this trait.
I have to fork and do this regardless, but if someone has an idea or desired implementation strategy, please let me know and I will follow that path so the changes can be merged upstream.

That sounds good to me. If you send a PR I will review it and update the crate.


chore(main): release 1.6.0

:robot: I have created a release beep boop
1.6.0 (2023-05-21)
Features

ghe support (#23) (60e128a)

Documentation

automated doc update (7567b6a)
cleanup badges (7fdc028)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/andrewthetechie/gha-repo-manager/releases/tag/v1.6.0 :sunflower: