Feat auth jwt plugin

Type:
The following has been addressed in the PR:
This PR is to at least generate a discussion about the possibility of making the apiJWTmiddleware auth overwriteable by Auth plugins. The logic behind why I'd find is useful is I can then tie directly into my token based authentication system and disable login/adduser from the npm registry itself. In my case when users signup & login on our existing system we'll put our token in the .npmrc then use that token in our plugin apiJWTmiddleware function to validate & create the user appropriately or return an error.

There is a related issue?
Unit or Functional tests are included in the PR

Description:

Interesting ...
could you give me some real usages examples?

So yeah it basically solves that exact issue. I had the same use case. We have an existing external API that uses bearer token auth where our users login/signup and we manage users & the orgs and packages they have access to over there so I needed a way to take a token from our existing system put it in the .npmrc and then use that to get the user and authenticate against our existing system to determine the packages they have access to. This proposal does not help with the generation of the token but rather we rely on our existing system/tooling/docs to help the user get a token into the .npmrc So for my Auth Plugin I've disabled login/adduser functionality. Here's an example of what my plugin utilizing this functionality looks like.
import fetch from 'node-fetch';
import createError, {HttpError} from 'http-errors';

import {
  NextFunction,
  Request,
  Response
} from "express";
import {Verdaccio} from "@verdaccio/types/lib/types";

export type ConfigExternalAuth = {
  auth: {
    externalAuth: {
      url: string,
      signupUrl: string
    }
  }
} & Verdaccio.Config;

export type RequestExtend = Request & {remote_user?: Verdaccio.RemoteUser}

export default class ExternalAuthPlugin {
  apiUrl: string;
  signupUrl: string;
  createAnonymousRemoteUser?: Function;
  createRemoteUser?: Function;
  logger: any;

  constructor(readonly config: ConfigExternalAuth, options: Verdaccio.PluginOptions<ConfigExternalAuth>){
    this.apiUrl = config.auth.externalAuth.url;
    this.signupUrl = config.auth.externalAuth.signupUrl;
    this.logger = config.logger;
    console.log(`Config: ${Object.keys(config)}`);
    console.log(`inners: ${Object.keys(config.packages)}`);
    console.log(`Stuff: ${Object.keys(options)}`);
  }

  authenticate(user: string, password: string, callback: Verdaccio.Callback) {
    // disable login
    callback(createError(405, `Signup/Login Not Implemented please use ${this.signupUrl} to signup`), false);
  }

  add_user(user: string, password: string, callback: Verdaccio.Callback) {
    // disable login
    callback(createError(405, `Signup/Login Not Implemented please use ${this.signupUrl} to signup`), false);
  }

  apiJWTmiddleware(helpers: any){
    this.createAnonymousRemoteUser = helpers.createAnonymousRemoteUser;
    this.createRemoteUser = helpers.createRemoteUser;
    return this.doExternalAuth.bind(this);
  }

  async doExternalAuth(req: RequestExtend, res: Response, _next: NextFunction) {
    if (!(this.createRemoteUser && this.createAnonymousRemoteUser)) {
      throw new Error('createRemoteUser or createAnonymousRemoteUser methods undefined');
    }
    req.pause();

    const next = function(err?: HttpError) {
      req.resume();
      if (err) {
        return _next(err);
      }
      return _next();
    };

    if (req.path.includes('login') || req.path.includes('user')) {
      this.logger.info('User Auth/Management not supported');
      const err = createError(403, 'User Auth/Management not supported');
      return next(err);
    }

    if (!req.headers.authorization || req.headers.authorization.toUpperCase().startsWith('BASIC')) {
      const err = createError(401, 'Invalid Authorization');
      return next(err);
    }

    try {
      const userResp = await fetch(
          `${this.apiUrl}/users/self`,
          {
            method: 'GET',
            headers: {
              'Content-Type': 'application/json',
              'Authorization': req.headers.authorization
            },
          }
      );
      if (userResp.status >= 500) {
        this.logger.error('Internal Server Error');
        const err = createError(500, 'Internal Server Error');
        return next(err);
      }

      const body = await userResp.json();
      if (userResp.status !== 200) {
        const err = createError(userResp.status, body.message);
        return next(err);
      }
      const user = body.data;
      this.logger.info(`User Auth Success ${user.username}`);
      req.remote_user = this.createRemoteUser(user.username, user._orgs);
      return next();

    } catch (e) {
      this.logger.error(`ERROR FETCHING: ${e.message}`);
      const err = createError(403, 'Not Authorized');
      return next(err);
    }
  }
}


Cleanup the documentation

Small cleanup of the documentation:

Split out the Contributing section in its own page
Link to the pyansys dev guide when applicable
Use links by index instead of inline

Merging this one fast to let Kathy time to then review the doc as a whole!


In leafmap package, make all "add" methods consistent in the arguments they accept

Description

Some methods (e.g., add_cog_layer) accept only a URL (The URL of the COG tile layer.)
Some methods (e.g., add_kml) accept only a local file path (The input file path to the KML.)
Some methods (e.g., add_geojson) accept a local file path, a URL, or a object (The file path or http URL to the input GeoJSON or a dictionary containing the geojson.)

It would be more ergonomic for users if all of these accepted either local path or URL.
I would recommend changing any method that accepts the object directly to have another method with a different clearer name instead of overloading the parameters, e.g., add_geojson_from_dict.
Related, some methods accept a parameter layer_name and some accept name, and it would be easier to use if all of them used a consistent name for all of the common parameters.
Source code
n/a

Good suggestions. I can make all add data functions accept both a local file path and HTTP URL. Regarding the add_geojson_from_dict function, the parameters will still be the same as add_geojson, I don't think it needs to be separate function in order to accept a dict input.
I agree that it makes sense to use consistent parameter names, maybe changing all layer_name to just name.
Pull request is welcome if you would like to contribute.

This is great, thanks so much. I think this will make it much easier for new (and existing) users to work with. Thanks!


include original props on when rendering decorated component

I'm not sure if the removal of the original props was an intentional design decision, but in case it wasn't: This small change "fixed" #6 for me so that I can now access actions passed as props from a container component.

Thanks. I had just fixed this locally a slightly different way.


Flutter iOS Unable to run exportArchive

I have followed the medium tutorial and fixed lot's of issues by myself although I got to this one:
Building App Store IPA...                                        2,157ms
Encountered error while creating the IPA:
error: exportArchive: Failed to log in.

If I run
flutter build ipa --export-options-plist=/Users/myUser/Documents/Developement/flutter_app/app/iOS/exportOptions.plist locally it is successfully generates the IPA file
More to that I ran locally the command below and it was successful:
xcodebuild -exportArchive -exportOptionsPlist --export-options-plist=/Users/myUser/Documents/Developement/flutter_app/app/iOS/exportOptions.plist -archivePath '/Users/myUser/Library/Developer/Xcode/Archives/2024-02-09/FlutterApp 2024-02-09 13.18.02.xcarchive' -exportPath /Users/myUser/Desktop

Thing is I didn't see any step where I have to provide some login info for an Apple ID. Any ideas how to make flutter build ipa --export-options-plist=etc pass on Azure Devops?

As you can see the error is Failed to log in.. You will have to create a service connection on your project. Go to your settings and add a service connection of Apple ID and then it should work. Also go through the links below

https://github.com/hey24sheep/azure-flutter-tasks/issues/49#issuecomment-1309118882
https://github.com/hey24sheep/azure-flutter-tasks/wiki (please go through all the IOS links, you will find a solution)

Check this issue as well if your issue isn't solved yet https://github.com/hey24sheep/azure-flutter-tasks/issues/119


空安全里面有警告，代码写的不严谨

Pub/Cache/hosted/pub.flutter-io.cn/flutter_datetime_picker-1.5.1/lib/flutter_datetime_picker.dart:311:32: Warning: Operand of null-aware operation '??' has type 'Color' which excludes null.
 - 'Color' is from 'dart:ui'.
                  color: theme.backgroundColor ?? Colors.white,

/C:/SDK/FlutterSDK/flutter_windows_2.10.0-stable/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_datetime_picker-1.5.1/lib/flutter_datetime_picker.dart:311:32: Warning: Operand of null-aware operation '??' has type 'Color' which excludes null.

'Color' is from 'dart:ui'.
color: theme.backgroundColor ?? Colors.white,

你好，你用的这个插件，有发现会不停的闪烁的问题吗？https://github.com/Realank/flutter_datetime_picker/issues/340


data can be corrupted by wslgit assuming everything is utf-8

WSLgit is forcing a conversion of data from git (diffs, key/values, files, status, binary, ...everything) from unknown encodings into UTF-8. This can result in corruption of data.
As per GIT documentation:

Git at the core level treats path names simply as sequences of non-NUL bytes, there are no path name encoding conversions.
Commit log messages are typically encoded in UTF-8, but other extended ASCII encodings and codepages are also supported. This includes ISO-8859-x, CP125x and many others, but not UTF-16/32, EBCDIC and CJK multi-byte encodings (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).
Repositories created on such [non UTF-8] systems will not work properly on UTF-8-based systems (e.g. Linux, Mac, Windows) and vice versa.
Line endings can be LF, CRLF, or any native system line ending. Line endings can change per-file or be across an entire repository.

Today with WSLgit v0.50, data that is not UTF-8 is already being corrupted by WSLgit. Several charsets like ASCII, Windows-1251, and ISO-8859-1 have the same bytes encoding for commonly use characters. When WSL, git settings, and the user's Windows character set are within this limited set of charsets, it is likely they do not experience corruption. This is the often seen scenario where almost all the characters are ok except for the occassional ü or Ó doesn't look correct.
This leads me to some recommendations:

I do not recommend WSLgit have comprehensive character-set support. Why? Because git itself has some limitations as written above. And, WSLgit is not a tool that needs to solve all problems.
One of these problems to not fix is line endings. Line endings are not just LF and CRLF. However, since Git has some limitations on this and we don't have to solve all problems... I recommend only supporting LF and CRLF. References: https://en.wikipedia.org/wiki/Newline and https://docs.microsoft.com/en-us/visualstudio/ide/encodings-and-line-breaks
Do not use conversion or validation APIs like from_utf8_lossy() or from_utf8(). These APIs will corrupt data that is not valid UTF-8. Instead, transparently accept all data with APIs like from_utf8_unchecked() or leave them in byte buffers.  This is ok. Why? Because there are two cases today:

