Implementation Docs: Plugin Based Authentication

This was my approach to implementing plugin based authentication. Hopefully it's not an anti-pattern for how you envisioned Saloon being used. Putting docs here in case they can be brought into the official docs if it's an acceptable solution.
Plugin Based Authentication
In release v0.8.0 the authentication feature withToken was added. This trait adds the functionality to requests:
$request = UserRequest::make()->withToken('Sammyjo20');

This can be great for one offs, but depending on the size of the API you're interacting with, can feel less clean than simply newing up a request class and having it happen behind the scenes.
Pain Point
There are a few pain points which can be addressed using plugin based authentication:

Limits copy pasting of code that would otherwise be present in every request for larger API's
Allows additional logic such as expiration, finding proper keys to use (when you have multiple users authenticated, for instance) to be attached at single point and used for all subsequent requests
Architecturally feels more familiar to how we are accustomed to handling authorization (base URL, configuration, headers live in the "Connector"), abstracted away from the requests
For large API's such as salesforce, it could be helpful to build more than one connector depending on how you want to organize the project

While it is shown here that using defaultHeaders() is possible, with expiring tokens this approach does not feel as streamlined.
Lastly, to use Salesforce as an example, per-user OAuth configurations may have radically different endpoints. To validate and get the OAuth configuration, then initialize the wrapper and not need to worry about subsequent requests, design wise, feels more like what Saloon was going for.
Implementation
In your wrapping class that invokes the API, you can add the following properties.
// MyApiWrapper.php
protected static string $token;

public static function token() : string
{
    return self::$token;
}

These can be supplied during construction of your wrapper. For my use with Salesforce, it looks like this (where $accessToken is an oauth token that has not expired):
public function __construct(string $accessToken, string $instanceUrl, string $apiVersion)
{
    self::$token = $accessToken;
    self::$instanceUrl = $instanceUrl;
    self::$apiVersion = $apiVersion;
}

Then, create a plugin with the following:
// Plugins/WithAuthorizationHeader.php
public function bootWithAuthorizationHeader() : void
    $this->mergeHeaders([
        'Authorization' => 'Bearer ' . MyApiWrapper::token()
    ]);
}

Finally, in your connector class(es), simply include the Trait
// Connectors\MyConnector.php

use WithAuthorizationHeader;

The connector will automatically merge the token into each request.

Thanks so much for writing this up @WalrusSoup. I think you have a really good point about how using "withToken" breaks out of Saloon's pattern of everything being wrapped in objects. I released it because I feel for some people might not be able to easily pass in a token. Maybe I should add it as an optional add-on trait rather than bolting it onto every request?
After seeing it from this angle I can see it actually adds a bit of confusion.
I like your DTO approach to this though. I have done this too on an API wrapper I built around Saloon with Oauth 2. Essentially I have a "Keychain" DTO which is returned after successfully generating authentication tokens, see here:
https://github.com/Sammyjo20/intelligent-office-php-sdk/blob/main/src/Concerns/AuthenticatesWithService.php
Here's the Keychain class:
https://github.com/Sammyjo20/intelligent-office-php-sdk/blob/main/src/Helpers/Keychain.php
Which looks very similar to what you are doing, but I would be quite happy to add this to do the docs with maybe a few tweaks inspired by my approach too.

I love that keychain approach (and the name, makes so much sense!).
One reason I used the approach inside the wrapper was it would act as a  class property singleton. Requests new up a connector each time, which could be some load in unexpected places depending on where the dev gets their token.
In the case of Salesforce, Zoom, etc where requests are often paged it could mean unnecessarily contacting the database layer. While this is a small concern, it was enough to make me think optimization could be helpful.
I could see an approach where a Keychain feature built into actual library could be really helpful. I suppose the thing to ask then would be where does Saloon stop as far as scope? I think a keychain is probably as far as it should go.
Perhaps a class based approach built into the connector may be consistent with how Saloon is built out so far?
class MySeviceKeychain extends SaloonKeychain
{
   // this can be in parent class
    protected static $instance;
   // could potentially have traits in here for defaults, useBearerHeader, etc.

    // called if $instance was not built yet, user should write this function themselves
    public function buildKeychain() : void
    {
        // I should set $instance in here to whatever I need it to be
        self::$instance = MyBackendFunction::loadCredentialsFromDatabase();
    }

    // user could code this themselves or this apply function can yield to the included trait (like Authorization: Bearer)
    public function apply(SaloonConnector $connector): void
    {
        // I should do my own logic here if i need something super custom
    }
}

Then over in the actual connector:
protected ?SaloonKeychain $keychain = MySeviceKeychain::class;

Then I suppose if there is a keychain set in the connector, the connector can call build and then a built in apply or the a user supplied apply function.
Just a thought, though. In practice, not sure how maintainable this would be long term.

Glad you like the idea! I’ve now built two SDKs with Saloon using this approach, you authenticate the SDK with
‘$sdk->authenticate($keychain);’
Which loads it into the SDK to use later in your connector.
To be honest though, I see it being really useful as a way you can nicely transport credentials around the application, especially with your example where you might have different sources. What I did for one of my SDKs is I have a Laravel Model which has a method called “toKeychain” which returns its credentials as a SDK keychain that can be passed in. Maybe the same approach can be used for Saloon too, or like you’ve described - you can specify how a keychain is populated inside.
After you have created your keychain, you could pass it into your request or connector.
What would be nice is to let the user handle how the keychain should be processed, because different APIs might require different authentication/headers. Do you have any suggestions for this?

On a side note, I’m definitely interested in building a nice “Oauth” wrapper around Saloon that people can really easily use to connect to an Oauth 2 service. Quite a lot to process on that though so that’s for another day 😅

Ah, I just re-read your message and I like your implementation 👍
I agree with this is probably as far as I would go with Saloon, I don’t want it to be too opinionated but certainly make integrating with APIs easier. This could be a plugin that people add, but I’ll have a think.
Thanks for sparking the thought in me, this is a really cool discussion!

So here’s a first party idea from this discussion

A user can define a Saloon “Keychain” which a class used to find credentials
when a connector is booted up, the keychain’s “lookup” method is called (but can be blank)
If the lookup method is not called the user is expected to pass in a keychain maybe like this:

Request::make()->authenticate($keychain)->send();
or
Request::make()->withKeychain($keychain)->send();
There could also be different types of keychain like:

BearerKeychain (will prefill the Authorizatoon header)
BasicAuthKeychain
Keychain (basic)

Awesome, I think I might go for this then, here's a class style I've come up with:
class ForgeKeychain implements SaloonKeychain
{
    public function __construct(
        protected string $apiKey
     )
    {};

    public function default(): self
    {
        return new static(config('services.forge.key'));
    }

    public function toSaloon(SaloonRequest $request): void
    {
        // The keychain could have the helper methods like
        // addToken, addBasicAuth, addDigestAuth rather than the
        // request.

        $request->addHeader('Authentication', 'Bearer ' . $this->apiKey);
    }
}

I'm thinking of moving the authentication helpers like withToken to this keychain class in the form of a trait so it's a shortcut to add a bearer token rather than it being on the request and breaking the Saloon pattern

I have implemented this in v9.0, however I'm having second thoughts. What if instead we just introduced a way to send requests easily from the connector rather than the request.
My initial thought of creating the request and then sending it was to keep it simple but sometimes you might want to create the connector so you can pass in authentication tokens into the connector.
I can see the keychain being useful if you want to authenticate individual requests for a particular user but I'm worried it's complicating Saloon a bit.
What are your thoughts? I've placed this feature in an issue here: #46

Going to mark this as closed since we moved it into another issue :bow:


Injest configuration for FeatureDataAdapters should be able to target more than one adapter

Ingest plugins often create multiple adapters/feature types for different sets of data types.
Each one has its own configuration (and name...hint)

In addition, add doc and tests for the other configuration items: secondary indexing, primary index selection, visibility.  Fix any bugs that crop up.


About the Dev section

Create 3 divs for each member:
includes- their name, short introduction, link to github

Will also need the usage section that has short description of how to use the app.

Preliminary set up for this section is done. Needs additional styling.

Styled pages in a way that should suffice for now.
Still need to implement media queries due to adjustments made to images in styles.css


cache bio drafts

Description
Address #1437
Current pr does not cache by user. localStorageBioDraftKey needs user id added in. I am not sure if there is a scheme used for determining local storage keys.
Screenshots

Additional Context

Checklist
Are your changes backwards compatible? Please answer below:

On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:

For frontend changes: Tested on mobile? Please answer below:

Did you introduce any new environment variables? If so, call them out explicitly here:

We have this built into forms already. If you set the storageKeyPrefix to me.id it should do the trick.

@huumn I made new pr #1455  cause the git history on here was so messy. Thanks!

@huumn I believe I was incorrectly paid for this pr.

Appreciate the honesty :)


Update cats-effect, cats-effect-laws to 2.3.3

Updates

org.typelevel:cats-effect
org.typelevel:cats-effect-laws

from 2.1.4 to 2.3.3.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel" } ]

labels: library-update, semver-minor

Superseded by #131.


added gb_xander docs

I closed the code PR because this implementation is incorrect -- it's just an alias. Please open a new docs PR based on other aliased biddercodes when the appnexus alias list update has a PR.


Update documentation to reflect v1.1.0

We can assume this is fixed, as the README (specs) already include the changes/added keys. I'll close this.
Landing page and CONTRIBUTING.md are handled in other issues.


Add experimental mac support and fix compilation if UTF8 support is assumed

This should add experimental mac support and perform the additional fixes necessary in #10
A few changes in the CMakeLIsts.txt are necessary, to change the C style, as well as add an explicit linking to iconv.
On the code side, the most significant change is in the path Path::exe() function, which requires an entirely different codepath on mac.
I have not run the tests, as they seem to be outdated/broken.

Very nice work. It looks good to me and I'm going to merge it. Since I already merged a few other PRs, I think I need to get some cleanup work done on Pathie and do a new release...

I was unable to run the tests, as they seem to not link to the library created. Are they outdated/not used? Let me know if there are any other additional issues.
Cheers,
Nick

I was unable to run the tests, as they seem to not link to the library created. Are they outdated/not used?