UTF-8 data -- this data works today and will continue to work with the unchecked APIs because it is already valid UTF-8. A side benefit is the unchecked APIs will be faster because it doesn't need to validate anything since the data is already valid UTF-8.
not UTF-8 data -- this data is already being corrupted today. Therefore, it can only get better. By using the unchecked APIs, it is possible for the data to still be workable/usable. All of this data is just bits in groups of bytes. The bytes should not change. For commands like git show this is essential -- the data must not be altered in any way. For commands like git rev-parse the data might still work since the byte values can be transparently passed-through and as they are captured by tools like VS Code, they may correctly use the user's alternate character set since the bytes were transparently passed to them. Yes, there might be a problem if the data uses a path with non UTF-8 data in it and one or more of the /\:mnt characters have a different byte encoding. However, this is no worse than today's already corruption of that same data. And it might be better if those 6 characters are encoded with the same bytes because the other characters may be transparently passed-through.

I have code which uses the above recommendations at https://github.com/diablodale/wslgit/tree/charset_trans

Good points and nice summary, thank you.
I completely agree that wslgit should not try to solve all problems. I would like to see it stay an as-thin-as-possible wrapper for git.
Your approach using the unchecked conversion does indeed improve on the current situation and is possibly the easiest solution right now.
Going forward it might be worthwhile to evaluate whether wslgit could only process raw bytes (instead of trying to encode them to a string). This does not solve the encoding problem for file system paths, but the conversion could maybe be offloaded to specific tools like wslpath, as discussed in #12 .

Got it. Raw bytes/buffers would likely work well except for the need to translate paths; the most important thing. 😉

Well, yes, but have you actually encountered a problem with file system encodings? I ask, because using wslgit with files and folders containing german umlauts like äöüß seems to work fine for me.
As a short test, I created a new git repository containing a subdirectory with a file called äöüß€/ßüöä.txt. Running git status with both Git for Windows and wslgit returns the same output:
[...]
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        "\303\244\303\266\303\274\303\237\342\202\254/"
[...]

While the directory in the output of git is unreadable, this is not the fault auf wslgit, as it is the same using Git for Windows.
Commands like wslgit.exe add äöüß€ also work fine, resulting in the following git status output:
[...]
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   "\303\244\303\266\303\274\303\237\342\202\254/\303\237\303\274\303\266\303\244.txt"

And it doesn't seem to matter if the files are created by Windows (with English language settings) or inside WSL. VSCode also shows the correct status for the file.
Do you have a testcase showing an actual problem?

Oy, that was a rabbithole 🐇  In short, I think assuming UTF-8 for paths is ok for the majority of cases; falling into the "don't have to solve everything" bucket.
Two types of data streams from GIT:

raw "file" data - Should have no translation, no utf-8 anything, no line splitting. This is commands like show. I believe we agree this should be raw byte output. I already have that fix above.
diffs, paths, key/values, etc. - This is the data which needs to be parsed for paths. Commands like rev-parse. This is our inquiry now.

You might have read something into my 😉 comment above that I didn't intend. Yet, to clarify/confirm I went down the research rabbithole...
If a user keeps the default GIT config, then the behavior of git is to quote and escape any characters 0x80 or above when outputting paths.

core.quotepath The commands that output paths (e.g. ls-files, diff), when not given the -z option, will quote "unusual" characters in the pathname by enclosing the pathname in a double-quote pair and with backslashes the same way strings in C source code are quoted. If this variable is set to false, the bytes higher than 0x80 are not quoted but output as verbatim. Note that double quote, backslash and control characters are always quoted without -z regardless of the setting of this variable.

Characters 0x7F and under are ASCII and overwhelming the same across all character sets and languages.
And, the first 128 Unicode code points are the ASCII characters, which means that any ASCII text is also a UTF-8 text.
This means that when GIT within WSL outputs paths, the bytes sent from GIT->WSL->Win32->WSLgit will always be 0x7F or less. They will always be ASCII. They will always be valid UTF-8. The interpretation of those escape sequences are the responsibility of things outside of WSLgit. So for these path cases and the default GIT config... paths are happily being passed transparently. :-)
If the user sets core.quotepath to false or uses the -z parameter on commands that generate paths, this all unravels and becomes the character set compatibility issue I was describing. I suggest/agree we should put this into the "don't solve everything" bucket.
That leaves the cases of non-path data on commands that are not show. This is diffs, config key/values, commit, add, ...the majority of commands. For all these commands, if the user has incompatible character sets in the GIT repo, WSL "lang" setting, and/or Windows itself, then characters above 0x80 may be corrupt when sending characters to WSLgit and which are not parseable by the Rust String libraries.
This latter case is my recommendation 3.ii where this data is already being corrupted today by the lossy api. That it might work transparently with the non-lossy api depending on how the Rust libraries implement their utf-8 parsing.
I don't have the resources to setup a separate machine with a distinctly different character set. In its place, I was able to config my WSL install to be de_DE.ISO-8859-1. This exposed problems with characters being corrupt when not paths. For example, VS Code issued the following command and you can see how the ü was corrupted to become a diamond with a question mark.
git rev-parse --symbolic-full-name --abbrev-ref truncate_28@{u}
fatal: Kein Upstream-Branch f�r Branch 'truncate_28' konfiguriert.

Also in that same repo case, I got two different behaviors when WSLgit was run from the command prompt instead of within VS Code.  Some code I haven't pushed to github panicked with the error failed printing to stderr: text was not valid unicode. I'll need to explore this error, how it relates to the ü, and if a switch to raw buffers and .write_all() is needed.
Tech details
The current path translation code needs to detect the /\:mnt characters in a very specific sequence. And use lines(). And use Rust String indexing. And that indexing is on UTF-8 characters not on bytes. All of those with Rust Strings are assuming UTF-8 and the Rust documentation cautions if operations are done on Strings containing non-UTF-8 data. That's why the lossy API exists to try and scan/resync/toss data that isn't UTF-8 digestable.
An example of different encodings for a very common character is the character for the euro €.
Windows-1252:  \x80
Unicode:  \x20\xAC
UTF-8:  \xE2\x82\xAC
Or the Œ character used by many languages when representing diphthongal sounds.
Windows-1252:  \x8C
Unicode:  \x0152
UTF-8:  \xC5\x92
Or large bytecode differences with the very common e-grave  è  or french Œ.
Here are some links that write about misinterpreting or processing various charsets between Windows-1252, ISO-8859-1, Unicode, and UTF-8. There are many cases when the byte values and the number of bytes which represent a character significantly differ.
http://www.i18nqa.com/debug/bug-iso8859-1-vs-windows-1252.html
http://www.i18nqa.com/debug/utf8-debug.html
http://www.i18nqa.com/debug/table-iso8859-1-vs-windows-1252.html#compare

Ah, yes, I misinterpreted your last post. Thanks for your research and sorry for sending you down this rabbithole. At least we confirmed that paths should not be a problem in the default configuration.
For the remaining issue, I completely agree. Your proposed change is probably a worthwhile improvement, even if it does not fix the issue completely. I plan to merge your change when I find some time.
Maybe we should also identify more commands that do not need any path translation, like show. For example, diff should not need path translation, as it outputs only relative paths, which are currently not translated. Even further, I feel like there might be actually only a few commands that need path translation, like git rev-parse --show-toplevel (but I haven't checked). So maybe the logic should switch to a whitelist of commands that need path translation, instead of a blacklist of commands that are not translated. Then, for all untranslated commands, the output is passed through as-is.

No worries.
I reached a dead end. ⛔ Rust 100% demands UTF-8 with stdin, stdout, and stderr. In their core library for stdio, is the forced validation of UTF-8 and, afterwards, the blind translation of UTF-8 -> UTF-16 for a call to the Win32 API WriteConsoleW. Similar code for stdin and stderr.
https://github.com/rust-lang/rust/blob/f1ea23e2cc72cafad1dc25a06c09ec2de8e323eb/src/libstd/sys/windows/stdio.rs#L73
This is a Rust core limitation/requirement, depending on perspective. In my opinion, this is a toolset issue and not a WSLgit issue. Moving it into the "don't solve everything" bucket.
Unfortunately, this causes a significant problem. 🙈 Files with non-UTF-8 content will be corrupted as I predicted. I finally got a repro case that is easy to reproduce. This corruption will occur with your official v0.5.0 (corrupts) or my charset_trans branch (panics and crashes).
Repro

Have WSLgit v0.5.0 installed and working
Have the Windows version of Git installed and working. I will write Wingit below to distinguish this from WSLgit.
Wingit init a fresh repro in an empty directory
Save the attached image (any image will do) into that directory
Wingit add the image
Wingit commit
Wingit ls-tree -l HEAD -- circle.png
Copy the blob id; it is in the 3rd column.
Wingit show blob id
Visually note the appearance of the raw picture data
WSLgit show blob id

Result
The data is different. This is due to from_utf8_lossy() corrupting the bytes of data by tossing away anything that doesn't appear to be UTF-8. This is raw binary data but this Rust API doesn't care.
If you compile the code from my recent charset_trans branch, it is no better. It will panic due to the Rust core library issue I write at the top of this post.
You can further see problem by configuring VS Code to use WSLgit. With the repo you made above, edit the picture and make a visual change. Save it. Then in VS Code, in the Source Control icon, click on the picture. It should show a visual diff of the two images. Unfortunately, it won't. The left will show some kind of error (because WSLgit corrupted the data) and the right will show your edited picture (VS Code reads it directly from the current file). If you reconfigure VS Code to use Wingit, this diff will work ok.
This binary example is easiest to setup. Yet, I can also create it by making a carefully crafted text file in an character set other than UTF-8.
Expected
Identical output from Wingit and WSLgit. No corruption or loss of data.
Workaround
This is a core Rust cough requirement that leads to corruption. 🙁 Using the core Rust functionality, there is no workaround.
In the Rust library code I referenced above, we may be able to create a private version of read/write to stdin/out/err which better handles content. A brief look at the below suggests to me that the Rust team isn't appropriately handling redirection of stdin/out/err by assuming it is always to a console.
https://docs.microsoft.com/en-us/windows/console/writeconsole
https://docs.microsoft.com/en-us/windows/console/setstdhandle
https://msdn.microsoft.com/library/windows/desktop/ms682499
I also noticed a few bugs in this same Rust library with the label // FIXME which are about buffers. Makes me wonder if this is the buffering truncation problem I see on my computer.

I might have some progress on a workaround by using raw handles with the module std::os::windows::io::AsRawHandle. Prelim testing worked. Stay tuned... 😵

Maybe the simpler/more pragmatic solution is to just exclude commands like these from path translation (and pass trough their output unchanged). Because, if these commands output user data (i.e. the contents of a file), we don't actually want to change any paths there.
Also, as noted above, I suspect that there is actually only a small subset of commands that actually need path translation. So maybe we should just identify and whitelist them, and do not alter the output of any other commands.

OK. new code at https://github.com/diablodale/wslgit/tree/charset_trans is working so far in my tests. Still needs some refactoring. Feedback is appreciated.
Quick tests using my circle.png repo from the repro case above.

wslgit show HEAD:circle.png doesn't crash or panic
wslgit show HEAD:circle.png > stdout.txt 2> stderr.txt works. And stdout.txt is a binary exact copy of the original circle.png.
wslgit rev-parse --show-toplevel works and returns expected value
wslgit ls-tree -l HEAD -- works and returns expected value
I am able to use this wslgit in VS Code. Opening the windows for git output, I can see all the operations working with no errors.
Doing the repo steps a few posts ago with the circle.png and the visual diff now works.

Great, thanks.
However, I found a simpler way to pass through stdout of the subprocess, without unsafe code and raw file handles. As wslgit does not need the output in this case, it just doesn't capture it. Instead, it lets the subprocess inherit stdout, so it writes directly to the stdout of wslgit, see this commit 6b32eae5dcada5ed5ea0e73b3b3f249d5cc099a0.
In my quick test this fixes untranslated commands (i.e. currently only show) with binary files like your image. Viewing the diff of a changed image in VSCode also works. Could you also test my version?
I may still take a closer look on the binary handling of the translation.

Haha, yes. Cleaner to not get involved. ;-)
I merged this approach into my branch and it is transparently passing all data with show as expected. Hurrah! We have slightly different codebases as I'm returning forward slashes to be compatible with GIT standard (see https://github.com/Microsoft/vscode/issues/41636 as likely cause of your https://github.com/andy-5/wslgit/issues/11) and using RegEx's as I enjoy them and that approach may be flexible for future use.
I already process data as binary in my branch. I do it with the RegEx. What we receive in the Output struct will be UTF-8. And the stdout()::write() or println style APIs demand UTF-8. My original concerns of handling non-UTF-8 data (non english charsets, etc.) are no longer valid after my research into the core libraries. UTF-8 is omnipresent. You can see here https://github.com/rust-lang/rust/blob/f1ea23e2cc72cafad1dc25a06c09ec2de8e323eb/src/libstd/sys/windows/process.rs#L165 that when the child process is created, Rust instructs Windows to do it in Unicode (Windows uses UTF-16). While I haven't found the exact code in the core libraries that does the conversion of UTF-16 -> UTF-8 data via a pipe into the Output struct, I'm 90% sure based on the Rust library's approach and actual usage/examples that the vec given to us in output.stdout is always UTF-8 data.
What is possible with binary process is a change in performance. Profiling would be needed to truly measure increase/decrease. I was always concerned with the lines() approach as, without digging into the libraries, it might be creating new Strings for every line rather than just an iterator pointing to the existing data in the original vec. If the output was large (like with show) this could create hundreds of thousands of strings - one for each line. :-/
Taking the binary approach and disabling the utf-8 parser in the RegEx, I should be minimizing new creation of objects; instead borrowing/using slices. At least one new vec is created as the loop appends on translated paths. It may be possible to alternatively parse the vec and immediately write segments to stdout rather than queuing it into a single vec. I have not explored that idea at this time.
I also tested for the truncation bug https://github.com/andy-5/wslgit/issues/28. Good news which I'll write over in that issue.