The tests work, but they are a little unusual to set up, because you need to tell the test suite the paths on your system that Pathie should be able to figure out correctly (this is for testing functions like Pathie::Path::cache_dir(). The tests also assume you build the source code in a directory build in the project's toplevel directory and have the experimental stream replacements enabled. I agree that I should abstract these two assumptions away (probably part of the next release cleanup).
For now, to run the tests, you'd have to:

Wipe any previous build
Create a directory build in the project root: mkdir build
Configure Pathie with the experimental stream replacements set to ON (otherwise the tests will fail to link): cd build && cmake -DCMAKE_BUILD_TYPE=Debug -DPATHIE_BUILD_STREAM_REPLACEMENTS=ON ..
Build Pathie: make
Switch to the test directory: cd ../test
Create a testsettings configuration: rake testsettings
Edit the generated testsettings.conf file to reflect the directories that Pathie needs to figure out correctly (I know you use a Mac, but for comparison: on a typical Linux this would just mean replacing nobody with your username).
Execute rake

From distant times I remember MacOS does not have LD_LIBRARY_PATH, but uses something different. The Rakefile in the test/ directory uses LD_LIBRARY_PATH to prepend ../build to the shared library load path. You might need to tweak that.
The directory path methods probably don't return the correct results on MacOS either, because on everything Unixish they assume that the XDG specification is followed (example for cache_dir()).
Testing things depending on the system something is run on is a difficult topic.

Further note: I commented into the diff.

Sorry, I can't seem to find your comments.
Yes, that totally explains why the tests didn't pass on MacOS. I'll see if I can change that later tonight or tomorrow. TBH mac is pretty annoying to work with...

Sorry, I can't seem to find your comments.

O_o I really dislike GitHub's diff comment interface. It's so surprising. So when I press that big green must-be-correct "start a review" button, that's not shown to you? Man...
Here's what I commented below this line

Are you sure that Mac compilers do not react to __unix__? I'm actually unsure why I didn't use _PATHIE_UNIX for this ifdef, but I'm still interested in whether __unix__ catches Macs.

Found the problem why you didn't see it. One needs to press another "submit review" button... confused

Yeah, idk, I've never used github's review.
Before I added APPLE there, compilation failed because the #ifdef went to the ERROR PLATFORM NOT SUPPORTED part. It seems logical that it should be captured by Unix, since BSD was derived from unix...

Ah well. Apple doesn't want to make it easy for us. Then it's okay like that. If you don't want to fiddle around with the tests first, I'd merge this now.

I see you have opened an issue for rewriting the tests in a different way. Ping me once you do it, if I still own a mac, I'll add tests for it. I don't really want to go through it now though, sorry (:


change the favicon of the unelma code translator

UnelmaSupport
Hello!
Thanks for getting in touch! This is an automatic email just to let you know that we've received your request and your ticket reference is #544.
One of our support agents will get back to you shortly. Please do not submit multiple tickets for the same request, as this will not result in a faster response time.
View Help Center: https://unelmasupport.com/hc
Regards,
UnelmaSupport
If you’re having trouble clicking the "View Help Center" button, copy and paste the URL below into your web browser: https://unelmasupport.com/hc
© 2024 UnelmaSupport. All rights reserved.


Reg: Astropy Affiliated Package

Being tracked here: https://github.com/astropy/astropy.github.com/pull/306

Closed! :)
EinsteinPy is an Astropy Affiliated Package now :D


zeroscope doesnt work

when i want to generate something i always get
/content/Text-To-Video-Finetuning
seed is<PHONE_NUMBER>90305933
Loading pipeline components...:   0% 0/5 [00:00<?, ?it/s]2024-01-26 10:00:10.608979: E external/local_xla/xla/stream_executor/cuda/cuda_dnn.cc:9261] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-01-26 10:00:10.609030: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:607] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-01-26 10:00:10.610281: E external/local_xla/xla/stream_executor/cuda/cuda_blas.cc:1515] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2024-01-26 10:00:11.660957: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Could not find TensorRT
Loading pipeline components...: 100% 5/5 [00:02<00:00,  2.24it/s]
100% 50/50 [05:50<00:00,  7.02s/it]
Traceback (most recent call last):
File "/content/Text-To-Video-Finetuning/inference.py", line 232, in
export_to_video(video, f"{out_stem} {str(uuid4())[:8]}.mp4", fps)
File "/content/Text-To-Video-Finetuning/train.py", line 118, in export_to_video
img = cv2.cvtColor(video_frames[i], cv2.COLOR_RGB2GRAY)
cv2.error: OpenCV(4.8.0) /io/opencv/modules/imgproc/src/color.simd_helpers.hpp:92: error: (-2:Unspecified error) in function 'cv::impl::{anonymous}::CvtHelper<VScn, VDcn, VDepth, sizePolicy>::CvtHelper(cv::InputArray, cv::OutputArray, int) [with VScn = cv::impl::{anonymous}::Set<3, 4>; VDcn = cv::impl::{anonymous}::Set<1>; VDepth = cv::impl::{anonymous}::Set<0, 2, 5>; cv::impl::{anonymous}::SizePolicy sizePolicy = cv::impl::::NONE; cv::InputArray = const cv::_InputArray&; cv::OutputArray = const cv::_OutputArray&]'

Invalid number of channels in input image:
'VScn::contains(scn)'
where
'scn' is 40

is there a way to fix that

thanks for the info ❤ please try again

eed is<PHONE_NUMBER>745367308
The cache for model files in Transformers v4.22.0 has been updated. Migrating your old cache. This is a one-time only operation. You can interrupt this and resume the migration later on by calling transformers.utils.move_cache().
0it [00:00, ?it/s]
/usr/local/lib/python3.10/dist-packages/diffusers/models/transformer_temporal.py:24: FutureWarning: TransformerTemporalModelOutput is deprecated and will be removed in version 0.29. Importing TransformerTemporalModelOutput from diffusers.models.transformer_temporal is deprecated and this will be removed in a future version. Please use from diffusers.models.transformers.tranformer_temporal import TransformerTemporalModelOutput, instead.
deprecate("TransformerTemporalModelOutput", "0.29", deprecation_message)
/usr/local/lib/python3.10/dist-packages/diffusers/models/transformer_temporal.py:29: FutureWarning: TransformerTemporalModel is deprecated and will be removed in version 0.29. Importing TransformerTemporalModel from diffusers.models.transformer_temporal is deprecated and this will be removed in a future version. Please use from diffusers.models.transformers.tranformer_temporal import TransformerTemporalModel, instead.
deprecate("TransformerTemporalModel", "0.29", deprecation_message)
/usr/local/lib/python3.10/dist-packages/diffusers/models/transformer_temporal.py:34: FutureWarning: TransformerTemporalModelOutput is deprecated and will be removed in version 0.29. Importing TransformerSpatioTemporalModel from diffusers.models.transformer_temporal is deprecated and this will be removed in a future version. Please use from diffusers.models.transformers.tranformer_temporal import TransformerSpatioTemporalModel, instead.
deprecate("TransformerTemporalModelOutput", "0.29", deprecation_message)
/usr/local/lib/python3.10/dist-packages/diffusers/models/transformer_2d.py:20: FutureWarning: Transformer2DModelOutput is deprecated and will be removed in version 0.29. Importing Transformer2DModelOutput from diffusers.models.transformer_2d is deprecated and this will be removed in a future version. Please use from diffusers.models.transformers.transformer_2d import Transformer2DModelOutput, instead.
deprecate("Transformer2DModelOutput", "0.29", deprecation_message)
/usr/local/lib/python3.10/dist-packages/diffusers/models/transformer_2d.py:25: FutureWarning: Transformer2DModel is deprecated and will be removed in version 0.29. Importing Transformer2DModel from diffusers.models.transformer_2d is deprecated and this will be removed in a future version. Please use from diffusers.models.transformers.transformer_2d import Transformer2DModel, instead.
deprecate("Transformer2DModel", "0.29", deprecation_message)
Loading pipeline components...:   0% 0/5 [00:00<?, ?it/s]2024-01-30 20:29:01.373400: E external/local_xla/xla/stream_executor/cuda/cuda_dnn.cc:9261] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-01-30 20:29:01.405383: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:607] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-01-30 20:29:01.553697: E external/local_xla/xla/stream_executor/cuda/cuda_blas.cc:1515] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2024-01-30 20:29:04.513037: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Could not find TensorRT
Loading pipeline components...: 100% 5/5 [00:08<00:00,  1.76s/it]
100% 25/25 [02:57<00:00,  7.11s/it]
Traceback (most recent call last):
File "/content/Text-To-Video-Finetuning/inference.py", line 232, in
export_to_video(video, f"{out_stem} {str(uuid4())[:8]}.mp4", fps)
File "/content/Text-To-Video-Finetuning/train.py", line 118, in export_to_video
img = cv2.cvtColor(video_frames[i], cv2.COLOR_RGB2BGR)
cv2.error: OpenCV(4.8.0) /io/opencv/modules/imgproc/src/color.simd_helpers.hpp:92: error: (-2:Unspecified error) in function 'cv::impl::{anonymous}::CvtHelper<VScn, VDcn, VDepth, sizePolicy>::CvtHelper(cv::InputArray, cv::OutputArray, int) [with VScn = cv::impl::{anonymous}::Set<3, 4>; VDcn = cv::impl::{anonymous}::Set<3, 4>; VDepth = cv::impl::{anonymous}::Set<0, 2, 5>; cv::impl::{anonymous}::SizePolicy sizePolicy = cv::impl::::NONE; cv::InputArray = const cv::_InputArray&; cv::OutputArray = const cv::_OutputArray&]'

Invalid number of channels in input image:
'VScn::contains(scn)'
where
'scn' is 40

STILL GETTING THIS ON EVERY NOTEBOOK


Update or remove architecture diagram

The diagram here is woefully out of date: https://minder-docs.stacklok.dev/developer_guide/architecture

Some things that are missing:

Keycloak (both as a dependency, and reacting to user-deleted events)
OpenFGA (as a dependency, in the gRPC middleware path)
gRPC triggers events on profile change
telemetry logging

There's probably more, but that's a start.


How we can send a telegram premium emoji via WTelegramClient?

hi! Can i send a telegram premium emoji via this client library?

See this example: https://wiz0u.github.io/WTelegramClient/EXAMPLES#reaction


clarify error message when using 'association' helper for nonexistent relationship

How about
`You're using the `association` factory helper on the '${associationAttribute}' attribute of your ${modelType} factory, but that attribute is not a `belongsTo` association. Read the Factories docs for more information.`

I'd love to get a permalink to different parts of docs that's versionless, so we could link right to it.