Enable integration tests within CI

The integration tests are currently disabled within the CircleCI build, as they rely on running up a Docker container.
This doesn't seem to work with the current CircleCI configuration.

914735bfc2a5c22e15746d63dd68460fc599caaf addresses this, but we won't be able to close this until #5 is resolved.

There doesn't seem to be an easy way to do this and I am, for now, giving up.
The problem is that while you can run up Docker containers within the CircleCI build environment, those containers are not allowed to bind to a network port within the build environment. So the tests cannot communicate with the Docker container.

Reopening this to investigate the possibility of running the integration tests using GitHub Actions.


Change name of stdlib

stdlib.h seems to be an important file and name aliasing is possible

Should be fixed by #144


develop <- master

Merge PR to develop along with master branch push for article publication. Created by this action: https://github.com/falgon/roki-web-post/actions/runs/3573324109

Build log
Preview build with this PR (commit): https://output.circle-artifacts.com/output/job/b1f86257-2ef4-4e8e-885c-475cc92e11f4/artifacts/0/index.html


Manifest update in Foundry does not update this module

Hello,
When I update this module in Foundry and accept the new manifest (1.85->1.95) nothing is updated.
I'm on Foundry 12.311.

Second this ... using both the automated in Foundry as well as the manual point to the 1.95 ... both claim install complete (even when a fresh install) but it only installs the old v1.85. Manifest pointing to wrong version?

yar, even manually installing from the .json in the 1.95 release installs 1.85

It looks like 1.85 and 1.95 are both pointing to the same SHA

There have been no commits since 1.85.
But also, the manifest link inside module.json should point to "latest" rather than a specific version. (The download link should remain a specific version.)

Yes the 1.95 zip file is the same of 1.85 zip file. So the modules insides are the 1.85, just the outside manifest that was declared as 1.95 (but when foundry unzips the module.zip it uses the 1.85 manifest too).

Finally, fixed with 1.96 - I hope.


[Backport 2.x] Add throw for empty strings in rules with modifier contains, startwith, and endswith (#860)

Manual backport of #860 to 2.x

Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

can we check Security test workflow failures?

can we check Security test workflow failures?

Security test workflows have been failing in previous PRs, will need to create a separate PR to fix it.


Force sequential building for some ports.

Most ports i want to build in parallel , like python ports.
There are 3 ports i want to build serial, ie one at a time , namely : "electron,chromium,iridium".
[This because these 3 ports make my system go swapping ]

#87 covers this. It will be in the next poudriere-devel update and next release. I have just been adding more tests for unrelated changes.


Possible issue with drawing cerrain wall glyph combinations

See original repo issue:

https://github.com/amethyst/bracket-lib/issues/350

Closing, as the issue was that the wall glyphs in question weren't in Codepage 437.


[VTK] build failure

Host Environment

OS: Windows 10
Compiler: VS2019 16.4.1

To Reproduce
Steps to reproduce the behavior:
./vcpkg install vtk
Failure logs
Call stack in powershell:
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
    Command failed: ninja -v
    Working Directory: D:/libraries/vcpkg/buildtrees/vtk/x64-windows-rel/vcpkg-parallel-configure
    Error code: 1
    See logs for more information:
      D:\libraries\vcpkg\buildtrees\vtk\config-x64-windows-out.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_configure_cmake.cmake:293 (vcpkg_execute_required_process)
  ports/vtk/portfile.cmake:91 (vcpkg_configure_cmake)
  scripts/ports.cmake:94 (include)

Callstack in cmake output:
CMake Error at D:/libraries/vcpkg/scripts/buildsystems/vcpkg.cmake:263 (_find_package):
  Could not find a configuration file for package "PROJ4" that is compatible
  with requested version "6".

  The following configuration files were considered but not accepted:

    D:/libraries/vcpkg/installed/x64-windows/share/proj4/proj4-config.cmake, version: 6.2.0 (_MSC_VER = 1923)

Call Stack (most recent call first):
  CMake/FindLibPROJ.cmake:8 (find_package)
  D:/libraries/vcpkg/scripts/buildsystems/vcpkg.cmake:263 (_find_package)
  CMake/vtkModuleMacros.cmake:891 (find_package)
  ThirdParty/libproj/CMakeLists.txt:1 (vtk_module_third_party)

-- Configuring incomplete, errors occurred!

Additional context
It seems to have found Proj4 version 6.20 (_MSC_VER = 1923), but it isn't accepted as the log says.

Hi @larshg, thanks for reporting this issue!
Can you modify SOURCE_PATH/CMake/FindLibPROJ.cmake line 8 to:
find_package(PROJ4 CONFIG REQUIRED)
and try again?
Thanks.

Hi @JackBoosY
I tried with both empty and 6.2.0, but the error message is the same (except the version matches what I request, ie "" or "6.2.0".

@larshg Sorry to hear that, could you provide output again?
Thanks.

Here is the config output: config-x64-windows-out.log

@larshg Sorry for late.
Could you add VERSION CONFIG to SOURCE_PATH/Thirdparty/libproj/CMakeLists.txt line 3 and try again?
Thanks.

Hi @JackBoosY
Np. its hollidays time I guess :)
When I add VERSION CONFIG it shows the following:
CMake Error at D:/libraries/vcpkg/scripts/buildsystems/vcpkg.cmake:263 (_find_package):
  Could not find a package configuration file provided by "LibPROJ" with any
  of the following names:

    LibPROJConfig.cmake
    libproj-config.cmake

  Add the installation prefix of "LibPROJ" to CMAKE_PREFIX_PATH or set
  "LibPROJ_DIR" to a directory containing one of the above files.  If
  "LibPROJ" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  CMake/vtkModuleMacros.cmake:891 (find_package)
  ThirdParty/libproj/CMakeLists.txt:1 (vtk_module_third_party)

I then tried to rename it to PROJ4 - but then it shows this again:
CMake Error at D:/libraries/vcpkg/scripts/buildsystems/vcpkg.cmake:263 (_find_package):
  Could not find a configuration file for package "PROJ4" that is compatible
  with requested version "".

  The following configuration files were considered but not accepted:

    D:/libraries/vcpkg/installed/x64-windows/share/proj4/proj4-config.cmake, version: 6.2.0 (_MSC_VER = 1923)

Call Stack (most recent call first):
  CMake/vtkModuleMacros.cmake:891 (find_package)
  ThirdParty/libproj/CMakeLists.txt:1 (vtk_module_third_party)

This is quite weird, but I can repro it now. I think this is due to the wrong config.cmake / target.cmake exported by proj4.
Please remove VCPKG_PATH/buildtrees/vtk/src/, build vtk and terminate the build process after decompressing the source code, then replace VCPKG_PATH/buildtrees/vtk/src/v8.2.0-***/CMake/FindLibPROJ.cmake with this. Then rebuild vtk.
If it works, I will open a PR to fix it.
Thanks.

@JackBoosY it doesn't seem to do anything. It still reports the same error.

@larshg Could you provide proj cmake files in D:/libraries/vcpkg/installed/x64-windows/share./proj4/ ?
After remove version number, this shouldn't happened.

Hi @JackBoosY Here are all the .cmake files.
proj4.zip
However, since the MSVC_VER 1923 keeps popping up, I looked it up here MSVC Versions.
Where 1923 is VS 16.3.x (which was what Proj4 was build with) - and I currently have VS 16.4.x installed - which apparently was the "error".
I removed PROJ4 and reinstalled it and now its currently building VTK.
Any reason, the PROJ4 is so restrictive on the VS version used?

@larshg  Sorry for late, I'm dealing with other issues.
In proj4-config-version.cmake line 27:
elseif (MSVC AND NOT MSVC_VERSION STREQUAL "1923")
  # Reject if there's a mismatch in MSVC compiler versions
  set (REASON "_MSC_VER = 1923")
  set (PACKAGE_VERSION_UNSUITABLE TRUE)

The proj4 cmake file automatically generates "1923". And it should be the same as "MSVC_VERSION" in VTK.
But in the configuration log you provided:
-- The C compiler identification is MSVC 19.24.28314.0
-- The CXX compiler identification is MSVC 19.24.28314.0

So I guess you are built curl before Visual Studio update, and building vtk after Visual Studio update, is that right?
Please rebuild(remove + build) curl, then try to build vtk.
Thanks.

Well its working now?!
I had to rebuild Proj4 - which I did after I have updated Visual studio. So I guess I'll just close this issue, as its designed to be restrictive to compiler has been used.

@larshg I think I should fix this issue.
Please keep this issue open until I fix it.
Thanks.


I hope you can provide nuxt3 support.

I like this project very much, it is a beautiful component library, I hope you can provide nuxt3 support.

@qinfeo What does not work in nuxt? This library should be easy to install as any other standard vue app , so in theory it should work just out-of-the-box with nuxt :p but im gonna try it out soon.

Please checkout : https://vanilla-components.com/guide/integrations-nuxt.html

I did set up this on nuxt with no problem @qinfeo, just add it to the Vue app on nuxt as a normal vue extension

Closing for Inactivity, let me know if you still have issues! Cheers and thanks <3


Desktop, contextual menu, Terminal: does not launch a terminal application

First use of my PC-BSD PersonaCrypt home directory with TrueOS Desktop.
With the contextual menu, I made two or three attempts to use Terminal.
The white cursor bears an apparently endless asynchronous progress indicator.
On closer inspection, Default Applications has nothing alongside Virtual Terminal.

This looks like your default terminal setting did not transition properly from PC-BSD to TrueOS (if no default is set, it is supposed to use xterm, but TrueOS does not install xterm out-of-box). The newer defaults for Lumina on PC-BSD/TrueOS ensure that the default terminal setting is properly set (pointing to qterminal for TrueOS), so I think we can close this.


README.md 中硬件品牌拼写错误

README.md文件的Hardware Connection Overview图中，GPS Receiver品牌名称拼写为“Novotel”错误，应为「NovAtel」

Hi @LE2031 , we have made the change according to your advice. We will close the issue for now. If you have any additional questions, please feel free to open a new issue. Our engineer team is more than happy to help with that.
Thank you for supporting Apollo!


Swarm API, Cannot create a service with secret

Hello,
I have a service with secret parameters and i cannot create it using docker swarm API
Can you expose secret params into docker swarm API (POST /services/create)?
Thanks

Could you provide some more information?

output of docker version
output of docker info
exact steps to reproduce (e.g. the API request you're making)

Please keep in mind that the GitHub issue tracker is not intended as a general support forum,
but for reporting bugs and feature requests. For other type of questions, consider using one of;

https://forums.docker.com
the Docker community Slack channel
StackOverflow

Hello i have 17.03.0-ce docker version.
However you can check my issue using your eyes. Into this page
https://docs.docker.com/engine/api/v1.27/#operation/SecretCreate
isn't any information regard secrets
can you help me?

I'm not sure I understand the question; what information are you missing?

@thaJeztah i am sorry but i had copy a wrong link. Sorry, look at this link: https://docs.docker.com/engine/api/v1.27/#operation/ServiceCreate

Hello, There are any news?

@Fabryprog there is a Secret "information" in the ServiceCreate Section, under TaskTemplate > ContainerSpec :ang

Finally!
When i open this issue there aren't!
Tnkx


docs: remove "1.0-SNAPSHOT" keyword in all OpenAI links

I removed snapshop link in OpenAI TTS link.
- before TTS link: https://docs.spring.io/spring-ai/reference/1.0-SNAPSHOT/api/audio/speech/openai-speech.html
- after TTS link: https://docs.spring.io/spring-ai/reference/api/audio/speech/openai-speech.html
Additionally, I discovered that other links were also incorrect due to the "1.0-SNAPSHOT" keyword, so I removed the "1.0-SNAPSHOT" term from all the links.
close #1574
Before

After

Thanks


add support for metrics-endpoint provider

Issue
The Mimir charm is currently missing the metrics-endpoint provider which would allow it to be scraped by Prometheus.
Solution
Implement the relation provider in Mimir.
Testing Instructions
Deploy Mimir and Prometheus, relate them over the new interface and verify that Prometheus receives the metrics correctly.

Can we just drop it entirely? Wait 10 min :D

I'm currently putting the recording-rules.yaml file in the prometheus_alert_folder; that file will need to be moved in the appropriate folder after https://github.com/canonical/prometheus-k8s-operator/issues/428 is resolved.


GL context

For glium and glium_sdl2 — shameless plug :) —, it's required to check if an OpenGL context is the current one in the thread. Using context == gl_get_current_context() doesn't work because the owned fields would always be different.
I removed gl_get_current_context() to guarantee unique OpenGL context objects that always get deleted, but its functionality lives on in GLContext::is_current() and Window::gl_set_context_to_current().

Sure :)


Why is it necessary to import react ???

Why when creating the SVG components is it necessary to include
import * as React from 'react' in the generated code ???
What purpose does this serve ???

It is the way React worked. https://react-svgr.com/docs/options/#jsx-runtime

Thanks.
I actually worked that out while building an icons library. If import React from 'react' isn't present my rollup code splitting decides to add one anyway but with but as React$ for some reason.
Anyway, all fixed now so thank you for taking the time to answer


Old workshop link goes nowhere when ending with #

Broken Link
https://substrate.dev/substrate-contracts-workshop/#/
Expected Location
https://docs.substrate.io/tutorials/v3/ink-workshop/pt1/
Context and Origin
I suppose it was a hash router before and some websites still link to the full URL. The new router can't handle hashes.
Got it from here https://morioh.com/p/0e444b63ab48, but it might be more wide spread.

This redirects just fine for me. Please check behavior again

this is what I still see using google chrome


Shopping Frontend Page

ui-workshop-tailwind

Sure go ahead

hello, can you please assign me this issue.

No @siddhesh-coder


Change CI to Cirrus CI

The goal of this PR is to change the CI to be faster, easier to configure, and just plain more simple without losing functionality.

Agree with what Caleb wrote, though just wanted to  add that we really care about making the experience of contributing to Shields a fun one!
If you're interested in working on that, some good places to start would be the discussion threads for the open issues tagged developer-experience or documentation! And if you've new tooling ideas to propose, it's always good to start with a discussion!

I'm also curious as to what the benefits are of Cirrus over something like Azure Pipelines or GitHub Actions?


Can't view orders in back-end

Magento EE v<IP_ADDRESS>, PHP 7
Hi we have the PHP7 Inchoo extension installed, and when we click to view a customer's orders in the back-end we get the following error.
We have contacted Magento support, but because the error references 'Inchoo_PHP7_Model_Layout', they are just telling us to uninstall the plugin and downgrade to PHP5.6 :-/
Can anyone offer any advice or a possible fix?
Thank you!
"
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'main_table.entity_id' in 'field list', query was: SELECT COUNT() FROM (SELECT main_table.entity_id, main_table.increment_id, main_table.customer_id, main_table.created_at, main_table.grand_total, main_table.order_currency_code, main_table.store_id, main_table.billing_name, main_table.shipping_name, shell_request.   Disable the extension, and when the error happens again, send them the new stack trace, without Inchoo_PHP7 in it...

What on earth is "shell_request" in that SQL query?....
I can't find any reference at all to "shell_request" anywhere in CE <IP_ADDRESS>.  Is that something specific to EE?
The term "shell_request" is ringing all kinds of alarm bells for me...

No idea what "shell_request" is, sorry :)
But if we disable the Inchoo plugin, we still get the same error.
I am just manually removing all the Inchoo files instead of just disabling and will re-test.
Thank you for your replies, guys!

@durzel, you are a god! Pointing out "shell_request" as being suspicious  led me right to the culprit. It was an extension we had which enabled various "tweaks" in the back-end. One of which was providing more details in the order management.
Thank you very much for your input :)
Best Regards,
Elliot


Server status watchers

PingWatcher
Sends ICMP echo request to specified host. Supports bunch of connection-fail reasons.
Based on PortWatcher.

Thanks for another nice feature! I will check this out soon :).


Datashape type string and Impala

Datashape type string is always converted to SQL types TEXT and VARCHAR, which are not provided by Impala, but only STRING.
For a simple example I derived the following snippet from
https://github.com/mrocklin/blaze-scipy-2014/blob/master/01-computation.ipynb
cities_list = [(1, 'NYC'),
               (1, 'Boston'),
               (2, 'LA'),
               (3, 'Beijing'),
               (3, 'Shanghai'),
               (4, 'Moscow'),
               (5, 'Paris'),
               (5, 'Berlin')]

cities_schema = "{id: ?int, city: ?string}"

into(SQL('impala://...', 'cities', schema=cities_schema), cities_list)

Execution results in
DBAPIError: (HiveServer2Error) AnalysisException: Syntax error in line 4:
	city TEXT
      ^
Encountered: IDENTIFIER
Expected: BIGINT, BINARY, BOOLEAN, CHAR, DATE, DATETIME, DECIMAL, REAL, FLOAT, INTEGER, SMALLINT, STRING, TIMESTAMP, TINYINT

Workaround by fixing length ("{id: ?int, city: ?string[50]}") doesn't work because VARCHAR is also not supported.
I guess, dshape_to_alchemy() needs a bit more differentiation based on the SQL dialect.
As an alternative I implemented the following workarkound in impyla's impala.sqlalchemy.
from sqlalchemy.ext.compiler import compiles
from sqlalchemy.types import Text

@compiles(Text, "impala")
def compile_text_impala(type_, compiler, **kw):
    return "STRING"

It works, but I'm not sure it's the right way to do it. If at all, Impala (i.e. the server) could allow TEXT and VARCHAR as aliases, but Impyla should probably not auto-adapt.
CC @laserson

I think this should be pushed to impyla and sqlalchemy's type compiler rather than increasing the complexity of dshape_to_alchemy. @fkaufer did you submit your fix upstream to impyla?