Sounds much better, I like it 👍
I don't think it's possible currently to get a permalink like that, but http://www.ember-cli-mirage.com/docs/v0.2.x/factories/#factories-and-relationships should be good enough here, at least for now.

rebuilding master to see if the problem is there

@samselikoff All tests are passing now, sounds good to merge?

Yessir go for it
On Tue, Jan 17, 2017 at 7:26 AM Ricardo Mendes<EMAIL_ADDRESS>wrote:

@locks approved this pull request.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/samselikoff/ember-cli-mirage/pull/981#pullrequestreview-16979620,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACyXCrukLO-FghrUptzZLuDoGI1TRCFjks5rTLN-gaJpZM4LgrGU
.

💪


SFTP - Enable keys

Description

Renamed Flexion-flavored env vars and/or secrets to use ca-phl as part of the name to create a consistent pattern
Turned on using-keys-for-SFTP

Issue
https://github.com/CDCgov/trusted-intermediary/issues/1153
Checklist

[x] I have added tests to cover my changes
[x] I have added logging where useful (with appropriate log level)
[x] I have added GoDocs where required
[x] I have updated the documentation accordingly

Note: You may remove items that are not applicable

I think all that this PR needs is that readme about the credentials created and fleshed out and figuring out why the PR environment fails to deploy.  Everything else works.  There are other tasks in story #1153, but those can be in a different PR.

Approved pending the one outstanding question in docker-compose

Confirmed that commented it back out continues to work.


Pattern Matching

Won't merge until the compiler implementation is done (haven't started it yet).
Example:
x = match z:
  | < 2: "less than two"
  | > 3 and < 10: "between three and ten"
  | 2: "equal to two"
  | 3 or 10: "equal to three or ten"
  | "hello" or "goodbye": "its a greeting"
  | instanceof MyClass: "its a MyClass instance"
  | ~isFunction() and instanceof OtherClass: z()
  | ~isFunction() with f: f()
  | ~isObject() and .x and .y with { x, y }: x + y
  | ~isArray() and [0] with [ first, ...rest ]: [...rest, first]
  | /f([oO]+)/ or /b([aA]+)(r)+/ with [ fullRegMatch, ...parts ]: match parts.length:
    | 0: "no paren groups matched (not possible here)"
    | 1: `found an o: ${parts.0}`
    | 2: `found an a and r: ${parts.0} ${parts.1}`
  | else: "none of the above"

This also should be preceded by outlawing of naked decimals (enforcing 0.123 instead of .123) and removing all bitwise operators from ordinary use.

(significant pertinent discussion has been occurring on this thread)

Branching from the above, @wcjohnson, I'm considering moving from with to as for renaming/destructuring:
incremented = match x:
  | 1 as one: one + 1
  | 2 as two: two + 1
  | ~isObject() as { number }: number + 1

note that as is used as a keyword in imports, but it is not a reserved word, so syntax like this needs to be supported (which should be trivial):
match x:
  | as as as: as

I feel good about where the syntax/parsing is at now. My biggest concern with the syntax is that the indentation is a bit shallow:
fooBar = match barFoo:
  | "foo":
    "foo!"
  | "bar" or
    "baaar" or
    "barr":
      "bah!"

it's a little hard to distinguish between tests and consequents, visually.
changing to, eg, case instead of | could help:
fooBar = match barFoo:
  case "foo":
    "foo!"
  case (
    "bar" or
    "baaar" or
    "barr"
  ):
    "bah!"

(at least the start of the consequent wouldn't line up exactly with the start of the test, which happens now).

I agree that the fact that the delimiter is 2 characters long creates an unfortunate situation with indent alignment, but I also like the concision and visual flow of |. Going to case might be just as unfortunate. Tough call here.

Actually, looking at the example above, I like the case a lot more – you? @citycide you around to comment?

Copping a few more examples:
export toStatement(body) ->
  t = getTypes()
  match body:
    | ~isa("Expression"):
      buildAtLoc(getLoc(body), t.expressionStatement, body)
    | else: body

export toFunctionBody(body) ->
  match body:
    | ~isa("Expression"): body
    | else: toBlockStatement(body)

would become
export toStatement(body) ->
  t = getTypes()
  match body:
    case ~isa("Expression"):
      buildAtLoc(getLoc(body), t.expressionStatement, body)
    default: body

export toFunctionBody(body) ->
  match body:
    case ~isa("Expression"): body
    default: toBlockStatement(body)

Other examples might make | look better, though:
export toBlockStatement(body) ->
  t = getTypes()
  bodyLoc = getLoc(body)
  match body:
    | ~isa("BlockStatement"): body
    | ~isa("Statement"): buildAtLoc(bodyLoc, t.blockStatement, [body])
    | else: buildAtLoc(bodyLoc, t.blockStatement, [
        buildAtLoc(bodyLoc, t.expressionStatement, body)
      ])

export blockToExpression(path) ->
  t = getTypes()
  node = path.node
  match node:
    | ~isa("BlockStatement"):
      path.canSwapBetweenExpressionAndStatement = () => true
      // XXX: source maps - this code is inside babel and makes unmapped
      // nodes.
      path.replaceExpressionWithStatements(path.node.body)
      path.node
    | ~isa("FunctionDeclaration"):
      // Special case: the parser promotes a block consisting of a single declaration
      // from ExprStatement(FunctionExpr) to FunctionDeclaration. Convert back to
      // expression here.
      nextNode = t.clone(node)
      if nextNode.type === "NamedArrowDeclaration":
        nextNode.type = "NamedArrowExpression";
      else:
        nextNode.type = "FunctionExpression";
      nextNode
    | ~isa("ExpressionStatement"):
      node.expression
    | else:
      node

case versions of the above:
export toBlockStatement(body) ->
  t = getTypes()
  bodyLoc = getLoc(body)
  match body:
    case ~isa("BlockStatement"): body
    case ~isa("Statement"): buildAtLoc(bodyLoc, t.blockStatement, [body])
    default: buildAtLoc(bodyLoc, t.blockStatement, [
        buildAtLoc(bodyLoc, t.expressionStatement, body)
      ])

export blockToExpression(path) ->
  t = getTypes()
  node = path.node
  match node:
    case ~isa("BlockStatement"):
      path.canSwapBetweenExpressionAndStatement = () => true
      // XXX: source maps - this code is inside babel and makes unmapped
      // nodes.
      path.replaceExpressionWithStatements(path.node.body)
      path.node
    case ~isa("FunctionDeclaration"):
      // Special case: the parser promotes a block consisting of a single declaration
      // from ExprStatement(FunctionExpr) to FunctionDeclaration. Convert back to
      // expression here.
      nextNode = t.clone(node)
      if nextNode.type === "NamedArrowDeclaration":
        nextNode.type = "NamedArrowExpression";
      else:
        nextNode.type = "FunctionExpression";
      nextNode
    case ~isa("ExpressionStatement"):
      node.expression
    default:
      node

In terms of syntax only I lean toward case because this situation I think the clarity wins over the terse. The conciseness of | is appealing but I don't know if it's that appealing.
Here's another thing though, do you think the familiarity of match with case to switch statements would be a benefit or could it end up being confusing?
Maybe consider using else instead of default - it's symmetrical with ifs and aligns vertically with case ?

Definitely seems that | looks better with one-liners.
Also definitely think I agree that else looks better than default here. Updating examples to reflect that...
I am somewhat concerned that case's familiarity to switch might be confusing...

Another possibility would be to allow either, but I think this feature is dizzying enough as it is.

In super-simple cases like this:
  match body:
    | ~isa("Expression"): body
    | else: toBlockStatement(body)

I can see the | being nice enough that developers might choose it over an if; with case, it might tilt the balance juuust enough to write if instead:
  if body~isa('Expression'): body
  else: toBlockStatement(body)

I don't think that's necessarily a bad thing; match is super great, but idk if it should really be used for every conditional.

I would characterize that particular example (or more generally, branching on the type of something) as an ideal case for using match over if.

Probably going to let this simmer for a bit while I implement the compiler bit for the feature.

@wcjohnson interesting – things like that were why I hesitated to build match in the first place – with convenient elif expressions, who needs it? But I definitely see how clear it makes the code: "we have this thing, now depending on its attributes, we will return different results".

I haven't read the whole thread (apologies), but I would find it simpler to reason if the matching expression was applied somehow to the value in question. Having > 1 and < 10 to me is less clear than a range 1.. or ..10.
e.g. if it's a range, true if val is in the range (add concept of "open" ranges like 10..?). If it's a regex, true if val matches regex. If it's a class, true if the val is a descendant of that class.

(Jon's a friend I'm meeting up with soon)
Just pushed a commit that allows both | and case so they can be played with, will probably choose one option (or something not yet thought of) later.

@JonAbrams I think classes & RegExps already work the way you're talking about:
result = match value:
  | instanceof Foo: `it's a Foo!`
  | /^hello$/: `it's a greeting!`
  | /^bye$/: `it's a farewell!`

I think the current < / > syntax is fine also - the value basically just becomes the left side of the binary operator in there. Having syntactic ranges would be a whole other story.

Just pushed a commit that allows both | and case so they can be played with, will probably choose one option (or something not yet thought of) later.

Definitely think we should have just one only but this will be good to mess with.

Actually, while we're on the subject of RegExps, I'm currently compiling them into .test:
  elif is("RegExpLiteral", testNode):
    // /^regexp/.test(ref)
    // XXX: let consequent see the match results? this could be something like:
    // _ref2 = ref.match(/^regexp/); consequent(_ref2);
    buildAtLoc(testNodeLoc, t.callExpression,
      buildAtLoc(testNodeLoc, t.memberExpression,
        testNode, buildAtLoc(testNodeLoc, t.identifier, "test")
      )
      [discriminantRef]
    )

But it may be better to have special-case code that compiles it into .match and then passes the match object to the consequent if there are any matches. (In fact I think @rattrayalex may have said this at some point though I can't find it)
That would, of course, add additional complexity to the construct (now devs have to remember that regexps are special cases) but the full match object would make matching on regexps way more powerful.

Coming back to this, the aesthetics of | are hard to beat, especially in shorter scenarios (which should be encouraged).
My biggest concern with it is multiline conditionals, which would be especially confusing:
match x:
  | ~someLongNamedFn(otherArg, otherOtherArg) or
  ~someOtherLongNamedFn(otherArg, otherOtherArg) or
  ~someOtherOherLongNamedFn(otherArg, otherOtherArg):
    doSomeLongNamedFnThing(x, otherArg, otherOtherArg)
  | ~someLongNamedFn(otherArg, otherOtherArg)
  or ~someOtherLongNamedFn(otherArg, otherOtherArg)
  or ~someOtherOherLongNamedFn(otherArg, otherOtherArg):
    doSomeLongNamedFnThing(x, otherArg, otherOtherArg)
  | ~someLongNamedFn(otherArg, otherOtherArg) or
    ~someOtherLongNamedFn(otherArg, otherOtherArg) or
    ~someOtherOherLongNamedFn(otherArg, otherOtherArg):
      doSomeLongNamedFnThing(x, otherArg, otherOtherArg)
  | (
    ~someLongNamedFn(otherArg, otherOtherArg) or
    ~someOtherLongNamedFn(otherArg, otherOtherArg) or
    ~someOtherOherLongNamedFn(otherArg, otherOtherArg)
  ):
    doSomeLongNamedFnThing(x, otherArg, otherOtherArg)

Of those, I like the 2nd and 4th best, personally... but 2nd clashes with the way most people do multiline conditionals now (at least, how prettier does it). 4th is a little ugly (| (, ehh) but matches the recommended multiline if style.
So as long as there's a style which assuages this, I think I feel okay about it. Hopefully a linter/formatter enforces one style in the future.

(apologies for the deluge)
...another option would be to go back to -> instead of :, which has far more visual "pop".
We left that because of the , -> redundancy – the comma was annoying, but necessary because of situations like this: | x -> x + 1, which would be parsed as, "does this match a function with param x that returns x plus one?". Hence the annoying comma.
However, by disabling function syntax in match-test's, which wouldn't make any sense anyway, this could be lifted, allowing comma-free syntax.
That would still leave the problem of how to rename/destructure params, and I think with would still be appropriate:
match x:
  | y with z -> z + 1

This would be moderately messy in the parser, but not the end of the world – two or three places, I think, where if (this.state.inMatchCaseTest) return false would need to be added.
Hackier (but less messy) would be the fact that the -> wouldn't be a real function at all – the code for parsing it would look something like this:
if (this.eat(tt._with)) {
  node.binding = this.parseBindingAtom();
}
this.expect(tt.arrow); // TODO: how to handle -*> etc – disallow? what about => vs -> ?
if (this.isLineBreak()) {
  node.consequent = this.parseStatement(false);
} else {
  node.consequent = this.parseMultilineWhiteBlock(...);
}

This would allow for slightly surprising (but, I think, desired) behavior in MatchStatements, like this:
f() ->
  match x:
    | y ->
      if blah: return
  foo() // not reached if x == y && blah

I definitely agree there's an issue with some of that multiline test expression formatting, and I think having a consistent style guide between match and if (i.e. option 4) is one way out of the bind.
-> is a symbol I don't think should be overloaded to have other meanings. Any time I read an -> I think "I am making a function here." One of the reasons I think : is good there is because : has the same standard meaning of "initiating a block" that it has everywhere else, and the general syntax is consistent with IfExpressions.
I also don't love making up new kinds of arrows. Already I think things like -*/> are confusing (I'll bet you a lot of money programmers forget whether it's -/*> or -*/> and have to rely on a live linter to remind them. Fortunate that we have one of those.) I think runic languages in general make programmers fill limited head space with remembering what all the runes mean.
Out of the available options, I think a recommended style for multiline test expressions is better than the others. If that isn't sufficient to solve the issue to everyone's satisfaction, then I myself prefer going to case to any of the other options so far.

I agree on all @wcjohnson 's points there.
Have you come across Brian Terlson's strawman proposal for JS? Without saying any particular way is better yet, it's very different from this but probably worth a look if you haven't. It's an alternative switch body basically.
https://gist.github.com/bterlson/da8f02b95b484cd4f8d9#file-patternmatching-md

Another possible style:
match x:
  | ~test1()
    or ~test2()
    or ~test3():
      result

I hadn't seen that proposal before, thanks for pointing it out. Worth considering for sure. The Symbol.matches and whole-object-matching bits are interesting.
I think the point about not overloading -> is a good one.
Sounds like there's no enthusiasm for |> which isn't too surprising.
Will probably stick with | and : though remain somewhat concerned about visibility.
The power of destructuring before the test is appealing, though, which might change the grammar... In general, being able to match on multiple values would be great. ~isObject() and .x and .y with { x, y }: is unfortunate (especially with longer property names or nesting).

I'd say |> is too closely associated with a chainable pipe operator to be used here. I'm in line with what @wcjohnson said earlier:

Out of the available options, I think a recommended style for multiline test expressions is better than the others. If that isn't sufficient to solve the issue to everyone's satisfaction, then I myself prefer going to case to any of the other options so far.

So | + : is good if we can either enforce or strongly recommend a certain style, otherwise case. The style I think is best is this one:
/* ... */
  | (
    ~someLongNamedFn(otherArg, otherOtherArg) or
    ~someOtherLongNamedFn(otherArg, otherOtherArg) or
    ~someOtherOherLongNamedFn(otherArg, otherOtherArg)
  ):
    doSomeLongNamedFnThing(x, otherArg, otherOtherArg)

Don't like to make big course corrections when this far along, but I think we could implement the destructure-as-match-test without too much syntax change. Something like:
match x:
  | with { a, b } when a > 2: `a is a large ${a} and b is ${b}`

which would compile to include an additional assertion that x matches the destructuring pattern, and apply the destructuring pattern before implementing the when part of the test.

Yeah, something like that could work, but I think makes other things worse.
What about just
match x:
  | { a, b } and a > 2: ...

That makes arrays-vs-computed-properties hard, though, and I have no idea
what it'd compile to..
On Fri, Jun 2, 2017, 11:01 William C. Johnson<EMAIL_ADDRESS>wrote:

Don't like to make big course corrections when this far along, but I think
we could implement the destructure-as-match-test without too much syntax
change. Something like:
match x:
| with { a, b } when a > 2: a is a large ${a} and b is ${b}
which would compile to include an additional assertion that x matches the
destructuring pattern, and apply the destructuring pattern before
implementing the when part of the test.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lightscript/babylon-lightscript/pull/17#issuecomment-305867074,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq_LrPMTEIrh0NVXfOdkBiP5Sfjyr7sks5sAE3rgaJpZM4NG3EQ
.

Yeah, I'm looking more closely at it and in fact some of the destructuring pattern stuff in that strawman is actually illegal syntax right now (like a RestElement without an Argument) -- due to that I think this should be regarded as a longer term separate proposal from the current pattern matching proposal.

Right, but there's little doubt that patterns would be really useful,
right? I think in elixir that's almost the primary use of pattern
matching...
On Fri, Jun 2, 2017, 11:15 William C. Johnson<EMAIL_ADDRESS>wrote:

Yeah, I'm looking more closely at it and in fact some of the destructuring
pattern stuff in that strawman is actually illegal syntax right now (like a
RestElement without an Argument) -- due to that I think this should be
regarded as a longer term separate proposal from the current pattern
matching proposal.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lightscript/babylon-lightscript/pull/17#issuecomment-305870797,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq_Li6THRgijtd3nQtsWk6JV67VAv95ks5sAFFLgaJpZM4NG3EQ
.

No doubt that a terse syntax for implicit destructuring with an assertion that the object matches the destructure would be extremely useful.

Alright, here's what I have (very much open to changes):

you can destructure anywhere in a match-case-test, but only once.
destructuring can include "required variables", default values, nesting, spreads, etc.
if you do not destructure, you can rename the ref to a single variable, using as (not with)

it feels fairly hacky and will require quite a bit of rewriting in the compiler level. For example, the object/array "patterns" are actually object/array expressions, the "default values" are actually AssignmentExpressions, etc.
However, the compiler is going to be a ton of work anyway, so :man_shrugging:
eg;
match x:
  | { a, b } and a > b: a + b
  | { a, b }: a - b
  | { b = 1, c: 'required value for c', ...d }: d~merge(b)
  | [ 'a', b, ...rest ] and .length > 10: rest.concat([b])
  | [ a = 1, b = 2 ]: a + b
  | [a, b] as arr: 'error!'
  | {a, b} or [a, b]: 'error!'
  | ~isNumber() as num: num + 1

thoughts?

I don't think we can use hasOwnProperty there. Destructuring supports prototypical properties, so an assertion that an object matches a destructure should do so as well.

I think we should try to use BindingAtoms for the destructure. They wouldn't support the equality assertions on individual destructure variables, but I think those assertions should be broken out to a separate clause anyway. Using ObjectExpressions leaves a lot of room for weird edge cases and creates a lot more error-prone work on the compiler backend.

Counter-proposal:
match [discriminant: Expression] :
| ([unboundTest: Expression]) (with [binding: BindingAtom] (when [boundTest: Expression)) : [consequent: Block]
...

The unboundTest is run with the discriminantRef replacing the PlaceholderExpressions.
If true, and there is a with binding, assertStructureCompatibility(discriminantRef, binding) is called, where that is an algorithm similar to what you describe above.
If there is a with, variable bindings are created by doing the equivalent of [binding] = discriminantRef
If there is a when, the boundTest is run in a context where the variable bindings are available.
If that passes as well, the consequent is run in the same context.

Examples from above, ported:
match x:
  | with { a, b } when a > b: a + b
  | with { a, b }: a - b
  | with { status, message } when status == "ok": message
  | with { status, message = "error :-(" } when status == "error": throw new Error(message)
  | with { b = 1, c, ...d } when c == "required value for c": d~merge(b)
  | with [a, b, ...rest ] when .length > 10 and a == "a": rest.concat([b])
  | with [ a = 1, b = 2 ]: a + b
  // | [a, b] as arr: 'error!'
  // | {a, b} or [a, b]: 'error!'
  | ~isNumber() with num: num + 1

Miscellaneous thoughts:

The user may not want the destructure to actually be assertive. If it is preceded by a type assertion that guarantees the destructure will work, then the assertion is just extraneous code. Eg:

match x:
  ~isWidget() with {price, color}: `${color}: ${price}`

If I know every widget has a price and color, I don't want extra code being generated there to check for those.

MatchExpressions may have to be lifted into IIFEs by default in order to support variable bindings in the tests themselves rather than just in the consequents. (Alternatively, it may be possible to lift the bindings up-scope to refs, but that seems kind of ugly.)

Interesting stuff.
I'd also considered | { a, b }, conditional: and | conditional, { a, b } as options, which is essentially the same thing but fewer words. Probably too concise, and having multiple ways of destructuring sort of rubbed me the wrong way.
the point about not wanting to check for keys is interesting... I don't think it should be too much of a problem, but I do like the idea of being able to omit that. You're right about hasOwnProperty; should be prop in _ref, which is concise (and I think cheap) enough that codegen shouldn't be prohibitive.
with and when are a bit verbose... not sure I see the advantages there.
I think there's two primary suggestions you're making:

allow destructuring before and after the test, and when it's after, don't check props.
use ObjectPattern/ArrayPattern instead of ObjectExpression/ArrayExpression, and enforce property value checks to be explicit.

Both could be accomplished with the above syntax, and I'll think about them. Being able to match on things like ['err', msg]seems like a big part of the feature in Elixir, and I could see that being useful. That being said, I'm not sure if it has that much of an advantage over | {status, message} and status == 'err':.
Okay, so I think I like ObjectPattern/ArrayPattern better – will amend to use that, and correspondingly disallow { status: 'err', message }.
Heck, will also allow destructuring in the as clause, why not. And sure, can compile such that prop in _ref tests aren't run for those.
Sound good? Are there major reasons to prefer with and when in that world?

My preference for with and when is based on readability -- as you mentioned before, the word as just makes less sense there. You match something with something, not as something.
I also think there should be a bit more structure to the syntax, and I think the (unbound test) delimiter (pattern) delimiter (bound test) is a good way of structuring it. It flows in the same direction/order as the generated code would.
That being said, I'm not married to with and when for any technical reasons; I don't have any strong objections to as or other symbols (except the objections I raised to reusing ->)

Cool. My hunch is that renaming won't be that common; having a single destructure check is probably more typical.
eg; this could become:
  match caseNode:
    | { functional, consequent }:
      callExpr = t.callExpression(toFunctionBody(consequent), [discriminantRef])
      if isExpression: callExpr
      else: t.expressionStatement(callExpr)
    | { binding, consequent }:
      if isExpression: bindingToFunctionCall(binding, consequent, discriminantRef)
      else: bindingToAnonymousBlock(binding, consequent, discriminantRef)
    | { consequent }:
      if isExpression: blockToExpression(casePath.get("consequent"))
      else: toStatement(consequent)

and if you wanted the last one to run even with an empty object (or at least, an object with no consequent prop), you could just do { consequent = null }

Yes, I do like the look of that, and I think that case is worth optimizing for.
I also expect | ~someTest() with { somePattern } : ... to be very common, as well as | with {someElement} when someCondition(someElement): ...

Both could also be written:
| ~someTest() and { somePattern }: ...
// or, for non-prop-testing,
| ~someTest() as { somePattern }:

and
| { someElement } and someCondition(someElement):

which frankly I think are a bit clearer.
To clarify on the move to as from with, in an environment where destructuring could occur earlier, I got the feeling that as was much clearer that it was merely renaming a variable, whereas with felt like more of a modification/refinement... obviously not a big deal, though, and very easy to change later as we get more of a feel for this feature.
(on that note, as much terrific discussion as we're having now, this seems like one of those features that we'll have to see in the wild a bit before finalizing, and should be considered very much subject to change)

By the way, (this doesn't affect parsing), I'm also thinking more about "auto-instanceof" for ClassCased variables, eg;
y = match x:
  | String as s: s+'!'
  | Number as n: n+1
  | Array as arr: arr.concat(1)
  | FooClass as foo: foo.bar()

becoming
const y =
  typeof x === "string" ? (s => s+'!')(x) :
  typeof x === "number" ? (n => n+1)(x) :
  x instanceof Array ? (arr => arr.concat(1))(x) :
  x instanceof FooClass ? (foo => foo.bar())(x) :
  null // to null or throw, that is the question...

Points of agreement so far:*
I'm totally fine with as over with, that's a nontechnical preference.
Very much in agreement with this syntax for the "base destructuring"/most common case:
match x:
  | { assertiveDestructure}: "result"

So in terms of my syntax proposal, allow dropping with when we see a binding pattern.
Points of contention:*
Not thrilled about the use of and there. It looks like a logical operator to me and feels pretty jarring to see it doing something that has nothing to do with conditional logic.
Compare:
| { someElement } and someCondition(someElement):

| { someElement } when someCondition(someElement):

I think the latter is better.

Regarding auto-instanceof, my input would be that I kind of like it (especially the String/Integer typecases) , but on the other hand, I think we just at least doubled the cognitive burden associated with using and remembering all the intricacies of pattern matching with this latest round of proposals. There's a LOT going on here now.

Nice, well spelled out!
oh, but it is the logical operator 😉  that's the beauty of it. You could also do things like | someFlag == true and { prop } and prop > 3: - it stands in for "check that this has these properties, and destructure them".
that said, I see your point, and will keep that alternative in mind if people find this confusing.
Agreed about the dangers of cognitive overload, though in the String/Number situation, people who have come from other languages with matching are probably accustomed to that feature. Definitely need to be vigilant about (and probably scale back) the number of capabilities here...

So if I want to test the discriminant, non-assertively destructure, then test one of the bound vars, what do I write? Would it be
| ~isWidget() as {price, color} and price == 2.50: "two fiddy"

no, you wouldn't be able to do that, which I think makes sense, because price would be "unsafe", and color would not exist.
... the more I think about it, the more I think non-assertion should be opt-in, which is easy with { price = null, color = null }... I actually really don't see much of a case for a destructured as...

Both price and color are safe, because ~isWidget() is standing in for a test that checks that the thing is a valid widget and therefore has those fields set. That's the whole point of the non-assertion as I see it; it's the programmer saying "I don't want you to generate check code because I've already done the checks."

hmm, k. I guess I just don't currently see that as such a problem, but open to being proven wrong.
If it's a performance concern (seems questionable), can always use { prop = null }. If it's the prettiness of the output code, I'll wait and see... if it's really ugly, no harm in adding a destructured as.

plugin PR at https://github.com/lightscript/babel-plugin-lightscript/pull/22

Jumping in late to this discussion, but can I throw this in please?
How about omitting any symbol (like | or when) preceding the test? Since match already implies “Here follows a list of conditions and consequents:” the |  is redundant; and reading the code examples above, in most cases if you omit the |  at the start of each test the meaning would still be clear:
x = match z:
  < 2: "less than two"
  > 3 and < 10: "between three and ten"
  2: "equal to two"
  3 or 10: "equal to three or ten"
  "hello" or "goodbye": "its a greeting"
  instanceof MyClass: "its a MyClass instance"
  ~isFunction() and instanceof OtherClass: z()
  ~isFunction() with f: f()
  ~isObject() and .x and .y with { x, y }: x + y
  ~isArray() and [0] with [ first, ...rest ]: [...rest, first]
  /f([oO]+)/ or /b([aA]+)(r)+/ with [ fullRegMatch, ...parts ]: match parts.length:
    0: "no paren groups matched (not possible here)"
    1: `found an o: ${parts.0}`
    2: `found an a and r: ${parts.0} ${parts.1}`
  else: "none of the above"

Whatever syntax is decided on regarding with, when and as or , in the test expressions would work with this, wouldn’t it, since the indentation itself would be enough to continue the match block.

Hi @DuncanMacWeb , thanks for pitching in!
Given the direction the TC39 pattern-matching proposal is headed, it's very likely that syntax will be adopted in LightScript as well.
I'm currently waiting to see how that proposal shakes out before taking further action here.

@rattrayalex good plan, keeping LightScript as close as possible to JS — keeps the learning curve shallow for developers from a JS background 👍


How do the contribution circle calculated?

Hi
I am not a front-end guy so I was really surprised when I see my circle here. Most of my repos are for Python and Jupyter-notebook. I really have no idea why the other part and html part took so much space.
Could you shed some light on how those contributions are calculated?
Thanks a lot!

To make some contract, contribution statics from another tool is like this, which seems more fit to my status.

Hi dukechain2333. Thanks for visiting my repository.
What this chart represents is which languages your commits over the past year have contributed to.
It does not represent the language used in your repository.
Each commit has a target repository.
Each repository has a primary language.
Each commit is calculated as a contribution to the primary language of the target repository.
This information is retrieved via GitHub's GraphQL API.
The query is as follows:
query {
  user(login: "dukechain2333") {
    contributionsCollection {
      commitContributionsByRepository(maxRepositories: 100) {
        repository {
          nameWithOwner
          primaryLanguage {
            name
          }
        }
        contributions {
          totalCount
        }
      }
    }
  }
}

Results are as follows (public only):
{
  "data": {
    "user": {
      "contributionsCollection": {
        "commitContributionsByRepository": [
          {
            "repository": {
              "nameWithOwner": "enligencelab/enligencelab.github.io",
              "primaryLanguage": {
                "name": "HTML"
              }
            },
            "contributions": {
              "totalCount": 224
            }
          },
          {
            "repository": {
              "nameWithOwner": "dukechain2333/dukechain2333",
              "primaryLanguage": null
            },
            "contributions": {
              "totalCount": 179
            }
          },
          {
            "repository": {
              "nameWithOwner": "dukechain2333/BigData-Develop-Course",
              "primaryLanguage": {
                "name": "Scala"
              }
            },
            "contributions": {
              "totalCount": 4
            }
          },
          {
            "repository": {
              "nameWithOwner": "enligencelab/.github",
              "primaryLanguage": null
            },
            "contributions": {
              "totalCount": 3
            }
          },
          {
            "repository": {
              "nameWithOwner": "dukechain2333/IBM-Data-Science-Certificate-Capstone",
              "primaryLanguage": {
                "name": "Jupyter Notebook"
              }
            },
            "contributions": {
              "totalCount": 3
            }
          },
          {
            "repository": {
              "nameWithOwner": "dukechain2333/BigData-Develop-Course-ShortPeriod",
              "primaryLanguage": {
                "name": "Scala"
              }
            },
            "contributions": {
              "totalCount": 3
            }
          },
          {
            "repository": {
              "nameWithOwner": "dukechain2333/TranslHero",
              "primaryLanguage": {
                "name": "Python"
              }
            },
            "contributions": {
              "totalCount": 3
            }
          },
          {
            "repository": {
              "nameWithOwner": "dukechain2333/EasyVocab",
              "primaryLanguage": {
                "name": "HTML"
              }
            },
            "contributions": {
              "totalCount": 3
            }
          },
          {
            "repository": {
              "nameWithOwner": "dukechain2333/HBase-Develop-Course",
              "primaryLanguage": {
                "name": "Java"
              }
            },
            "contributions": {
              "totalCount": 2
            }
          },
          {
            "repository": {
              "nameWithOwner": "dukechain2333/OperationDash",
              "primaryLanguage": {
                "name": "Python"
              }
            },
            "contributions": {
              "totalCount": 1
            }
          },
          {
            "repository": {
              "nameWithOwner": "dukechain2333/BaiduTranslate-Terminal",
              "primaryLanguage": {
                "name": "Python"
              }
            },
            "contributions": {
              "totalCount": 1
            }
          },
          {
            "repository": {
              "nameWithOwner": "liyupi/rubbish-yingxiaohao",
              "primaryLanguage": {
                "name": "JavaScript"
              }
            },
            "contributions": {
              "totalCount": 1
            }
          }
        ]
      }
    }
  }
}

Repo
Contrib
Lang

enligencelab/enligencelab.github.io
224
HTML

dukechain2333/dukechain2333
179
null

dukechain2333/BigData-Develop-Course
4
Scale

enligencelab/.github
3
null

dukechain2333/IBM-Data-Science-Certificate-Capstone
3
Jupyter Notebook

dukechain2333/BigData-Develop-Course-ShortPeriod
3
Scala

dukechain2333/TranslHero
3
Python

dukechain2333/EasyVocab
3
HTML

dukechain2333/HBase-Develop-Course
2
Java

dukechain2333/OperationDash
1
Python

dukechain2333/BaiduTranslate-Terminal
1
Python

liyupi/rubbish-yingxiaohao
1
JavaScript

That helps a lot. Thank you


Stop working after Error: image not found

After watchtower tries to pull an image that is not able to find (for example an image locally builded) it is not able to go on scanning the following images in the list.
So in the log I have
time="2016-12-04T22:34:24Z" level=info msg="Checking containers for updated images"
time="2016-12-04T22:34:24Z" level=debug msg="Retrieving running containers"
time="2016-12-04T22:33:41Z" level=debug msg="Pulling localimage:latest for /test-container"
Error: image library/localimage:latest not found
time="2016-12-04T23:24:24Z" level=info msg="Checking containers for updated images"

Fixed with c4efc838757aff437b22c07c85be29761974eb72


Catastrophic loss of parallelism at low sampling rates

Render a scene with a low number of samples/pixel, e.g. 4 spp. On my 6-core/12-thread machine, rendering seems to be effectively using a single core. It looks as if parallelism is killed by the display of rendered tiles in Blender.

I ran a render with 1spp and I was seeing 100% CPU utilization.

Franz is there a reason to keep this one open?  I haven't been able to reproduce it.

Let's close it.
Thanks for the housekeeping :)


Fix sqlite_version() out of bound panics

#560
Changes to translate_expr function:

core/translate/expr.rs: Changed the amount parameter in the Insn::Copy instruction from 1 to 0.

Enhancements to the testing framework:

testing/scalar-functions.test: Added a new test do_execsql_test_regex to validate that the sqlite_version function returns a valid output.
testing/tester.tcl: Introduced a new procedure do_execsql_test_regex to support regex-based validation of SQL outputs.

Thanks @diegoreis42!


Updated code to handle the same record type name of two different packages

If you have two packages installed and they contain the same record type (same name and api name, but other package prefix), only one of them is in the currentRecordTypeMap (will be overwritten). SObjectType and DeveloperName are not unique, I changed it to the NamespacePrefix + DeveloperName.

@sabrinaGruber thanks so much!


Wikigeeks: Round starts over from article-selection in the middle of the round

Was trying to reproduce #190 in a 4-player game. Clicked "back" and then "forward", doing a cycle a couple of times until refreshing caused the iPad to get kicked from the game for "inactivity."
After starting to do the same on the iPhone 4, ALL devices switched to starting article selection momentarily, before going back to their respective articles.
Refreshing it one more time caused the hub screen to move to "choose a starting article about" screen, and ALL devices moved to starting article submission, even those that hadn't been back-forward-refreshed.

@mattwbenson when the game refreshed the main screen, at what state was the players in? Did the game already move into the "find the revealed article" ? or was this during the first two minutes?
#179 #189 #190

The game was in the "find the revealed article" state


Parse emphasis in indented code

This will allow * and _ to be recognized inside indented code blocks.
As a bonus, both formatters have cleaner indented code handling.

Hey,
Postponing this merge might actually be a good idea.
I recently made some progress at enabling support for extensions, and this definitely feels like one.

Reimplemented as a custom extension.


KAFKA-10332: Update MM2 refreshTopicPartitions() logic

Trigger task reconfiguration when:

topic-partitions are created or deleted on source cluster
topic-partitions are missing on target cluster

Co-authored-by: Mickael Maison<EMAIL_ADDRESS>Co-authored-by: Edoardo Comar<EMAIL_ADDRESS>Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

cc @ryannedolan

@kkonstantine @rhauch can you take a look?


Get-WmiObject not recognized in Powershell 7.

Describe the bug
I was testing the script in a Windows 10 22H2 Testing VM. I had been using Powershell 5.1 (default to Windows 10 22H2) and decided to test in Powershell 7 to see if I got the same result, and got this error that I hadn't seen in Powershell 5.1.
To Reproduce
Steps to reproduce the behavior:

Run the winutil.ps1
Error appears for $gpuInfo

Expected behavior
Expected no error.
Screenshots

Additional context
Hitting enter after the error allows the script to continue, seemly unharmed. This was while testing in a Windows VM.

Windows 10 (22H2) Fresh Install
Been working on a couple changes in the Winget Installer side of things, when I came across this bug.
I believe I saw the $gpuInfo part added as a pull request by Chris recently.
If I try to call Get-WmiObject outside of the script, it isn't recognized in Powershell 7.

After a little research, I may suggest using Get-CimInstance as a fallback.  Get-CimInstance -query "SELECT * from Win32_VideoController" will return similar information.

The Current commit wasn't a full fix, it references the incorrect class. @YusufKhalifadev is working on a fix, then will close after merged.

made a pr about this


execute on header value Generates assertThat() instead of method call

This worked in version 1.2.4. Does not in 2.0.1:
...
response {
    status 201

    headers {
      // pass the value of the location header to the test for validation
      header('location', producer(execute('assertLocation($it)')))
    }
  }

results in:
error: 'void' type not allowed here

assertThat(response.header("location")).isEqualTo(assertLocation(response.header("location")));

It used to call the assertLocation(value of location header) in the base class. Am I doing it wrong?

assertThat(response.header("location")).isEqualTo(assertLocation(response.header("location")));
It's exactly doing the same thing.
assertLocation($it) -> assertLocation(response.header("location"))
How would you want this to behave?

ah I see, you say that
assertThat(response.header("location")).isEqualTo(assertLocation(response.header("location")));
should be
`assertLocation(response.header("location"));

I have the culprit - https://github.com/spring-cloud/spring-cloud-contract/issues/628
and the commit https://github.com/spring-cloud/spring-cloud-contract/commit/077e18aa259e9ac0999d4435c056a3fca56a127f
@OlgaMaciaszek, @TYsewyn  we'll have to think how to make those two approaches work together. Anyways, we broke the compatibility :(

@kpb @marcingrzejszczak @TYsewyn It looks like, in fact, https://github.com/spring-cloud/spring-cloud-contract/issues/628 was not valid. I have added a comment there explaining why. I'm going to revert this change, which will fix this issue.

Reverted breaking change.


failure starting subprocesses causes infinite retries

If a subprocess (indexer, scanner) fails to start, the extension initially retries three times with backoff. After the third time, it logs a message saying that it's not going to try again. It continues to try, however, with no backoff.

An easy way to reproduce this problem in development: add --help to these arguments: https://github.com/applandinc/vscode-appland/blob/1368044cecf3a750e118e57f434e5b9fec9db9e7/src/services/indexProcessWatcher.ts#L16 .


Refs #5388 Fixed whitelist and bug with xml structure literal include. [5389]

Build status:

Build status:

Build status:

Build status:


Lock a workspace

FireCloud allows OWNERS to "lock" a workspace, which prevents editors from editing the description, creating/deleting workspace attributes, adding data tables, and importing method configurations.
We should also allow users to 'lock' workspaces. We should prevent the behaviors above when the workspace is locked. We should also prevent uploading data from the Files view, deleting table data, deleting files from the Files view, and creating/deleting notebooks. It's OK if users can do these things via API. We're turning off the UI affordances for them.
AC
Dependencies
Open Questions
Estimate
Any hard Deadlines?
Is this noteworthy? Does Comms need to know?

Very few workspaces are actually locked. I'm going to consider whether it is important to carry this feature forward.


Display Timestamp in Dashboard

Description
The Kyma dashboard shows only the date for timestamps but does not show the time itself. This makes analyzing issues difficult. I am not aware of any way to view the exact times of a certain timestamp in the dashboard and have to use kubectl to see exact timestamps which is cumbersome.
Ideas:

Always show the exact time instead of just the date
Show exact time on hover over date
Introduce condensed and wide mode to switch between displaying only the date or the full date + time
Introduce a toggle whether only the date or full time should be shown

I am not totally sure whether this is a regression. I just noticed this issue since the latest Fiori theme updates and think that we could see exact times in the dashboard before. We are using managed Kyma 2.20.0 on SAP BTP with the "Light / Dark" theme.
Reasons
Having the exact time available is really useful for analyzing issues. The date is not sufficient e.g. to determine in which order events occurred. I miss this feature especially for events (on cluster and resource level) and for the "Created At" for any K8s resource. There are probably many other places where the time is missing.
Attachments

Thank you for your feature request @henri-kohlberg . We will prioritize this in our backlog. We had a major ui change ( moving to a new Theme ) and some fields need adjustments.


Add Command for Windows 10

Edit README.md : Change multi-line command in this repo to multi-line command on Win10

PowerShell use ` (backquote)
Command Prompt use ^ (caret)

LGTM


CompositeByteBuf optimizations and new addFlattenedComponents method

Motivation:
The CompositeByteBuf discardReadBytes and discardReadComponents methods are currently quite inefficient, including when there are no read components to discard. We would like to call the latter more frequently in ByteToMessageDecoder#COMPOSITE_CUMULATOR.
In the same context it would be beneficial to perform a "shallow copy" of a composite buffer (for example when it has a refcount > 1) to avoid having to allocate and copy the contained bytes just to obtain an "independent" cumulation.
Modifications:

Optimize discardReadBytes() and discardReadComponents() implementations (start at first comp rather than performing a binary search for the readerIndex).
New addFlattenedComponents(boolean,ByteBuf) method which performs a shallow copy if the provided buffer is also composite and avoids adding any empty buffers, plus unit test.
Other minor optimizations to avoid unnecessary checks.

Results:
discardReadXX methods are faster, composite buffers can be easily appended without deepening the buffer "tree" or retaining unused components.

@normanmaurer I've addressed your comment and split the fix into separate PR #8946 (and amended this PR name and commit message to reflect that). I can rebase this once the other one is in.

Thanks @trustin, have now rebased and addressed those comments.

@normanmaurer now updated, PTAL

@netty-bot test this please

@netty-bot test this please

@normanmaurer I think the java12 test failures are unrelated to the changes?

@njhill yep... I think this test code is a bit racy... will have a look.

@netty-bot test this please

@vkostyukov it will be used here: https://github.com/netty/netty/pull/8931/files

@njhill thanks a lot!


HOSTEDCP-710: Make ImageContentSource immutable

What this PR does / why we need it:
Makes ImageContentSource immutable
Which issue(s) this PR fixes:
Fixes HOSTEDCP-710
Checklist

[x] Subject and description added to both, commit and PR.
[x] Relevant issues have been referenced.

/test e2e-aws

/test e2e-aws

Yeah looks good to me.
/lgtm

/approve

/retest-required

/retest-required

/test e2e-aws

{  failed to create secret: secrets "e2e-aws" already exists}
/test e2e-aws

/cherry-pick release-4.13

IBM needs this for when folks move from public endpoint clusters (public registires) to private only endpoint clusters (private registries)


flux Q*_K models don't work on macbooks (green noise)

First of all — thank you for the node. it is really helpful for small and personal projects.
I've tried multiple different flux Q*_K models from different authors — none of them work.
Meanwhile Q4_1 and similar quantisations work totally fine.
There are some reddit posts about that issue, including mine with no solution yet:
https://www.reddit.com/r/StableDiffusion/comments/1heupt9/flux_q_k_models_dont_work_on_macbooks/
https://www.reddit.com/r/comfyui/comments/1glk3lc/help_flux_schnell_gguf_is_generating_green_images/
https://www.reddit.com/r/FluxAI/comments/1gc98wh/flux_gguf_with_comfyui_on_macbook_m3_not/

I don't have any apple devices to test but it seems like a strange failure considering both Q4_1 and Q2_K_S use pretty similar functions (bitwise and and rshift).
Reading that thread you linked and considering the T5 encoder does work fine makes it even stranger (I assume Q3_K_S fails with flux).
Could you maybe test SD3.5 medium to see if the issue is isolated to flux or if it happens across all models. Also may be worth testing pytorch stable VS nightly to see if there's any fixes upstream.

both sd3.5_medium-Q3_K_S.gguf and sd3.5_medium-Q4_0.gguf work fine
Right now I'm using comfyui desktop — so it would be a bit harder to control pytorch version so I will test it later.
You could see from reddit posts that it's a common issue for at least a few months and for different macs (M1/M3).

Interesting how the SD3.5 preview still has green spots in it. Wonder if it's some precision issues, but iirc someone did try the --force-fp32 launch flag without much luck before.
Another thing that might be worth testing is using the Unet Loader (GGUF/Advanced) node and setting dequant_dtype to float32.

is using the Unet Loader (GGUF/Advanced) node and setting dequant_dtype to float32.

Unfortunately, no luck — same issue :(
I've tried your hunyuan-video-t2v-720p-Q3_K_S.gguf with this result:

Again, hunyuan-video-t2v-720p-Q4_1.gguf works fine.
My hypothesis is this — maybe there was some update in the GGUF conversion tool that broke some Q*_K models for macs.
We need someone with knowledge and Apple devices to test this.
I can use Q4_1, but I’ve noticed some deep confusion among new users.
Thank you for your work, and I’m looking forward to FastVideo/FastHunyuan GGUF :)
Yesterday, I tried making my own but, unfortunately, failed.


VS2015 strange sourcemaps after webpack

I have a strange behavior in VS2015 with source maps and webpack:
If I bundle with webpack, the breakpoints are picked correctly, but they are highlighted oddly, as if there is a +1 offset or similar. Furthermore, I can no longer hover the mouse over the variable and get the inspection tooltip.
Compare the two images below, the first is webpacked, the second is a plain TypeScript HTML app project created in Visual Studio. See how the red and yellow areas are shifted +1 to the right. But what bother most is the missing tooltip.

webpack

no webpack
I guess this is a VS problem because the source maps looks correct when inspected with something like source-map-visualization.
Any idea what is going wrong?

@nippur72 , I have observed similar behavior yesterday, and I am looking into it. Will keep you updated.

for completeness, I should add that I don't use any typescript specific loaders in webpack, I just bundle the .js files (and their source maps) compiled via VS2015.
Snippet of my webpack.config.js
module.exports = {
    module: {
        preLoaders: [ {
                test: /\.js$/,
                loader: "source-map-loader"
            }
        ]
    },
    devtool: "source-map",
    output: {
        libraryTarget: "this",
        path: "./bundle",
        filename: "app.js",
        sourceMapFilename: "[name].js.map",
        devtoolModuleFilenameTemplate: "[resource-path]"
    }
}

An additional remark about this issue: when debugging in Chrome I've noticed there's a "red dot" at position 0 in the sourcemap file. When hovering the mouse over such red dot the tooltip reveals it to be an \ufeff character, suggesting something is wrong with UTF encoding.
I suspect this might be related to the +1 offset, but have no clue why this is happening.
See the attached image:

Update: the UTF BOM character is not the problem, I converted my source files to UTF8 without marker and the issue it's still there.
Anyway I switched to using ts-loader in webpack (before I just loaded the compiled .js along with their .map files) and the problem seems to be (mostly) fixed as it does occur only in just few files.
What hasn't gone is the mouse tooltip when hovering over variable names.

I have investigated this and understood the issue and looking into possible ways to fix this. Will keep you updated.

I have just made changes in debugger to fix this issue. Next release that ships this fix should work for your solution correctly. please re-open if you still run into issues.

@sheetalkamat I've found another similar issue which I think might be related to this one, see #9770.


fix: preserve url hash on replaceState

Thinking about it more, I think it should be reload rather than replace.
For replace, I think we need a way to specify what hash to navigate to.


modified pick helper function to only keep keys if value is not None

@ramnes ,
I believe this should fix the issues mentioned here: #94
I haven't fully tested this yet, but I hope the GitHub Actions would be able to test this more fully.
Note, this is my first time contributing to this project, and I would love to contribute more. If there is anything else you would like me to do differently please let me know.

Hey there, thanks for opening that PR!
Yes, that would work in that scenario, but what if we really want to pass None as a value to Notion's API? Are we sure it can't happen?

Your absolutely right, it could happen that None is a valid value, in which case we would need to keep it.
From what I understand, in JavaScript, a variable can either

Have a value (aka be defined)
Be null
Be undefined

And each one of these has its own meaning in JavaScript. In python we can only handle defined and null variables, but not undefined variables.
In the notion API, I've seen cases where a variable can be either

Defined or null
Defined or undefined

But I have yet to see a situation where a variable can be either defined, null, or undefined...
What do you think about adding a little logic to the pick function so that, in cases where a variable must either be defined or undefined, the pick function would just remove it if it's None? Otherwise, it would just leave it alone.

@ramnes , I realize my description above might be difficult to follow, so I went ahead and implemented what I was talking about so that you can see it for yourself.
With these changes, key-value pairs with a value of None are popped by default. Key-value pairs that have a value of None are only kept if they are explicitly allowed via the keys_to_keep_if_none. I think this would work well with the Notion API, and would help solve the issues users have been experiencing.
Anyway, you may have better ideas. I'm open to suggestions.

Haha, I agree with you, sort of... Function arguments would be nice, but that still doesn't solve the real issue.
The real issue is that users want to specify, for example, start_cursor=None because this feels Pythonic. But, it's invalid to pass start_cursor=null to the Notion API. The workaround you proposed is not Pythonic ... but it's a good workaround for now.
This pull request is really about improving the user experience while using notion_client. It's really about allowing users to specify: variable=None, and then silently removing variable=None before a request is made to the Notion API.
In fact, that's exactly what @thamshirtz recommended in his issue comment.

I think it is needed to remove the argument start_cursor internally if None is passed, because I don't see any situation where it is wanted to get this error response

Here's another idea of how we could fix this: introduce the concept of an Undefined object.
The Notion API relies heavily on undefined variables, but there is simply no such thing in Python. If we created a notion_client.Undefined object, then users could use that instead of None.
Then the pick function could easily remove any key-value pair where the value is Undefined, but leave anything with a value of None. What do you think?

Did you really see a use case for passing None or was it just theory?

Actually, I think I completely made it up... sorry. I haven't seen a use case for passing None.
The Notion API seems to rely heavily on either a variable being defined or undefined, but not on it being null.
That's one reason why I think we can just have the pick function silently remove any key-value pairs with a value of None. I think this is a simple solution that will work very well, as far as we can tell. If we need to support some key-value pair with a value of None, then we can either worry about that later, or use the keys_to_keep_if_none.

Let's revert to the state where you just ignored None values then. We'll update to something else if anyone complains.

@ramnes , just reverted everything back, as you said.

Merged, thanks!

Seems like we found a use case for None as a real value: #128

I think we should just write sensible defaults in pick, that would ignore None for start_cursor and maybe other variables. I don't think there's a need for control over both the presence and the value.

Yeah, this is a very tricky problem... one that I think will continue to haunt us forever!
I think your solution sounds good. The initial issue was that users wanted to type start_cursor=None (in order to make the Python code simpler).  My solution was to blindly ignore all key-value pair with a value of None.
Your approach sounds better. Just ignore specific key-value pairs with a value of None (like start_cursor=None), and keep all others.
So the final behavior of pick would be something like this:
pick({start_cursor: None}, "start_cursor")

> {}

pick({"icon": None}, "icon")

> {"icon": None}

Right?

Yes, exactly. :)

Sounds good. One more annoying question...
Would reimplementing pick to something like this be good?
def pick(base: Dict[Any, Any], *keys: str, *, keys_to_pop_if_none:List[Any]) -> Dict[Any, Any]:
    """Return a dict composed of key value pairs for keys passed as args."""
    # first, get all key-values of interest from base
    picked = {key: base[key] for key in keys if key in base}
    # next, pop any key-values if None is not an acceptable value
    for key in keys_to_pop_if_none:
        if picked[key] is None:
            picked.pop(key)

    return picked

This allows code that calls the pick function to be more specific about which keys to keep, and which to eliminate based on whether the value is None.
I am only suggesting this because I can envision a situation where a specific key can be None in some cases, but not None in others. One potential example is that, when updating a block a value of None might be okay, but when querying a block a value of None might not okay.
In the official notion-sdk, I can see a place where icon can have a value of null, and a place where icon cannot have a value of null. So, in some cases we may want to allow Python-users to type icon=None, and it be silently removed by pick, but other times when icon=None is kept.
I may be overthinking and worrying about this too much... Let me know what you think.

The problem we had so far was just with start_cursor, so I was thinking of something much simpler like:
def pick(base: Dict[Any, Any], *keys: str) -> Dict[Any, Any]:
    """Return a dict composed of key value pairs for keys passed as args."""
    result = {}
    for key in keys:
        value = base.get(key)
        if value is None and key == "start_cursor":
            continue
        entries[key] = value
    return result

Eventually we could add the keys_to_pop_if_none variable if there's a need for other keys than start_cursor, and ultimately make it a function parameter if it's needed by someone, but again, let's wait to see these scenarios. (In any case, I'd give it a simpler name such as drop_none)

I think you're right. I'm always overcomplicating things...
I'll do my best get a pull request with the fixes, and some accompanying tests soon.

Alright so actually there are a lot of keys that can't be null, not just start_cursor, see the diff in 28020cd. :P
My first thought was to do the opposite and list the keys that can be null, but doing it the way I did will make maintenance easier since the API will yell at us if we try to send null when we're not allowed to.

Actually the code I wrote earlier is dumb because it adds all base values as None. There's a much better way: consider arguments only when they are handed over and simply ignore the infamous start_cursor=None... Implemented in 3289bd4.


pljava:init at version 1.6.7

Contributing packaging of pljava postgres extension to nixpkgs
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/4799

If you're just adding the package - why not add it already formatted? No need for a second nixfmt commit, right?

Yes, it had been some time since I submitted PR here, and realized after the fact that this step was needed.

Also the commit message should be postgresqlPackages.pljava: init at 1.6.7.

got it thanks

Also note that the latest version upstream is 1.6.8, let's do that instead?

Will update

@Ma27 @wolfgangwalther thanks for the feedback on this. I am having some health issues, so I think I am just going to drop/close this for now. When feeling better I'll resubmit.

Oof, take care and get well soon.
When you're ready, I'll gladly help getting this merged.


Splitting up errors inside Address::Error

This PR includes the following :

Introduce a new error type NetworkError
Removes the Address::Error

fixes #2290

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

-4 of 5 (20.0%)  changed or added relevant lines in 2 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.004%) to 83.911%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

bitcoin/src/address/mod.rs
1
2
50.0%

bitcoin/src/address/error.rs
0
3
0.0%

Files with Coverage Reduction
New Missed Lines
%

bitcoin/src/address/error.rs
2
4.71%

Totals

Change from base Build<PHONE_NUMBER>:
0.004%

Covered Lines:
19438

Relevant Lines:
23165

💛  - Coveralls

I dunno about the others but I personally think this should be
/// Address's network differs from required one.
#[derive(Debug, Clone, PartialEq, Eq)]
#[non_exhaustive]
pub struct NetworkValidationError {
    /// Network that was required.
    pub required: Network,
    /// The address itself.
    pub address: Address<NetworkUnchecked>,
}

impl fmt::Display for NetworkValidationError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "address ")?;
        fmt::Display::fmt(&self.address.0, f)?;
        write!(f, " is not valid on {}", self.required)
    }
}