PyHive is an example of a SQLAlchemy dialect which does this:
https://github.com/dropbox/PyHive/blob/master/pyhive/sqlalchemy_hive.py#L126-L158

did you submit your fix upstream to impyla?

No, because I think it's controversial and personally I thought black magic stuff (abstractions, automatic conversions etc) is rather a job for blaze/odo whereas a database client interface should be close to the system's SQL datatypes and only provide a basic level of abstraction. When you use a database client directly you might want to know about missing/incompatible types and potentially related issues, when you use odo you expect things to work and don't want to deal with idiosyncratic data type issues.
But admittedly, you can also argue in favor of the PyHive solution.

@fkaufer

No, because I think it's controversial

What's controversial? The fix?

... whereas a database client interface should be close to the system's SQL datatypes and only provide a basic level of abstraction

One of the goals of SQLAlchemy (as I understand it) is to abstract away the idiosyncrasies of all the different RDMBSs. It has explicit mechanisms for doing such things on a per dialect basis.

When you use a database client directly you might want to know about missing/incompatible types and potentially related issues, when you use odo you expect things to work and don't want to deal with idiosyncratic data type issues

I guess we're of two minds here. I think that sqlalchemy should "just work" in this case (and it usually does). I personally don't care that certain types like varchar or char are incompatible with impala. With those types, I usually just want a string column. If I cared about faithfully representing those types in my database, then I probably wouldn't use Impala in the first place.
This fix would be likely be trivial to implement in impyla, and it wouldn't increase the code complexity.
I also think that it is the job of the dialect to map sqlalchemy types to actual db types.
There's even a TypeCompiler class in SQLAlchemy that can be subclassed to override type compilation behavior.
The only time odo should care about the sqldialect is when i want to choose one to pass to sqlalchemy.
In any event, do you mind if I submit your fix upstream to impyla?

What's controversial? The fix?

I would only consider it a fix for odo, but at most a convenience feature for impyla which could turn into a gotcha, hence controversial.
By example: Impala has VARCHAR support since 2.0/CDH5.2. If impyla had compiled VARCHAR to STRING (which was obviously easy to implement) it would now have to break this behavior to support the new language feature. Even if you would not mind this particular disruption I hope you agree that it is controversial and a legitimate approach to throw "not (yet) supported  type exceptions" leaving it to downstream applications dealing explicitly with that.

... whereas a database client interface should be close to the system's SQL datatypes and only provide a basic level of abstraction

One of the goals of SQLAlchemy (as I understand it) is to abstract away the idiosyncrasies of all the different RDMBSs. It has explicit mechanisms for doing such things on a per dialect basis.

Sure, but the crucial question is: what are syntactical idiosyncrasies and what meaningful differences? The answer might differ depending on the use case, here general-purpose database client vs. high-level data integration/conversion. SQLAlchemy is a flexible tool and can be used by low- and high-level applications and for varying degrees of abstraction. In other words: you can use SQLAlchemy to create both a generic/flexible and a specific/rigor dialect for one and the same database system. You can also map every (not supported) type to BLOB.

I guess we're of two minds here ... I personally don't care that certain types like varchar or char are incompatible with impala. ... With those types, I usually just want a string column.

Actually, in this regard we are on the same page and therefore I highly appreciate your work on blaze/odo, taking the burden from me to deal with these subtleties when I don't have/want to. Regarding my current personal use cases, I wouldn't not mind if impyla's sqlalchemy dialect compiles TEXT to STRING or if Impala accepts TEXT as alias for STRING in its DDL (or if Impala ignores DDL constraints). Nevertheless, I think it's also reasonable to be more rigor on this end and leave stronger abstraction to tools like odo. That's why I submitted the issue here and not to impyla (but I CCed - and hereby again - impyla's maintainer @laserson in case he wants to pick it up).

In any event, do you mind if I submit your fix upstream to impyla?

No, go ahead.

Just back from a vacation.  AFAIK, people generally use the DB API impl in impyla directly, rather than the SQLalchemy dialect, which I created primarily to work with Blaze, and which I generally based off of PyHive.  So I'm not opposed to a fix in impyla at the moment.


deployed readme to github pages

Pull Request description

Made a few changes to readme file ( added contributing section)
deployed readme to github pages

https://github.com/osl-incubator/containers-sugar/issues/11
How to test these changes

...

Pull Request checklists
This PR is a:

[x] bug-fix
[x] new feature
[ ] maintenance

About this PR:

[ ] it includes tests.
[ ] the tests are executed on CI.
[ ] the tests generate log file(s) (path).
[ ] pre-commit hooks were executed locally.
[x] this PR requires a project documentation update.

Author's checklist:

[x] I have reviewed the changes and it contains no misspelling.
[x] The code is well commented, especially in the parts that contain more complexity.
[x] New and old tests passed locally.

Additional information

Reviewer's checklist
Copy and paste this template for your review's note:
## Reviewer's Checklist

- [ ] I managed to reproduce the problem locally from the `main` branch
- [ ] I managed to test the new changes locally
- [ ] I confirm that the issues mentioned were fixed/resolved .

Hi @Satarupa22-SD , thanks for working on that!
about issue #11 it would need changes in the github actions used for release https://github.com/osl-incubator/containers-sugar/blob/main/.github/workflows/release.yaml
It would looks a bit similar to this another one: https://github.com/osl-incubator/makim/blob/main/.github/workflows/release.yaml
some key concepts here are:

github actions https://docs.github.com/en/actions/quickstart
semantic-release https://semantic-release.gitbook.io/semantic-release/
Make https://makefiletutorial.com/
mkdocs https://www.mkdocs.org/

so first, you can build the documentation locally: mkdocs build --config-file docs/mkdocs.yaml
and if you want to build and open that in the browser, you can run mkdocs serve --watch docs --config-file docs/mkdocs.yaml
so, if that works fine, you can create 2 "Make" targets one for each previous mkdocs command
for example:
build:
        mkdocs build --config-file docs/mkdocs.yaml

preview:
        mkdocs serve --watch docs --config-file docs/mkdocs.yaml

Note: remember that in a makefile the indentation is done with TAB not empty spaces
And the last piece would be adding that to the github actions (similar to what we are doing in the makim project)
maybe there is a bunch of new concepts here for you, so feel free to take your time to read all the references and also feel free to ping me here if you have any question :)

@Satarupa22-SD let me know if you still want to work on this PR :) thanks!

Sure Ivan, I would like to continue working on this project. Somethings
have come up very urgently hence the delay.
On Fri, 19 May, 2023, 4:53 am Ivan Ogasawara, @.***>
wrote:

@Satarupa22-SD https://github.com/Satarupa22-SD let me know if you
still want to work on this PR :) thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/osl-incubator/containers-sugar/pull/71#issuecomment-1553775672,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUC7H67CP65U37RH56TZXVDXG2VQ3ANCNFSM6AAAAAAXEPIGAY
.
You are receiving this because you were mentioned.Message ID:
@.***>

ok no problem .. just checking :)
thanks for the feedback :)

@Satarupa22-SD, any plans to move this PR forward?
if you don't have time, don't worry, it is totally ok.

@Satarupa22-SD I am closing this issue for now
feel free to reopen that when you want


Expand tilde in uninstall :delete

Closes #12864

Docs in #12997. Will also (finally) allow a merge of #11530.
Feel free to merge this one when you want.

Should we push a new release after this is merged, or should we wait for #12991?

We should likely push a minor release, just so https://github.com/caskroom/homebrew-cask/pull/11530 can be merged (otherwise it would break anyway, if someone tried to install it).

I'll push a release with this and #11200 later this evening.


Add Gitter badge on Readme.

not sure why the TravisCI failed, I only edited the Readme 😖

What would you think about adding another <div align="center"> with the code-unrelated badges? (Sponsors, Backers & Gitter) This looks like a lot of stuff at the moment:

This is what we could change it to imo:

What do you think?

@rogr the travisci fails due to whitespace issues: it's fixed in my PR @mxstbr: https://github.com/mxstbr/react-boilerplate/pull/391

@mxstbr: Yeah, looks nicer!

Nice one, thanks @rogr!


Set the broker's zookeeper chroot path

There should be a method to set the chroot path when the brokers use zookeeper. This is normally appended to the zookeeper.connect configuration property.

Hi. This is already supported by --zk option of the scheduler. It is passed as is to Kafka brokers as 'zookeeer.connect' option. So it could be specified like: "zk=master:2181/abc" including chroot path.
Please confirm, is that exactly what was required?

That is exactly what I want. Nice.


Adding curl

In order to perform command in prestop hook in Kubernetes or any kind of operation directly from the container, it would be very useful to get curl installed

Its fine if you remove wget :)

That's not enough as wget is used in the Dockerfile to download stuff..