#[cfg(feature = "std")]
impl std::error::Error for NetworkValidationError {}

Oh I remember the conversation now, you posted that example code then too and I did not see how that matters if a user is using anyhow. IIRC that is where the conversation ended (in my mind anyway).

I feel like its easier if I take this over @Harshit933, its way too contentious, hope you don't mind - #2508

I feel like its easier if I take this over @Harshit933, its way too contentious, hope you don't mind - #2508

Sure, I'll close this one.

Thanks man


Feature/exe 1884 make community detection deterministic

Setting a random seed for leiden algorithm so that component IDs remain constant through multiple runs of pipeline.
Fixes: #EXE-1884
Type of change
Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?
PR checklist:

[x] This comment contains a description of changes (with reason).
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works

Superseded by PR 188.


Using custom (Unlimited) SMS Provider for sending OTP

Feature request
Currently, there is just a few SMS Provider, Twilio and Messagebird but they are expensive for my country, and there is a local SMS Provider that is 500%++ cheaper.
And I believe there is a lot of SMS Provider that cheaper in every country.
https://github.com/supabase/gotrue-js/issues/356
Describe the solution you'd like
Add option in body request that gotrue didn't send the OTP and just give back the OTP code after saving it on the database.
By that, I can use any SMS Provider to send the OTP code, or even I don't send it via SMS, maybe Whatsapp, or anything else.
For example:
curl -X POST 'https://tqfkjdmpohkqylveukuhsy.supabase.net/auth/v1/otp' \
-H "apikey: <SERVICE_KEY>" \
-H "Content-Type: application/json" \
-d '{
  "phone": "123123123123",
  "send_otp": "false"
}'

{"otp_code":"897514"}

Describe alternatives you've considered
Maybe the API that can write the confirmation_token
curl -X POST 'https://tqfkjdmpohkqylveukuhsy.supabase.net/auth/v1/confirmation_token' \
-H "apikey: <SERVICE_KEY>" \
-H "Content-Type: application/json" \
-d '{
  "phone": "123123123123",
  "otp":"<RANDOM>"
}'

{"success":"true"}

No need to return an OTP code, since the OTP is created on my end.
Additional context

Hi, is there a progress here? Really need this feature. Twilio costs 0.2 usd for single sms in my country

Hey @myemuk, I've already created a PR for this (#558). In the meantime if you're self-hosting you can use my fork which supports using a custom SMS gateway.

@mamousavi , thanks. Hopefully it will be soon merged

If you need a quick fix just create psql function to duplicate auth.users to public.user and create psql trigger to run the function each new user signup.
then use RLS (Row Level Security) on your public.users.

Any progress here?

A suggestion we choose the provider that best serves us, in my case I want to be able to send the code via whatsapp api.
An example is that the subbase generates the token and returns it to us and we send the token via the whatsApp API, sms or whichever provider we want, and the user inserting the right token validates the subbase

It would be nice to be able to send SMS via Google Cloud's provider.  You get 10,000 successful auths/month for free and it's pretty much the only viable option for many indie developers. I believe many developer decide to stay in Firebase because of that.