You are doing this cowboy-style :( this wouldn't work because apk del --purge .build-deps will uninstall curl. Please, do your changes and test them accordingly before updating the PR. Also, squash into single commit.

Is it better now ? Works for me

Hi, any news ? Thx

You're right, fixed


PPO1 vs PPO2

When running ppo1 vs ppo2 on the same data, ppo2 converges whereas ppo1 does not.
I tried several times with custom policies also and ppo1 never converges.

Hello,
This is your 10th issue and you are still failing are giving all the required information.
As discussed with @hill-a , if you continue to not follow the contributing guidelines, you will be blocked.
So, I assume you are using them on a custom gym environment, and apparently not with the same hyper-parameters (especially the number of workers). In any case, see #359 (and documentation) , PPO2 is not the same as PPO1 which is closer to the original paper.
So, it does not seem to be surprising regarding all those differences.


Request: Option to keep route middlewares

Hello,
in some cases (in this case my), we need to generate documentation when there is routes under authentication middleware (middleware checks for passed token in api).
Now, as i see, in Mpociot\ApiDoc\Generators\LaravelGenerator line 75 is this App::instance('middleware.disable', true); which disables all middlewares.
Would be great if there will be option in command line to not disable them

The problem is, that the generator calls the routes and does not know about which data to pass to the routes.
What would that be in your particular use case?
Is there a way to generalize it for the package?
For example, that's why there is the actAsUserId parameter.

I'am using this on laravel 5.3 with jwt-auth package.
In this case, jwt uses middleware with auth guard api:auth, to check and authorize user by token which is passed with ajax request headers.
So, when middlewares are ignored then my generated documentations example responses are null, if i comment App::instance('middleware.disable', true); - everything looks good to me.

I rely heavily on explicit bindings for my api, which as of Laravel 5.3 now uses the 'SubstituteBindings' middleware. So without middleware active I can't get any responses as the bindings don't work properly. Creating an option to disable this would be very useful for this circumstance (which is a feature of Laravel, so less of a fringe case)


No "Code" button for MacOS

There is no "Code" button. In the screenshot on the page, one of the options in the drop-down menu is to open with Github Desktop, which doesn't exist for MacOS. So the person who wrote this help article for MacOS was not using MacOS. If they did, that option wouldn't appear, and hopefully they'd see that there is no "Code" button, and instead they'd give the real solution. Since I don't have a "Code" button, I am stuck.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 606d4c70-3daf-8b03-9c31-b690927a7136
Version Independent ID: 24a13aaf-3d14-c810-182c-2c2d93fc299b
Content: Setting up a Git Repository - Visual Studio for Mac
Content Source: mac/set-up-git-repository.md
Product: visual-studio-mac
Technology: vs-ide-general
GitHub Login: @heiligerdankgesang
Microsoft Alias: dominicn

@audreymeier -- Audrey, thank you for your feedback.  Please consider these resources:

Ask a question or find an answer on the Microsoft Q&A page for Visual Studio.
Check the Visual Studio MSDN Forum.
Stack Overflow
Reddit

@heiligerdankgesang -- Dominic, please look into this issue.

#reassign: @anandmeg


Current Version Build Failed

Need fix.

This is due to an incorrect value - i've commented on your pull request


TIMEOUT error on every first connect

Every time I connect to my SFTP server for the first after booting my laptop, after about 5 seconds a TIMEOUT error occurrs - without fail. After reconnecting it works fine for the rest of the day.
OSX 10.11.6
Atom and Remote-FTP up-to-date.
Let me know if there is any other information you need.

@EchoSixteen Could you try updating to 0.9.2 and let me know if you're problem persists?

Hey jimmaaay! (Nice name :P)
Bad news - I've updated to 0.9.2 and the issue persists...

Hello again,
This morning the connection didn't drop, even though nothing has changed from yesterday when I posted.
Let me know if there's any more information you need.

Okay, I'll probably implement some sort of auto reconnect on a timeout error with sftp. As I have no idea what would be causing this.

@jimmaaay - I discovered a caveat to this issue.
If I use the panel button to connect to my SFTP server, the timeout does not occur. Only if I use the keyboard shortcut does it disconnect.
Specifically, I am referring to the buttons that appear in the FTP panel, where the file tree appears once connected.
Hope that helps.

Okay, please test the latest update (which will be released in the next hours) if this still an issue for you and reopen if the problem persists. The sftp keepalive should be working again.


RFC: Idea to fix/run benchmark

My idea is based on the correctness and update speed of the discord/discord-api-docs repo, using its example data as the date we run the benchmark on (benchmark repo)[https://github.com/H01001000/benchmarks] (my fork). Currently, it gets the guild every time it runs, but instead, we can cache it in the benchmark and create PR or commit it directly when there is a difference with the last cache, which can run on schedule with GitHub action. This should be relatively easy to do/maintain and can run on every commit.
Then we can use  github-action-benchmark to check the result/comment on the result and put it on site.
Any feedback is appreciated

No, using stale and manually maintained things is not viable. The performance folder must run on request to the live api! I can discuss the goals of this in depth in discord @ me there
Also to clarify if this is about #2298 then this pr does not solve that.


Support for case statment

It would be good if you would implement jade's case statment support
template(name='main')
  case friends
    when 0
      p you have no friends
    when 1
      p you have a friend
    default
      p you have #{friends} friends

I often use a logic helper to mimic a case or switch statement:
if is field 'ok'
  span OK
else if is field 'maybe'
  span Maybe
else
  span Nope

I've posted my logic helpers in this gist, but the is helper could be implemented simply like this:
Template.registerHelper("is", (first, second) => first === second);

The and helper is great for the following little trick* that works because Blaze doesn't output falsy values – so if isOk is false, nothing happens:
span.label(class=and(isOk 'label-success'))

And I use the tern (ternary) helper like this:
i.icon(class=tern(isFiltered 'filter' 'world')

relying on the parenthesis syntax from dalgard:jade


Error While using helloworld sample smart contract

You can also create a feedback issue here in the repo. If you do this, please make sure your issue lists:

[ ] The relevant Azure service or technology.
Azure workbench

[ ] A link to the published documentation article that you have feedback about.
Hi, This smartcontract is giving me an error while i am trying to use it in Azure workbench
https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/hello-blockchain/HelloBlockchain.sol

[ ] Clear, specific feedback that the author can act on.
Here is the specific error. You can also refer to the attached screen print.
{"Errors":["Workflow contract HelloBlockchain should not derive from WorkbenchBase base contract. This is considered an error now. Update the HelloBlockchain contract to remove WorkbenchBase and calls to "ContractCreated" and "ContractUpdated" functions. "],"Warnings":[]}

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 2b3325f0-8e3a-6555-7589-ad0b8bbde085
Version Independent ID: 1318dfb8-652c-262c-b921-bb064d6480e5
Content: Create a blockchain application in Azure Blockchain Workbench
Content Source: articles/blockchain/workbench/create-app.md
Service: azure-blockchain
GitHub Login: @PatAltimore
Microsoft Alias: patricka

@amrikmahal Thanks for the feedback! We are currently investigating and will update you shortly.

Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

Hi @amrikmahal, Thanks for opening the issue. I deployed a new Azure Blockchain Workbench. Deployed Hello Blockchain! from the GitHub repo. I didn't get the error. The sample in the repo is current. I'm not sure why you would be getting that validation error if you have the latest version of Hello Blockchain! sample.
Can you verify you have the latest sample code?
Thanks,
Pat
#in-progress

Updated all code in the article to match the current sample. Tried the current sample from the GitHub samples repo and couldn't reproduce the issue.
#please-close

We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Update UserGuide.md

Update UserGuide.md for a better user guide

Codecov Report

Merging #203 (e4c8966) into master (8e6701b) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #203   +/-   ##
=========================================
  Coverage     67.44%   67.44%
  Complexity      718      718
=========================================
  Files           114      114
  Lines          2436     2436
  Branches        247      247
=========================================
  Hits           1643     1643
  Misses          689      689
  Partials        104      104

Continue to review full report at Codecov.

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


timeElapsed not increased on Bar.Set()?

Apparently I get "---" for the time elapsed prepend when using Set(). Is this by design?

Same here. I tried setting bar.TimeStarted but that didn't work.

Same here. Reproduced with this code:
package main

import (
	"github.com/gosuri/uiprogress"
	"time"
)

func main() {
	uiprogress.Start()            // start rendering
	defer uiprogress.Stop()
	bar := uiprogress.AddBar(100) // Add a new bar

	// optionally, append and prepend completion and elapsed time
	bar.AppendCompleted()
	bar.PrependElapsed()

	for {
		//bar.Set(bar.Current() + 1)
		bar.Incr()
		if bar.Current() == 100 {
			break
		}
		time.Sleep(time.Millisecond * 20)
	}
}

If you comment line 19 (bar.Incr()) and uncomment line 18 (//bar.Set(bar.Current() + 1)) then the elapsed time does not show up.

I noticed this as well, using the latest release (v0.0.1).
It's caused by a discrepancy between how Bar.Incr() and Bar.Set() work. It would be more consistent if Bar.Incr() was implemented in terms of Bar.Set().
Here's the current code:
// Set the current count of the bar. It returns ErrMaxCurrentReached when trying n exceeds the total value. This is atomic operation and concurrency safe.
func (b *Bar) Set(n int) error {
	b.mtx.Lock()
	defer b.mtx.Unlock()

	if n > b.Total {
		return ErrMaxCurrentReached
	}
	b.current = n
	return nil
}

// Incr increments the current value by 1, time elapsed to current time and returns true. It returns false if the cursor has reached or exceeds total value.
func (b *Bar) Incr() bool {
	b.mtx.Lock()
	defer b.mtx.Unlock()

	n := b.current + 1
	if n > b.Total {
		return false
	}
	var t time.Time
	if b.TimeStarted == t {
		b.TimeStarted = time.Now()
	}
	b.timeElapsed = time.Since(b.TimeStarted)
	b.current = n
	return true
}


WIP: Collapse .all and .first api method signatures to single hash

@jarthod
This supersedes https://github.com/RipTheJacker/survey-gizmo-ruby/pull/42 but I'm not ready to merge this yet.  Collapsing the method signatures makes everything a lot less user error prone and generally better but is also a majorly breaking change with everyday usage that I have not tested yet.
Other PR should be ready for merge and is only a minor version bump.  Not sure when I will finish this but heads up and feedback appreciated.

Ok I like the idea, but maybe you could just keep the second parameter and merge it into the first.
This way it won't break anything and we can put this as a minor. Maybe with a deprecation warning if this parameter is present.
Of course the comments, readme and specs should all show the single hash usage as you did.

that's actually a pretty great idea; then we don't need the major version bump.

OK now there's a deprecation warning that will print if you use the 2nd param and the major version doesn't have to increment.
i set version to 4.2 because the other PR is 4.1 and presumably that will be merged first (i've tested that in production)

OK i did some preliminary testing and fixed some bugs; I'll run a full scale test in the next few days at which point i'll give the greenlight on this PR, but so far looks fine.

Great, thanks for your contribution!

for what it's worth, PRs from lumos will only generally be submitted to the project when they have been tested in a fairly massive production environment on the order of hundreds of surveys and millions of responses being retrieved via the API.

but i would kill for some vcr/webmock specs, grr

i had one more minor style commit that didn't end up on this branch, so i'm going to close this and reopen a new PR.


Issue with conversation_id Being None in extended_openai_conversation

Refer Issue : https://github.com/jekalmin/extended_openai_conversation/issues/124
Expected Behavior:
Each ConversationInput instance should have a unique or continuous conversation_id that persists across related conversation inputs, enabling the tracking and management of ongoing conversations.
Current Behavior:
Debug logs indicate that every ConversationInput has a conversation_id of None. Here are some examples from the logs:

user_input: ConversationInput(text='xxx', context=<...>, conversation_id=None, device_id='...', language='*'), context: {'id': '...', 'parent_id': None, 'user_id': None}
user_input: ConversationInput(text='xxx.', context=<...>, conversation_id=None, device_id='...', language='*'), context: {'id': '...', 'parent_id': None, 'user_id': None}

Thanks for bringing this to my attention! This will require some coordinated changes across HA and the satellite, but I'll get it in there :+1:

That's a must have ! Nice to hear you work on this.
Will this help with the number of prompt_tokens sent in successive calls ?
Maybe the "system" part of the prompt is not needed when conversation_id is set ...

Thanks for bringing this to my attention! This will require some coordinated changes across HA and the satellite, but I'll get it in there 👍

Would that be adding a new attribute in all events to hold the id? (And modify both ends to use it)

I will add the conversation id to the "context" field that several Wyoming messages already have.
The only question is when/if to reset the id after some period of inactivity. ESPHome does this after 5 minutes.

That's a must have ! Nice to hear you work on this.
Will this help with the number of prompt_tokens sent in successive calls ?
Maybe the "system" part of the prompt is not needed when conversation_id is set ...

This will just tell the integration the key to look up the context. It's up to the integration to decide what to keep or discard before sending it to the LLM.

I will add the conversation id to the "context" field that several Wyoming messages already have.
The only question is when/if to reset the id after some period of inactivity. ESPHome does this after 5 minutes.

If integrations decide on what should be included in context to send to LLMs based on conversation id, then it should be reset and 5 minutes (or configurable if not hard to implement) looks ok, otherwise context size will grow huge and we'll run out of tokens. :)

this would be great ! I'm using Extended OpenAI Conversation with gpt 3.5 and it's just amaizing. Its what we thought alexa and google assistant will be eventually but never got to be. It works great on the phone but I miss not beeing able to do a follow up question on the satelite I have in the kitchen.

I have come here for the same reason, assistant often asks questions like this light or the one from the kitchen, or found this music, what shall i play? but when i respond of course it's a new convo for it.
Any new update on this?

Chiming in here - this would be a great addition to have available, regardless of if you're using the OpenAI extension or something else non-ESP!

Hi @synesthesiam, could you please give us any insight on whether we should switch to ESP32-based hardware instead of using a Raspberry Pi? Seeing all the official development going towards ESP32-based hardware lately, I wanted to know if this is going to be the future of voice assistant hardware and if the Pi option won't be supported any longer?

Both the ESP and Pi options will continue to be supported. The difference is that there are now 4 people (including me) working on voice in ESPHome and only one (again me) working on Wyoming satellites 😄
I've been slowly getting PR's merged and new features added. The conversation id is on my list for this upcoming week 👍

Thanks for the update! I'll keep the Pi satelites then. This project is great! Appreciate the hard work and looking forward to the new features.

As part of the upcoming release, I have added this: https://github.com/home-assistant/core/pull/118835
Conversation id is automatically generated and kept for 5 minutes of inactivity within HA.

Really love to see this change, thanks a lot <3. Is this also available for the ESPHome/ESP32 satellites?

Yes, this has been a part of the ESPHome voice assistant for a few releases now. They have the 5 minute timeout as well.

Is this change included in the current version (2024.7.2)?

Hi. Can you tell me if I'm doing this right?
I have wyoming-satellite configured on one device in docker and home assistant with extended_openai_conversation on another.
Every time openWakeWord is triggered wyoming-satellite listens to the microphone and extended_openai_conversation responds, but after the response the dialog ends.
Besides, debugging shows that conversation_id is different every time.
My docker-compose:
ersion: '3.0'

services:

  satellite:
    container_name: wyoming-satellite
    build: https://github.com/rhasspy/wyoming-satellite.git
    image: rhasspy/wyoming-satellite
    restart: unless-stopped
    volumes:
      - ./wyoming-satellite/sounds:/sounds
      - ~/.config/pulse:/root/.config/pulse
    ports:
      - "10700:10700"
    command:
      - "--debug"
      - "--name"
      - "living_room"
      - "--uri"
      - "tcp://<IP_ADDRESS>:10700"
      - "--mic-uri"
      - "tcp://microphone:10600"
      - "--snd-command"
      - "aplay --device \"pulse\" -r 22050 -c 1 -f S16_LE -t raw"
      - "--awake-wav"
      - "/sounds/act1.wav"
      - "--done-wav"
      - "/sounds/act2.wav"
    environment:
      - "PULSE_SERVER=host.docker.internal"

 playback:
    container_name: wyoming-snd-external
    build: https://github.com/guinmoon/wyoming-snd-external-pulse.git
    image: wyoming-snd-external:pulse
    restart: unless-stopped
    volumes:
      - ~/.config/pulse:/root/.config/pulse
    ports:
      - "10601:10601"
    command:
      - "--debug"
      - "--device"
      - "pulse"
    environment:
      - "PULSE_SERVER=host.docker.internal"

  microphone:
    container_name: wyoming-mic-external
    build: https://github.com/guinmoon/wyoming-mic-external-pulse.git
    image: wyoming-mic-external-pulse
    restart: unless-stopped
    volumes:
      - ~/.config/pulse:/root/.config/pulse
    ports:
      - "10600:10600"
    command:
      - "--device"
      - "pulse"
      - "--debug"
    environment:
      - "PULSE_SERVER=host.docker.internal"

  openwakeword:
    container_name: openwakeword
    image: guinmoon/wyoming-openwakeword
    volumes:
      - ~/.config/pulse:/root/.config/pulse
      - ./openWakeWord/data:/data
      - ./openWakeWord/custom:/custom
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "10400:10400"
    command:
      --preload-model 'alexa'
      --custom-model-dir /custom
      --model 'alexa'
      --uri 'tcp://<IP_ADDRESS>:10400'
      --debug
    restart: unless-stopped
    environment:
      - TZ=Europe/Moscow
      - "PULSE_SERVER=host.docker.internal"


switch statement unexpectedly treats barewords as expandable strings

Note: It may be too late to change this behavior, or it may fall into Bucket 3: Unlikely Grey Area.
If the former, the pitfall discussed is at least worth documenting.
about_Switch  states about the syntax of individual switch branches:

 "string"|number|variable|{ expression } { statementlist }

The above suggests that an expression can only be used inside script blocks, but in practice you can also use (...)- and $(...)-enclosed expressions directly (e.g., (1 + 2)) and even method calls (e.g., $PSVersionTable.PSVersion.ToString()).
Surprisingly, however, a non-numeric unquoted token that doesn't start with ( or $ (and doesn't break parsing) is unexpectedly treated like an (expandable) string rather than as an expression:
Steps to reproduce
0 -eq [uint32]::MinValue

switch (0) {
 ([uint32]::MinValue) { $true }  # OK - (...) ensures use as expression
 default { $false }
}

switch (0) {
 [uint32]::MinValue { $true }  # !! condition treated as *string*
 default { $false }
}

switch ('[uint32]::MinValue') {
 [uint32]::MinValue { $true }
 default { $false }
}

Expected behavior
True
True
True
False

Actual behavior
True
True
False
True

That is, unquoted [uint32]::MinValue is interpreted the same way as '[uint32]::MinValue' in this case.
This is unexpected, given that it is reasonable to conceive of the branch conditions of a switch statement as the RHS of an expression along the lines of <switch-value> -eq <branch-condition>, and given that any unquoted token on the RHS of -eq is interpreted as an expression.
Environment data
PowerShell Core v6.0.0-alpha (v6.0.0-alpha.18) on Darwin Kernel Version 16.5.0: Fri Mar  3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64

PowerShell ISE makes this pretty easy to see what is going on, and I have implemented this in https://github.com/PowerShell/EditorSyntax/pull/156.  The condition is treated as an argument, not an expression.  I think the documentation for this needs to be clarified, though not sure how.

Source: https://github.com/msftrncs/PwshReadXmlPList/blob/master/PList Reader.ps1


remove marketing footer from registry

overview
it was not intended to bring over the large marketing footer to registry, but it was easiest to bring it over to get it released on time. now lets remove it.
design details

[ ] remove dots and column'd list of pages from all registry footer pages
[ ] leave the hr, copyright, social icons, and row of links in place

this is done


minor functionality request

Issue Type: Feature Request
Will you developing guys please add a minor functionality that when I define a function in Python, a ":" and an identation are automatically added upon tapping "Enter"?
VS Code version: Code 1.26.1 (493869ee8e8a846b0855873886fc79d480d342de, 2018-08-16T18:38:57.434Z)
OS version: Windows_NT x64 10.0.17134

Please file an issue against python extension


[bug] Close the world when connecting

Game version: 1.21.22
Only the port and time zone were modified,
When I connect, the world will be closed directly. Even when re-entering the world, it will be closed again.

Have you disabled the Require Encrypted Websockets?
Currently this library doesn't support encryption.

It seems that it cannot be disabled...

Leave the world and try again from main menu

Leave the world and try again from main menu

This doesn't work, but restarting Minecraft can.


Don't extract filters that are not hyper edges

This bug was a bit frustrating.
Normally during join order optimization, we extract all filters and see if they can be used as join conditions. This helps us to identify filters like t1.a + t2.b = t3.c as a join filter. We visit/extract all filters for the relations within the reorder able join tree, and push the filters back in to the tree when we construct the plan.
Naively, the join order optimizer expects all filter expressions to have a column binding where the table index is in the relation mapping. In a happy case, this doesn't error, however, when limit rownum is introduced things start to go wrong. If a query with a delim join has limit, then a window operator is introduced to calculate the rownum. The rownum expression in the window operator has its own table index that is never added to the relation map because it exists only between the window operator and the filter operator on top of the window.
This rownum filter is still extracted, and there is an attempt to push the filter back into the plan. The join order optimizer does not push the limit rownum filter back into the exact same plac unfortunately (although it is very close). For some queries, it's possible there is another filter on top of the limit rownum filter. These filters are not combined during filter pullup/pushdown because of projection maps. It would require combining projection maps, which can get confusing and is out of scope for this PR. When the filter is pushed back in the wrong place, verifying the plan throws an error because the table index for the rownum expression no longer exists in the TableIndexes of the Filter. The table index only exists at the window operator and the parent filter operator (that filters the row number).
There are multiple fixes for this, but I like this fix the most. Filters that cannot be turned into join conditions are most likely in the right place. I also don't want to apply filter pushdown again because debugging the optimizer can get difficult when certain optimizers are called within other optimizer.
For now, the current fix is to not extract filters where all expression bindings have no table mapping in the relation mapping.

has been merged to main


[Ubuntu] Use variable instead of hard coded value

Description
Use the interval value in retry function
Related issue:
https://github.com/actions/runner-images/issues/7208
Check list

[x] Related issue / work item is attached
[ ] Tests are written (if applicable)
[ ] Documentation is updated (if applicable)
[ ] Changes are tested and related VM images are successfully generated

/azp run ubuntu2004,ubuntu2204


Get proposal id with events

Get proposal id with events to avoid problems when using RPC node does not support debug_traceTransaction
Import ERC20Votes in GovernorContract for build

Thanks for this PR! Just one question...

jfyi, have updated the pull requests

Awesome, thank you!!


Auth0 Migration instructions (DO NOT MERGE UNTIL AUTH0 MIGRATION IS LIVE)

What are you changing in this pull request and why?
Migration instructions for Auth0 SSO
https://dbtlabs.atlassian.net/browse/ENTERPRISE-529
Preview
Checklist

[x] Review the Content style guide and About versioning so my content adheres to these guidelines.
[x] Add a checklist item for anything that needs to happen before this PR is merged, such as "needs technical review" or "change base branch."

Adding new pages (delete if not applicable):

[x] Add page to website/sidebars.js
[x] Provide a unique filename for the new page

@matthewshaver about this -
"You can approach this by editing the existing SSO app settings or creating a new one to accommodate the Auth0 settings. One approach isn't inherently better, so choose whichever works best for your organization."

@matthewshaver @BrJan for website/static/img/docs/dbt-cloud/access-control/new-okta-completed.png file in this PR, can we use a screenshot that has custom domain unlike devspace-cluster.
This screenshot is a good one from au.
https://www.notion.so/dbtlabs/WIP-Auth0-Corbato-Overhaul-Support-Readiness-0d388b0ed9df4819a8dc997e083b923b?pvs=4#5671fd1f1ecd46a3bd036473cb58ad2c


BaseResponse with Arrays and Generics

Lets say we have a base response, that using generics, similar to this:
struct BaseResponse<T: JSONDecodable> : JSONDecodable {

  let data: T?

  init?(json: JSON) {
    self.data = "data" <~~ json
  }
}

When the T is an Object everything works well, but if the T is an Array of Objects, the parsing from JSON, returns nil.
I ended up with creating 2 base responses, one as above and another one for Arrays as follows:
struct BaseArrayResponse<T: JSONDecodable> : JSONDecodable {

  let data: [T]?

  init?(json: JSON) {
    self.data = "data" <~~ json
  }
}

But it looks like should be a better solution for that, or maybe I am missing something.
Please advise
Thanks

no you're not missing something!
what i'd actually advise - it sounds from the types you're writing that you may be close the start of a project, it might be better to utilize the first-class Codable framework instead of relying heavily on a third-party.


sending (posting) messages delivery & narrowing

I'm not sure how to diagnose this behavior.
First: I've been trying to send a message to the "publicity" stream on zulip.tabbott.net. First I did this, thinking it would link to a previously uploaded image:
[image](/user_uploads/2/f6/W61UzdFyz4Kywn1iO2MJLdth/20160605_001.jpg)
That got me a "not delivered" warning in red. I then edited the message to link to a conversation, like:
[image here](https://zulip.tabbott.net/#narrow/stream/PyCon.20Sprints/subject/mypy/near/6274)
and I still got a "not delivered" error. And then if I successfully post a message after the message that has a "not delivered" warning on it, then clicking on the retry, edit, or delete buttons (next to that Not Delivered warning) has no effect.
Also, I got the "outside your current narrow" message below while posting to a stream and a topic that was in my current narrow. I don't remember the exact sequence of events, but it was like:

narrow to 'publicity'
start writing a message
switch to PyCon Sprints
look up the URL I want and copy it
hit Compose, thinking it would have my saved draft - no, I don't see it
switch back to publicity stream and see my partially composed draft there
finish writing it and hit Send
see "outside your current narrow" notification even though I am in the publicity stream's narrow

This all happened in the span of a couple of minutes so maybe they're connected to a recent deploy or blip? But I don't see how they could be logically connected so they might be 2 issues.

"not delivered" issue:

"outside your current narrow":

The "not delivered" condition is what happens if e.g. the server is down at the time you try to send your message.  I suspect the "outside your current narrow" message might be a buggy interaction with that case.

Tim says this is "a bug in how our local echo support handles outages."

Hello, I just joined the community and started looking for issues to help with, and seems like this old one can be closed.
I tried to reproduce locally but was not able to, looks like things changed a lot already.
Can anyone please confirm if this can be closed?

I'm pretty sure this is indeed fixed, closing.E.g. this logic very clearly checks whether the current narrow will contain the new message:
    const current_filter = narrow_state.filter();
    if (
        current_filter &&
        current_filter.can_apply_locally() &&
        !current_filter.predicate()(message)
    ) {
        return $t({defaultMessage: "Sent! Your message is outside your current narrow."});
    }


v1 instead of dev branch

name "dev" branch is misleading for "v1", use v1 instead.

Is the dev branch still needed, ie can it be deleted after the creation of a new v1 branch ?


feat(viewer_results): add the results viewer ViewerCptGroupResults

Pull Request Test Coverage Report for Build<PHONE_NUMBER>5
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.7%) to 81.393%

Totals

Change from base Build<PHONE_NUMBER>9:
0.7%

Covered Lines:
1776

Relevant Lines:
2182

💛  - Coveralls


Window doesn't fit screen

I have the size of text and items in Control Panel\All Control Panel Items\Display set to medium (125%).  At that setting the synctrayzor window doesn't fit the screen (I lose the minimise/maximise buttons and the menu toolbar).
Is it possible to get it to fit the screen when the windows display size is not set to the default 100% setting?

What Windows version are you running? What's your display resolution? Can't reproduce this on Windows 8.1 1920x1080.

Err I guess I could put something in to decrease the default window size if it's too large for the screen.
Can't you just size it to whatever you want, though? After you've done that once, it will remember the size you set. You can move it using e.g. this technique.

@dodekeract many Laptops come with 1366x786. Instead to change the default, it would be better to check if the dimension is do big for the screen.

@nille02 if that's really OP's issue and @canton7 or somebody else change this behavior then I would add that the default/calculated window position needs to watch for any taskbar (mine is top for my main display) "interference". Steam doesn't properly do it and often moves the window behind my taskbars.

I've taken the simple approach of constraining the window's initial dimensions (before we get into the business of remembering the window's size/position) to virtural height - 40 and virtual width - 40, 40px being the (large) size of the taskbar. Windows can then take care of positioning it (which in my testing, it does well).
Although - you'll probably find that closing / re-opening SyncTrayzor fixes the issue for you anyway, due to the way that we restore the window's position.
Feel free to re-open the issue if, after the next release, the issue isn't resolved.

Sorry guys for not being more specific, and thanks for the comments.  It's on a little Windows 8 box attached to a TV.  Screen res' is 1920x1080 but the display adapter can only go up to 1360 x 768.  Because I'm sitting 10 feet away I have the display enlarged to 125%.  With that combination though there isn't much screen real estate.
I should have thought to use the technique canton7 suggested but in the end I didn't need to.  Once I changed the display back to 100% I could resize the screen so when setting it to 125% it fitted okay.
Not a difficult workaround but if you get around to having it fit automatically I'm sure that would help quite a few users.


build: Make "make clean" to gather all the informations about removed files

Fixes #1534 (hopefully).
Currently, make clean is able to remove files from build directory only for current configuration. It means that invoking the following commands:
./configure --with-stage1-flavors=coreos,kvm
make -j4
./configure --with-stage1-flavors=src,host
make -j4
make clean

will fail, because "make clean" will be able to remove files for src and host flavors (systemd git repo, its builddir, aci rootfs directories for host and src, …), but won't touch anything left by coreos or kvm flavors (downloaded pxe.img or linux sources tarball, squashfs file, aci rootfs directories for coreos or kvm, …), so it will end up complaining about not being able to remove some directories, because they are not empty.
This PR changes the build system to include all the Makefiles, including the ones specific to some flavor. A bunch of cleanups were required to make sure that make clean will handle its job regardless of parameters passed to configure script.

LGTM


Perform Validations during Task Execution

Right now, validations are performed during afterEvaluate in https://github.com/dropbox/dependency-guard/pull/86 because we don't know what all configurations are until that point in time, and cannot be sure we have what we need to validate.
While this should work, it's better to just provide these values to the task and have the validations done there.

Will work on this in https://github.com/dropbox/dependency-guard/pull/83

This is being worked on in https://github.com/dropbox/dependency-guard/pull/90 now as #83 didn't fix it.

Ever since we merged in the initial implementation of Config Cache for 0.4.0, there have been issues with race conditions in different projects.
This has made this plugin incredibly had to test as the behavior varies based on what large project it is working in.
GOAL
Create consistent validation that prevents these sorts of errors from happening in the future.
What's the problem?
project.configurations.forEach{} is not reliably ready with all configurations at the time the dependencyGuardTask.configure{} block is run.
What was the attempted solution?
For v0.4.2, configuration validation was moved to the .afterEvaluate {} block which worked, but there was a reproducible edge case that still ended up not having the values available.
What can we do?
Because there seems to be no reliable way to get a full list of available project configuration names during the Gradle configuration phase, we need to change the way these validations are occurring.
We DO have the ability to look up configurations by name, and see if they exist, and that seems to be reliable with project.configurations.findByName().  So, we can just look up each requested configuration with this method to see if it exists instead of cross referencing with a full list which may not be correct at that time.
The only remaining issue is that now we don't have a full list to print out to help guide the user to correct usage.  To get around that, we now print a helpful error message IF these names are available, and if not, we just say we can't resolve XYZ configuration.
I'm very hopeful the solution in #90 that no longer relies on .afterEvaluate will behave consistently in all projects.  It has fixed the reproducible error in the project I have, so I'm hopeful!

Fixed in #90 🎉


Move cursor to newly-created file or folder

This PR adds a simple, but in my opinion very useful feature.
After you create a new file or folder, the cursor is moved to the new line so you can press Enter to directly edit the file or enter the folder.
https://user-images.githubusercontent.com/543561/173052587-940c36cb-fb88-4740-b127-d0247ebc27f7.mp4

I like it! Thanks :)


fix headings levels in second quality assessment for seasonal

Fixing the level of the headings in seasonal_seasonal-monthly-single-levels_forecast-skill_q04.ipynb.

Not sure if there is a good way to avoid the updates to the python kernel version in the metadata. The figure numbering is still an issue.

I'm going to add a pre-commit hook that remove useless metadata.
We are already using pre-commit quite a bit, so make sure you install it for this project. If you are not familiar with pre-commit, you can find the instructions in the README.

The figure numbering looks tricky (there might be a bug in jupyter-book or sphinx).
Let's merge this for now, I will have a better look at it tomorrow.


unused dep references?

Got a hunch ( from undepend ) that these are not needed.

At least the bevy_reflect dependency of bevy_input is needed (see the red CI build). Did Bevy build locally after making these changes?

We are using https://crates.io/crates/cargo-udeps in CI to detect unused dependencies

cargo-udeps is not completely accurate. undepend works by actually compiling the source after removing candidate unused dependencies, which should be more accurate than cargo-udeps, but it seems not in this case.

bors r+