It's 2024, any progress here at all?

Is there a workaround on how to do it?

Hey all,
Thanks for patiently waiting. We've recently released the send sms hook
Which should allow you to do this. Please give it a spin
Going to close for now. but don't hesitate to reach us if there are issues


Rename method name: fit_maxent_classifier -> fit_softmax_classifier

Hi!
In the previous notebook, this method is named "fit_softmax_classifier", instead of "fit_maxent_classifier".
Considering that this notebook contains the following mention to the previous notebook, I have thought it would be nice to have both method named the same:

Our model will just be LogisticRegression, and we'll continue with the experiment framework from the previous notebook. Here is fit_maxent_classifier again:

Hope it helps!
Miguel

@miguelusque This is very nice -- thanks again!


Fail in get_stat_json on virtual repository

Hi,
I am trying to upload via the deploy_file method, and i had issue uploading through a virtual repository with error "404, Not found", what does not make sense because i am trying to upload a new file that he shouldn't be exists any way.
So after debugging the error trace back i found that in the API when i try to reach a file is not exists, i had different behavior if it is virtual repo or not;
in regular repository i get this:
{   "errors" : [ {     "status" : 404,     "message" : "Unable to find item"   } ] }
however in the virtual repository i get a different error message:
{   "errors" : [ {     "status" : 404,     "message" : "Not Found"   } ] }
And the library method artifactory.py in get_stat_json (Line 457),
if code == 404 and "Unable to find item" in text:
Which make this condition not working in virtual repository.
Thank you very much.

This repo is currently outdated
There is an active fork of this library available at https://github.com/devopshq/artifactory


Update api-management-api-import-restrictions.md

server templating from openapi v3.0 not supported by APIM

@dlepow
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@roquems - Thanks for submitting the PR. Do you have an example of a spec where you found this limitation? (Please don't include any sensitive information.)

@roquems,
Can you respond to the comment above?

@roquems
Can you respond to the comment above?

sorry I missed all the other notifications
openapi: 3.0.0
info:
title: Azure OpenAI Service API
description: Azure OpenAI APIs for completions and search
contact:
name: test user
email<EMAIL_ADDRESS>version: '2024-02-01'
servers:

url: https://{environment}.integration.site.com/openai
x-internal: false
variables:
environment:
default: apihub
enum:
- apihub.dev
- apihub.test
- apihub.preprod
- apihub

@dlepow
Can you review this old PR and determine whether it needs to be closed or merged?
@MicrosoftDocs/public-repo-pr-review-team


GEODE-9439: Convert CertificateBuilder to sun/jdk APIs

Makes it easier to de/serialize created certificates
Remove the requirement for the Bouncy Castle library
Java 9 has a very similar utility which we should be able
to switch to once we move away from 8.

Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[ ] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[ ] Is your initial contribution a single, squashed commit?

[ ] Does gradlew build run cleanly?

[ ] Have you written or updated unit tests to verify your changes?

[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

Note:
Please ensure that once the PR is submitted, check Concourse for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to<EMAIL_ADDRESS>

🥇

I don't remember seeing this as a proprosal in the dev channel. Is this something that should be there? I am just asking the question... I am curious if this affects Spring or others.

It's a change to a test helper class - I didn't think it would warrant any significant discussion.

It's a change to a test helper class - I didn't think it would warrant any significant discussion.

Sounds good. Approved..

@ladyVader Oops - thanks for pointing that out. Just pushed that change.


chore(deps): upgrade dev dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-dev-dependencies-k8s-28-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 4145

Questions ?
Please refer to the Backport tool documentation