Muon Matching and Vertices and Ratio Plots

Included are 4 main parts:

Work on NanoMuons with 3 different matching functions between LooseDSAMuons and LooseMuons collections
Work on NanoMuon Vertex collections to match muons to the vertices and merge the 3 Vertex collections (Pat-Pat, Pat-DSA, DSA-DSA) into one to work with
ID Scale Factors for DSAMuons
Ratio plots between two histograms

Maybe some of the NanoMuons and Muon vertex functions should be in the NanoEventProcessor, instead of NanoEvent

Now I've updated the code, so there's also a NanoDimuonVertex collection now and updated the muon matching, ratio plots and 2d plots


add With Clause

fix https://github.com/tgriesser/knex/issues/716
add a with function(alias, callback|raw)
knex.with('with_alias', function() {
    this.select('*').from('books').where('author', 'Test')
}).select('*').from('with_alias')

output:
with "with_alias" as (select * from "books" where "author" = 'Test') select * from "with_alias"

Looks good. I added couple of small comments. Also would be good to add at least one integration test for this.


Update cookie-sharing.md

Fixes #21163

@avendel you write in your SO thread:

This code should be added to the ASP.Net Framework project.

Shouldn't that be
This code should be added to the ASP.NET Core project.
Also, at the very top of the post, I'm going to replace

Have .NET Core 2.0 application which uses a Data Protection Provider

With
Have ASP.NET Core app which uses a Data Protection Provider

@avendel you write in your SO thread:

This code should be added to the ASP.Net Framework project.

Shouldn't that be
This code should be added to the ASP.NET Core project.
Also, at the very top of the post, I'm going to replace

Have .NET Core 2.0 application which uses a Data Protection Provider

With
Have ASP.NET Core app which uses a Data Protection Provider

@Tratcher  I thought this was too niche/advanced to mention, but the SO post has alot of activity.

@Tratcher  I thought this was too niche/advanced to mention, but the SO post has alot of activity.

Shouldn't that be
This code should be added to the ASP.NET Core project.

The workaround from my SO answer adds the ASP.NET Core session id claim during serialization of the authentication ticket.
public string Protect(AuthenticationTicket data) {
    var sessionClaim = data.Identity.FindFirst(OwinSessionIdClaim);
    if (sessionClaim != null) {
        data.Identity.AddClaim(new Claim(AspNetCoreSessionIdClaim, sessionClaim.Value));
    }
    return this.dataFormat.Protect(data);
}

So this code should run in the ASP.NET Framework OWIN project to make sure the generated cookie contains a session id claim known to the ASP.NET Core project.
One would have to make sure to always add both to get it working in the opposite circumstance where the cookie is generated in the ASP.NET Core project. I will update my SO answer to clarify.

Shouldn't that be
This code should be added to the ASP.NET Core project.

The workaround from my SO answer adds the ASP.NET Core session id claim during serialization of the authentication ticket.
public string Protect(AuthenticationTicket data) {
    var sessionClaim = data.Identity.FindFirst(OwinSessionIdClaim);
    if (sessionClaim != null) {
        data.Identity.AddClaim(new Claim(AspNetCoreSessionIdClaim, sessionClaim.Value));
    }
    return this.dataFormat.Protect(data);
}

So this code should run in the ASP.NET Framework OWIN project to make sure the generated cookie contains a session id claim known to the ASP.NET Core project.
One would have to make sure to always add both to get it working in the opposite circumstance where the cookie is generated in the ASP.NET Core project. I will update my SO answer to clarify.


files don't save or get marked dirty

Type: Bug

open a file
edit the file

Expected result: file gets the dot indicating it's "dirty"
Actual result since 1.70.0: 50/50 whether that will happen or not... in the cases when it doesn't, Save does nothing
Restarting VS Code will show the file as dirty, and usually will also allow the file to be saved, but about 80% of the time restarting VSCode again will reopen the file showing as dirty, and trying to save it again will show a Conflict where both before & after are identical (e.g there is no conflict)
I know that's several different bugs, but since they're all related I don't even know how to separate them... #157902 was caused by the same update...

I just had 1 case where I had to reboot the PC to stop it from marking a file dirty on restarting VSCode
I've already tried deleting my entire AppSettings/Roaming/VSCode folder, except for user settings, keyboard shortcuts, & snippets...no effect

Please use the Start Extension Bisect command to investigate whether the problem is being caused by one of your 100+ extensions.

I am seeing random git related issues with 1.70.2 as well.  In my case, I have noticed files appear "dirty" in the source control extension when git status says the repo is clean.  In another case the repo shows one dirty file and git status says there are two dirty files.

Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!

just duplicated it in the latest VSCode with all extensions disabled... tried it in Insiders with no extensions installed and it does not happen, at least not with the files that it consistently happens with... 2 other things that are correlated to this issue that I hadn't noticed to mention above...

it consistently happens or not with the same files over & over again
when the issue happens, not only does the file not get marked dirty, problems don't get yellow squiggles either (not even in the scroll area)

I can't confirm, but I suspect this bug should've been filed against the Markdown language server instead of VSCode as a whole... is that a separate repo???

this seems to be resolved with 1.72.0... files that consistently exhibited the strange behavior have been normal since that update


Fixed issue #93

replaced old link with a the new one in README.md

Thanks for the PR; fixed this in 82dd2cdd4954cd7b8983d5d64c0dfd9072bf4650.


Adding a minimal config example

Hey,
Thank you for bringing ctranslate2 to Triton! I am currently working on a project for a course using ctranslate2 and would like to host the model on Triton.
I got it up with Triton, but I am struggling to find the correct config.
Would it be possible to add a minimal example for a model?
Thank you!

Hi @aamir-s18, thanks for your interest.
I am sorry that there was no documentation yet, it wasn't quite ready for public consumption. I added a very basic README in #3, let me know if this helps, you could even make some comments to brush it up.
Thanks,
Markus

Hey @HennerM thank you for the docs! It is working :)
I will go over it tomorrow and brush it up. I made it run without the docs but it was really a wild ride to get it run.
Really thank you so much for the code and the docs! :)))

Hey @HennerM,
I think your Readme is super clear! LGTM.
Maybe we can move this to new issues:

Could we add support for other models than sequence to sequence? I modified the code to get it to work with language model class. What would be a good way to generalise the current code? Unfortunately, I am not super familiar with Triton. But I would love to contribute.
Does the current code support streaming? From my first experiments, it seems not. I didn't find any docs about how to make it work in Triton but it Triton seems to support it. Do you have some ideas or pointers?

Feel free to close this issue. Let me know if I should open a new issue.


Generated insertion code contains duplicate variable declaration when referring to converted type

DBFlow Version: 4.0.0-beta7
Issue Kind: Bug
Description:
generated code does not take advantage of the type converter to set values back from the cursor
public class BaseEntity extends BaseModel implements Serializable{

    @PrimaryKey
    ObjectId id; //from 'org.mongodb:bson:3.0.4'

    //getters and setters
}

@Table(database = DatabaseConfig.class,inheritedPrimaryKeys = {@InheritedPrimaryKey(column = @Column,primaryKey = @PrimaryKey,fieldName = "id")})
public class User extends BaseEntity implements Model {

    //other fields
}

ObjectId has a typeconverter class
@Table(database = DatabaseConfig.class,inheritedPrimaryKeys = {@InheritedPrimaryKey(column = @Column,primaryKey = @PrimaryKey,fieldName = "id")})
public class Collaborator extends BaseEntity implements Model {

    @ForeignKey(saveForeignKeyModel = false,stubbedRelationship = true)
    private User user;

    //getters and setters

}

the generated code in Collaborator_Table tries to set the id of the user on a collaborator from a string rather than converting it to an ObjectId on the loadFromCursor
private final void loadFromCursor(Cursor cursor, Collaborator model){
//...
if (index_user_id != -1 && !cursor.isNull(index_user_id)) {
      model.setUser(new User());
      model.getUser().setId(cursor.getString(index_user_id));
    } else {
      model.setUser(null);
    }
//..
}

i bypassed this issue by creating a second setter of the id on the BaseEntity class that accepts a string
also if the BaseEntity class is declared abstract the methods bindToInsertValues and loadFromCursor the generated variable ref id will be declared twice in the same scope making the code not compile

yes this is a bug. for now you can specify a column name manually while keeping variable name unique:
@Column(name = "id")
int _id;

something like this on your Collaborator class.

now foreign keys have a special postfix based on _Table which will eliminate this issue. Also new generated code would prevent this issue you see here now. in develop.


Fixed truncation of long text in the Interactive List for IE 11

Prerequisites
Please make sure you can check the following two boxes:

[x] I have read the CONTRIBUTING document
[x] My code follows the code style of this project

Contribution Type
What types of changes does your code introduce? Put an x in all the boxes that apply:

[x] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
[ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] My change requires a change to the documentation
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[x] All new and existing tests passed

Description
[Place a meaningful description here.]

Fix for #169


Switch to Debian Jessie Archive repo.

Fixes #366.
Please read through related issue ^ before commenting on this or merging.

Our CircleCI builds are failing today due to this error:

This might help fixing the issue?

Our CircleCI builds are failing today due to this error:

This might help fixing the issue?

I have same.
Sometimes I shows same IP addresses as on your screenshot, and sometimes - others
W: Failed to fetch http://http.us.debian.org/debian/dists/jessie-backports/main/source/Sources  404  Not Found [IP: <IP_ADDRESS> 80]

W: Failed to fetch http://http.us.debian.org/debian/dists/jessie-backports/main/binary-amd64/Packages  404  Not Found [IP: <IP_ADDRESS> 80]

Hey everyone commenting here. This issue will be fixed today. If you don't want to wait, using the non-Jessie version of your image should avoid this issue entirely.

Still seeing the issue:

Starting container circleci/node:8.11.4
  image cache not found on this host, downloading circleci/node:8.11.4
8.11.4: Pulling from circleci/node
Digest: sha256:372dbff602066c00561c11b8a19d85665001b9c13ec82f87247e1910e9fbd63b
Status: Downloaded newer image for circleci/node:8.11.4
  using image circleci/node@sha256:372dbff602066c00561c11b8a19d85665001b9c13ec82f87247e1910e9fbd63b

With the same errors when trying to run apt-get update. Have the images being pulled not been updated yet?

hi @dannyjeck-matroid can you try one of the node tags that was built more recently ?
https://hub.docker.com/r/circleci/node/tags

I'm using circleci/node:8.11.4 with out the "-jessie" suffix, and I'm having the same issue.

hi @mazyvan can you try one of the node tags that was built more recently ?
https://hub.docker.com/r/circleci/node/tags

i'm going to close this issue & redirect folks to the discuss post outlining the implementation of the fix:
https://discuss.circleci.com/t/convenience-images-update-changes-to-debian-mirror-for-browsers-tagged-image-variants
specifically:

As a reminder, we do not actively build/maintain all available image tags  . The tags we actively support are determined by the tags pushed to upstream Docker Library images, as outlined below:

https://github.com/circleci/circleci-images#official-images
https://circleci.com/blog/build-image-update-schedule

Thus, to ensure your image has the latest patch, make sure the tag you are using is a new one. You can easily make this determination in either of two ways:

check the tags list at https://hub.docker.com/r/circleci/YOUR_IMAGE/tags , which lists tags by last-pushed date
check our circleci-dockerfiles repository , which publishes complete Dockerfiles for all tags published as part of each new commit to our images repository

You can also use our images’ semantic versioning system, which draws from the semantic versioning of upstream Docker Library images, to make sure you receive these kinds of updates automatically. For example, while the circleci/node:9.10.0 image tag may not be built in the future, referencing circleci/node:9.10 in your config.yml file will ensure that you always receive the latest circleci/node:9.10.z image tag.


feat: pico swap contract

This is not quite the directory structure I had in mind. I was thinking of having the src/index.ts, src/contract/main.hl, src/contract/types.hl and src/contract/index.ts


Parameter documentation for huggingface config parameters

Hi, I am currently working on a UI Wrapper for the SAM models on huggingface.
Basically, the wrapper lets the user choose images and parameters and then dynamically generates the preprocessor_config.json and config.json files before running the model inference.
This works fine with default parameters, however I am wondering if I can find documentation of the parameters in the jsons (short description, value limits, datatype)? This would be quite helpful!

I don't know much about the huggingface side of things, so I'd take what I say with a grain of salt... However, it looks like the config files contain a mix of SAM model config parameters and then loads of junk that has nothing to do with the SAM model (but maybe needs to be there for compatibility with the rest of the library?).
For example, there are nonsense entries like: end-of-sentence token id but these are mixed with real SAM parameters like the layer indices for global attention. So making sense of the config files probably requires hunting around for which entries are actually relevant.
The config.json file has 3 important sections: mask_decoder_config, prompt_encoder_config and vision_config, these seem to correspond with the model config for classes: MaskDecoder, PromptEncoder and ImageEncoderViT, respectively. The values in the config file seem to be for the 'huge' variant of the SAM model, which is set within the build_sam.py script. Similarly, the preprocessor_config.json seems to reference the preprocessing steps found in the SAM model class and parts of the predictor. So those are the places I would look for understanding the values/ranges of the different settings.
That being said, the values all seem to be related to the model structure. Changing these values makes sense if the goal is to load a different set of weights (like the 'base' or 'large' weights), but would otherwise break the model, since they aren't the kind of values that can be tuned for better performance or anything (at least, for a given set of weights).

Thank you a lot for the detailed information - this is already quite helpful!
Yes, this is also the first time for me using huggingface. As I understand it, it basically abstracts models away so they can used with a few lines of code - which is actually perfect for my usecase (General web demonstrator for different ML models). So I guess it makes sense, that there is stuff in the configs for compatibility reasons.

Hi @TheRealRolandDeschain this is all documented here for instance: https://huggingface.co/docs/transformers/model_doc/sam#transformers.SamMaskDecoderConfig.

@NielsRogge Thank you I will have a look through the linked documentation!


Add draft-07 migration for ajv 6.0.0

Is it really necessary given that draft-07 is the same and only requires updating the reference to meta-schema from 06?

I think it's confusing that ajv no longer supports draft-06 (by default), and this migration tool doesn't migrate to -07.

As I said, the only difference is in $schema. I don’t mind the change that would update API (no need for draft6 in it, I don’t see any point in migrating to multiple drafts, this package should only migrate to the latest supported).
Optionally, the support for “switch” migration can be added, but I’m not sure if anybody needs it.

Any plans on supporting latest version, 2019-09?

v1 of this package supports migration to draft-07 and to draft-2019-09


Handle CUSTOMER type as Google Group member

What changed?

CUSTOMER type represents the entire google workspace organization.

Rationale

Without CUSTOMER type support, import on Google Workspace will crash.

How was it tested?
If it was manually verified, list the instructions for your reviewers to follow.

[ ] Unit Tests
[ ] Functional Tests
[x] Manually Verified

import google group with customer type. add customer type as member, remove customer as member.

for upcoming release note:
the missing CUSTOMER support issue is reported by jonathan.silva in community slack.


Bug fix: exit code greater than zero results blockquoted Markdown

The
# @exitcode >0 On failure

function tag produces:

0: On failure

instead of:

>0: On failure

and this is not the desired working.

@gimolai good point. Can you fix it?

https://github.com/reconquest/shdoc/blob/master/shdoc#L37
-    styles["github", "exitcode", "from"] = "([0-9]) (.*)"
+    styles["github", "exitcode", "from"] = "([>!]?[0-9]{1,3}) (.*)"

This is that. I have no permission to access the repository, so I can't push it.


added SlovenianUpnQr payload generator, manual QR version and ECI mode

This PR implements the following features:

[ ] Added ECI Mode Support (partial)
[ ] Added possibility of Manual QR Code Version
[ ] Added Slovenian UPN-QR Code standard Payload Generator (SlovenianUpnQr)

Hi @ahotko ,
thanks for your effort. Please give me a day or two to review the code and think about it. (I want to think about all possible side effects and conflicts. But from a first view, I think I'll merge it. 👍 )
Another question: Would you mind, to deliver a text for the wiki, which explains the SlovenianQRCode? Similiar to the SwissQrCode part over here: https://github.com/codebude/QRCoder/wiki/Advanced-usage---Payload-generators

Hei,
I tried to change the code as little as possible so the functionality SHOULD be compatible or the same.
SlovenianUpnQr generates string according to Slovenian UPN QR standard (UPN is acronym for "Univerzalni placilni nalog" or in english "Universal payment order"). Requirements are in https://www.upn-qr.si/uploads/files/NavodilaZaProgramerjeUPNQR.pdf document, but it is in Slovene. It has some special requirements though, which have to be met to get approval for printing QR code in UPN forms. Theses requiremenst are:

QR Version must be 15
ECC must be M
Byte mode
ECI set to 4 (ISO8859-2)
and of course specially formatted string

Attached if text for Wiki.
SlovenianUpnQr-md.txt

Hi @ahotko ,
at first thanks for providing the documentation.md!  As promised I had a look over the code. Before merging I have  one or two questions:

You added a method PlainTextToBinaryECI, but I can't see that it is used anywhere? Did I miss the part, where it is used or can it be removed from the source again?
In the PlainTextToBinary-method you added a case-switch for EncodingMode.ECI, but added no return value (see here: https://github.com/codebude/QRCoder/pull/111/files?diff=split#diff-9e6c145bebc51d16883ade6f68b714dfR908 ). How does this work? Wouldn't this empty the payload?

Besides this two questions I'm fine with your changes. Could you help to erase my question marks?

Hei,

PlainTextToBinaryECI  was ment to be for ECI Encoding, but as ECI is only for character encoding, mode doesn't matter (even better if it's byte mode), so I forgot to delete the method

in case of empty PlainTextToBinary case statement: PlainTextToBinaryECI shoul be used here, but I have removed it, as it is not used; case can be empty as it defaults to default (as it did before) - you can remove it or leave it, does not matter as EncodingMode.ECI is never assigned (maybe future use?)

Kind regards,
Ales

Ok,  the evrything is clear. Thanks for your support.  :+1:

Hi @ahotko I just released version 1.3.3 on Nuget. So your payload generator is part of the official Nuget package now.

Hei @codebude - thanks for info and merge! Have a great day!


Add space in "DISTINCT ON (...) "

For prettier query string.
This is homogeneous to what we do with commas and joins.

Currently we generate:
SELECT DISTINCT ON ("table"."id")"table"."id", "table"."field" FROM ...


Fix version check in schema_metadata/lookup test

The comment of the test states this test is meant for Cassandra 2.2+ yet the check makes it run against version 2.1 as well.

Good catch. Thanks.


[stable/grafana] Add support for Google Cloud SQL

What this PR does / why we need it:
Allows Google Cloud Platform's managed database service, Cloud SQL, to be used as a Grafana backend. This feature is intended to be used primarily from GKE. The only documented way of accessing Cloud SQL instances from GKE is via a Cloud SQL proxy sidecar.

/assign @prydonius


Translations update from Hosted Weblate

Translations update from Hosted Weblate for Frog/Frog.
Current translation status:

@flipflop97 no, that’s the name of the app and you should always leave it unchanged, unless it’s a general name (e.g. “Extension Manager”)

Totally true, I had nothing to add :)


Fix double macros bug

Macro run strangely if I input double macros like "%{ARGS_COMBINED_SIZE}%{ARGS_COMBINED_SIZE}".
Example(id and phase are omitted for convenience):
	SecAction "setvar:tx.msg=%{ARGS_COMBINED_SIZE}%{ARGS_COMBINED_SIZE}"

The scanner(lexical analyzer)'s status change road:
	0. INITIAL
	1. -[SecAction]-> TRANSACTION_FROM_DIRECTIVE_TO_ACTIONS
	2. -[ "]-> EXPECTING_ACTIONS_ENDS_WITH_DOUBLE_QUOTE
	3. -[setvar:]-> SETVAR_ACTION_NONQUOTED
	4. -[tx.]-> EXPECTING_VAR_PARAMETER_OR_MACRO_NONQUOTED
	5. -[msg]-> EXPECTING_VAR_PARAMETER_OR_MACRO_NONQUOTED
	6. -[=]-> SETVAR_ACTION_NONQUOTED_WAITING_CONTENT
	7. -[%{]-> EXPECTING_ACTION_PREDICATE_VARIABLE
	8. -[ARGS_COMBINED_SIZE]-> EXPECTING_ACTION_PREDICATE_VARIABLE
	9. -[}%]-> SETVAR_ACTION_NONQUOTED_WAITING_CONTENT
	10. -[{ARGS_COMBINED_SIZE}]-> SETVAR_ACTION_NONQUOTED_WAITING_CONTENT
	11. -["]-> EXPECTING_ACTIONS_ENDS_WITH_DOUBLE_QUOTE
			-> INITIAL

The ninth step should be paid attention. Since the ninth step take }%, the tenth step doesn't have %. So the tenth step cannot know there is a macro expansion.

Good work. thank you!
Very hard to get contribution on the parser. Kudos :)

Hi @supplient,
Made the modifications that I've suggested and the patch is now merged. Thank you.


Bump up browser docker base image

Describe the bug
Current Browser docker base image is mcr.microsoft.com/playwright:v1.30.0-focal,
which has node version v16.19.0. Version should be bumbped to get Node 20 version to container.
To Reproduce
Steps to reproduce the behavior:

run docker command to see node version on container: sudo docker run -it marketsquare/robotframework-browser:18.5.1 node --version

Expected behavior
node version should be 20
Actual result
node version v16.19.0
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: iOS
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional context
building container using version 18.5.1 as base image gives dependency warnings:
#22 2.623 2024-05-28 10:12:53,806 [INFO    ] Installing node dependencies...
9369#22 2.950 2024-05-28 10:12:54,132 [INFO    ] Installing rfbrowser node dependencies at /home/pwuser/.local/lib/python3.8/site-packages/Browser/wrapper
9370#22 3.231 2024-05-28 10:12:54,413 [INFO    ] npm WARN config production Use --omit=dev instead.
9371#22 3.626 2024-05-28 10:12:54,808 [INFO    ] npm WARN EBADENGINE Unsupported engine {
9372#22 3.626 2024-05-28 10:12:54,808 [INFO    ] npm WARN EBADENGINE   package<EMAIL_ADDRESS>9373#22 3.626 2024-05-28 10:12:54,809 [INFO    ] npm WARN EBADENGINE   required: { node: '>=18' },
9374#22 3.626 2024-05-28 10:12:54,809 [INFO    ] npm WARN EBADENGINE   current: { node: 'v16.19.0', npm: '8.19.3' }
9375#22 3.626 2024-05-28 10:12:54,809 [INFO    ] npm WARN EBADENGINE }
....

@allcontributors please add @vmmattila for bugs

Was not fixed, building docker image failed

Fixed in  #3628


running problem with video_chat_with_StableLM

I have installed all we need as the reference infered, when I run “python app.py”, I encoutered the problem below. I have checked the internet connection, which is OK. what's wrong with my code configuration?
Traceback (most recent call last):
File "/data/vjuicefs_hz_cv_enhance_v1/11142060/study/Ask_anything/Ask-Anything-main/video_chat_with_StableLM/app.py", line 21, in
model = tag2text_caption(pretrained="pretrained_models/tag2text_swin_14m.pth", image_size=image_size, vit='swin_b' )
File "/data/vjuicefs_hz_cv_enhance_v1/11142060/study/Ask_anything/Ask-Anything-main/video_chat_with_StableLM/models/tag2text.py", line 222, in tag2text_caption
model = Tag2Text_Caption(**kwargs)
File "/data/vjuicefs_hz_cv_enhance_v1/11142060/study/Ask_anything/Ask-Anything-main/video_chat_with_StableLM/models/tag2text.py", line 85, in init
self.tokenizer = init_tokenizer()
File "/data/vjuicefs_hz_cv_enhance_v1/11142060/study/Ask_anything/Ask-Anything-main/video_chat_with_StableLM/models/tag2text.py", line 338, in init_tokenizer
tokenizer = BertTokenizer.from_pretrained('bert-base-uncased')
File "/opt/conda/envs/videochat/lib/python3.9/site-packages/transformers/tokenization_utils_base.py", line 1707, in from_pretrained
resolved_vocab_files[file_id] = cached_path(
File "/opt/conda/envs/videochat/lib/python3.9/site-packages/transformers/file_utils.py", line 1846, in cached_path
output_path = get_from_cache(
File "/opt/conda/envs/videochat/lib/python3.9/site-packages/transformers/file_utils.py", line 2102, in get_from_cache
raise ValueError(
ValueError: Connection error, and we cannot find the requested files in the cached path. Please try again or make sure your Internet connection is on.

It might be because your network connection cannot connect to huggingface. Please check your network connection.


ColorMode - will stop working in Home Assistant Core 2025.3

None (<class 'custom_components.teleco_daisy.light.TelecoDaisyLight'>) sets invalid supported color modes {<ColorMode.RGB: 'rgb'>, <ColorMode.BRIGHTNESS: 'brightness'>}, this will stop working in Home Assistant Core 2025.3, please create a bug report at https://github.com/andreasnuesslein/hass_teleco_daisy/issues

That line in my first comment is exactly the Line that HomeAssistant writes into its Logfiles...
Sorry for not marking it as code or quote...
The Homeassistant Logfile states:
None (<class 'custom_components.teleco_daisy.light.TelecoDaisyLight'>) sets invalid supported color modes {<ColorMode.RGB: 'rgb'>, <ColorMode.BRIGHTNESS: 'brightness'>}, this will stop working in Home Assistant Core 2025.3, please create a bug report at https://github.com/andreasnuesslein/hass_teleco_daisy/issues

Just to state the obvious:

ColorMode.RGB
ColorMode.BRIGHTNESS

...will stop working in Home Assistant Core 2025.3
Since Your Integration tries to set those, Home Assistant proposes that I should contact You about this by opening a bug report, which I did and you obviously just closed...

haha okay ^^
well, like i said in the other ticket, to avoid confusion maybe be a bit more verbose in your tickets please ;)
(a hi there is a nice start)


AR support on Firefox and Chrome for iOS

Description
AR button in Firefox on iOS prompts a download instead of AR. Works on Safari. on Chrome I am not seeing the AR button at all*.
*I looked for the Chrome webXR flags but they're not on the list.
Live Demo

https://sourdough-ar.glitch.me/

Browser Affected

[x] Chrome
[ ] Edge
[x] Firefox
[ ] Helios
[ ] IE
[ ] Safari

OS

[ ] Android
[x] iOS
[ ] Linux
[ ] MacOS
[ ] Windows

Versions

model-viewer: v10
three.js: rXX

+1, Chrome and Firefox browsers on iOS is very commonly used.
Detection method is the same:
    // Check if AR quicklook is available on iOS
    var isARAvailable = function() {
      const a = document.createElement("a");
      return a.relList.supports("ar");
    }

If the AR button is showing up and not launching AR, then it's a bug on iOS Firefox/Chrome, as we are checking if it supports AR.


Illegal invocation error when modal has word model in id

OK:

Not OK:

Can you please create a reduced test case via CodePen or JS Bin and report back with your link, Bootstrap version, and specific browser and Operating System details. :slightly_smiling_face:

Can you please create a reduced test case via CodePen or JS Bin and report back with your link, Bootstrap version, and specific browser and Operating System details. :slightly_smiling_face:

modal is in the IDs of our size examples in our docs, so that doesn't seem to be the cause of the issue you're running into. https://getbootstrap.com/docs/5.0/components/modal/#optional-sizes
Closing until we hear more with a reduced test case.

modal is in the IDs of our size examples in our docs, so that doesn't seem to be the cause of the issue you're running into. https://getbootstrap.com/docs/5.0/components/modal/#optional-sizes
Closing until we hear more with a reduced test case.


Fix: Add missing package, which is preventing swagger-ui from loading, and ChatGPT from importing the plugin

Motivation and Context
This change is required to fix the issue with failure to fetch swagger.json due to a missing assembly Microsoft.CodeAnalysis. This is a blocker for user's onboarding by following Readme, as ChatGPT was unable to load the manifest when trying to fetch swagger.json, as shown below.
This fix will ensure that swagger.json will be fetchable and OpenAI is able to fetch the plugin as expected.

Description
This PR fixes the issue by adding 'Microsoft.CodeAnalysis' package (version 4.7.0-2.final) as a reference in the project file. The 'Microsoft.CodeAnalysis' assembly was missing, causing Swagger UI load to fail. By adding this assembly, the ChatGPT (or, SK's chat-copilot) will now be able to fetch swagger.json.
Contribution Checklist

[x] The code builds clean without any errors or warnings
[x] The PR follows SK Contribution Guidelines (https://github.com/microsoft/semantic-kernel-starters/blob/main/CONTRIBUTING.md)
[x] The code follows the .NET coding conventions (https://learn.microsoft.com/dotnet/csharp/fundamentals/coding-style/coding-conventions) verified with dotnet format
[x] All unit tests pass, and I have added new tests where possible
[x] I didn't break anyone :smile:

This solution is missing from https://github.com/microsoft/semantic-kernel-starters/blob/main/sk-csharp-chatgpt-plugin/azure-function/sk-chatgpt-azure-function.csproj. Please update the file as it is throwing error without the reference.

Hi @thegovind! Thanks for the PR - we found a similar issue in the sk-csharp-chatgpt-plugin starter and updated the README for how to run it in this PR. Were you running the chatGPT plugin starter when you ran into this issue or the sk-csharp-azure-functions starter?
I'm not able to reproduce this issue in the Azure Functions starter but note that I'm accessing Swagger UI at http://localhost:7071/api/swagger/ui.

Hi @thegovind! Thanks for the PR - we found a similar issue in the sk-csharp-chatgpt-plugin starter and updated the README for how to run it in this PR. Were you running the chatGPT plugin starter when you ran into this issue or the sk-csharp-azure-functions starter?
I'm not able to reproduce this issue in the Azure Functions starter but note that I'm accessing Swagger UI at http://localhost:7071/api/swagger/ui.

Getting the issue when I try to pull swagger.json, which is also the case for ChatGPT

Hi @thegovind, can you still reproduce this issue when you run the chat GPT plugin project using the updated steps here: https://github.com/microsoft/semantic-kernel-starters/blob/main/sk-csharp-chatgpt-plugin/README.md#running-the-starter?

Hi @thegovind, can you still reproduce this issue when you run the chat GPT plugin project using the updated steps here: main/sk-csharp-chatgpt-plugin/README.md#running-the-starter?

So these two lines did address this issue. However, we still have to update GetAIpluginJson and aiPlugin in appsettings.json to return OpenAPI 3.0 compatible spec:


fix: add types to package.json exports map

when using ts with "module": "nodenext" / "bundler", the types field is expected on exports in package.json.

LGTM btw Have you tried checked package with https://arethetypeswrong.github.io/ ?

Have you tried checked package with https://arethetypeswrong.github.io/ ?

haven't heard of that before, thanks for the link!

Good spot - thank you! 😄


Commit to setup.py missing an import

Please make sure that this is a build/installation issue. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:build_template
System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 18.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary): Source
TensorFlow version: 1.13.0
Python version: 3.6
Installed using virtualenv? pip? conda?: building pip wheel
Bazel version (if compiling from source): 0.24.0
GCC/Compiler version (if compiling from source): 7.3.0
CUDA/cuDNN version:
GPU model and memory:

When attempting to build pip the process fails with the following:
prompt:~/path/tensorflow$ ./bazel-bin/tensorflow/tools/pip_package/build_pip_package /tmp/tensorflow_pkg
Wed 27 Mar 20:48:26 GMT 2019 : === Preparing sources in dir: /tmp/tmp.RsnPbFm3Zx
~/path/tensorflow ~/path/tensorflow
~/path/tensorflow
Wed 27 Mar 20:48:30 GMT 2019 : === Building wheel
Traceback (most recent call last):
File "setup.py", line 276, in
Extension(
NameError: name 'Extension' is not defined
I ran:
bazel build --config=opt //tensorflow/tools/pip_package:build_pip_package
then attempted to run:
./bazel-bin/tensorflow/tools/pip_package/build_pip_package /tmp/tensorflow_pkg
and got the above error.
Commit e5778e4d763493b0b3ec05a9f5658a04aed47a3f added
Make setup aware this is an extension that cannot go into purelib.
ext_modules=[
Extension(
name='tensorflow',
sources=[],
)
],
but missed the import to ensure Extension was available.
I added from setuptools import Extension and it appears to be working (I haven't proceeded past that step yet though).
I'll update once I know if my build was actually successful (which may be tomorrow morning, GMT)

Just to confirm - with the import, everything appears to work fine.

Looks like commit fea98099e68bcdcd567afbabf2dabc8cf3ad4987 fixes the issue.


(Unga) Relauching GGST without closing Totsugeki greatly increases startup time

https://files.catbox.moe/mzj0wx.mp4
Test method: launched and closed GGST sequentialy. Went as far as the floor menu but no change there, all took ~6-8s. Relaunching Totsugeki -unga fix the issue.
Even accounting the time it took for the first startup to "warm up" the difference is huge. 4th one happened to be the slowest of all but given the consistency it should be just communication differences.
Two separate tests with normal Totsugeki gave me ~1:10 to menu, so the speedups are either not in effect or being greatly limited by something.

As this isn't the intended usage I'm sharing it for debug purposes (reason why I use the -no-close flag), but in case there's no fix you could add a note next to -no-close.

Side effect of the fix in #51. Because the stats_get_prediction stays in finished state forever now every game start after the first one will be slower.
Gonna try to get a fix out soon ™

Thanks for the report and fix!

Had a short test session and the PR worked, closing and opening the game again didn't reproduced the issue.
After a few games I had a network error - training in lobby, quit to floor menu and tried to reenter > disconnect - likely unrelated to 🐬 but here are the steps for further testing.
This network error threw me back to start menu (normal behaviour sadly). Entered the main menu (still disconnected, normal) and then went to Network to trigger a reconnect. This reconnect however was a slow one, with Totsugeki window behaving just like the reported cases.
Does it pass through different steps from start? I clearly remember reconnecting from there with speedups in effect.

So I just did some tests with R-Codes with #57. This works with viewing R-Codes in the park or tower, but doesn't work if you view multiple R-Codes through Rankings since there's no /tus/read call to reset it.
I'm thinking it might be better to just do some heuristics.

If all expected calls are complete, reset.
If a call that was complete gets called again, reset and clear all the queues.

This should in theory cover everything.

Damn it 😆 I only tried tower and replays and loading multiple r-codes worked there.
I'm gonna take another look at it and see if I can solve it your way. Using those conditions to reset sounds a lot better than using random requests that come after the stats ones.

🙏 https://github.com/optix2000/totsugeki/releases/tag/v1.5.0


file: Update Facebook logo

This PR fixes #1524
What's new?
Replace the old Facebook logo with the new, optimized logo (200x200) similar to #1361

Old
New

This is great! Can you resolve the merge conflict?

Thanks @rickhanlonii . I cannot resolve the conflict (the option is disabled). The conflicting files are only the Facebook logo that I’ve updated.
Can you please tell me how can I fix it? Thanks!

@elharony it looks like you branched off of master before your other change landed which means facebook.png is different on both master and on this PR, so git doesn't know how to resolve the conflict.
In order to resolve manually you'll need to checkout your branch locally.
If you give me access to edit the PR then I can push up a fix for you!

Hey @rickhanlonii, I tried to do it myself, but it seems that I did a huge mess! 😄

Oh yeah, that happens! To fix, I would rebuild the branch from master with the change you want and then force push to this branch.
I have it fixed locally but I’m not allowed to push to your repo, if you give me access I can help out 👍

Thank you, @rickhanlonii 🙋🏻♂
Just added you as a collaborator on my repo so you can push 🤞🏻

Hm I still can't push to it :c

If you want, you could re-pull master, add the changes, and submit a new PR

Good idea, @rickhanlonii . Done! 👍


Can you go into detail about why this doesn't work with aurora-postgresql?

I wondered this too and ultimately wrote my own function because this one didn't support deletion on multiple schedules (our org prunes the data at different intervals). But I believe it just needs a slight code change to include postgres, there should be no difference in the way snapshots are handled by the aws api the way i understand it. I haven't tested this but you could try it by changing line 42 in the snapshot_tool_utils.py to include a second value in the list.
_SUPPORTED_ENGINES = ['aurora', 'aurora-postresql']

@ahartma1 I had a successful experience by implementing your suggested change.  I'll close this issue, but suggest that awslabs go forward with this expansion of supported engines.


Better getting started with julia documentation

This PR adds a "Getting Started with using Julia in Projects" page to the documentation which gives an (opinionated) guide to setting up Julia for project development.
Closes #277 .
This PR doesn't change the README.md file for EpiAware, although I'm happy to do another quick PR to update that and give a link to the page if this PR is accepted.
@damonbayer I'd be interested in your thoughts/preferences here.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Please upload report for BASE (main@8166227). Learn more about missing BASE report.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #301   +/-   ##
=======================================
  Coverage        ?   92.85%
=======================================
  Files           ?       47
  Lines           ?      490
  Branches        ?        0
=======================================
  Hits            ?      455
  Misses          ?       35
  Partials        ?        0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Really really nice, @SamuelBrand1! No changes immediately come to mind. Pinging @thanasibakis for his thoughts.

I think this reads really well!

Made some changes:

Hopefully clarified and rejigged it in response to @zsusswein comments.
Clarified/corrected the order of primacy in stacked environments bit.


repo missing

.github repo missing.

In this repository, underneath subfolder orgs/osism/repositories there is a file missing (.github.yml) for the repository .github

@tibeer Please use more useful issue titles in the future.


[v1.16] deps: update Docker dependency

Stops https://github.com/advisories/GHSA-v23v-6jw2-98fq from appearing in container vulnerability scans. This is for tidiness, Cilium is not affected by this issue.

/test-backport-1.16

/test-backport-1.16


experiment with react context for theming

this will come up.  it's on the roadmap.  doesn't need an issue to track.


[core] Improve <Options/> component

Various improvements for the <Options .../> component:

disable wrap on the Button, to allow usage in flex layouts that should take 100% screen width
add export lines for times.ts and Options.tsx
improve time related types

[ ] I adjusted the corresponding documentation for this change.
[ ] I adjusted the values.yaml for the hub / values.yaml for the satellite file and the documentation for all values.

same changes are inside https://github.com/kobsio/kobs/pull/472


00236e madpsintst

This is the mask for 00236e from the imgs2 series. This is my first mask creation. Not sure if I did it correctly.

You have to submit a pull request to the commai/comma10k repository, not yours


global version of jss.

It'd be super nice if the scripts section of package.json had a script using browserify or webpack to compile a standalone bundle to run in the browser that adds jss to the global scope. Some people could benefit from this right away in certain scenarios depending on their stack.

You mean like loading jss + styles separately before everything else to let it style quickly the page without to wait for all other scripts?

Kinda bundling feature, I think we can add it to jss-cli

@kof Not quite, I meant something like https://github.com/jsstyles/jss/pull/63.


Assign valid partitions for messages with leaderless partitions

Don't fail messages assigned to partitions which are now leaderless. Just assign an available partition and try to send them again. Producer has to use round robin / random partitioner, where ordering is not important.

This is extremely difficult to accomplish with our current architecture for various reasons. It's definitely not going to happen in the short term, though maybe long-term we'll rewrite the producer and fix this along with a bunch of other minor issues.

We would be very interested in this. From a cursory check it seems feasible. If we worked on it would you accept a PR?

I'm happy to take PRs, with a few caveats:

I'm very busy right now with other things, so feedback is going to be slow or non-existent for probably the next month
Per my previous comment on this PR I expect this to be a fairly substantial undertaking. If you think you've found a less intrusive way to accomplish it that's great, but I remain skeptical. It's probably best if you propose specific changes here before spending too much time coding.

We solved by using round-robin and resubmitting failed messages up to N times (we can tolerate out-of-order messages)


AdminApplication or AdminSite?

maybe pick one or the other for consistency?
new CfnOutput(this, 'AdminApplicationECR', { value: baseline.adminSiteEcrUri });

Fixed


Handle 0-byte reads correctly (fixes #520).

We were incorrectly assuming a 0-byte read from libuv indicated a connection end. This is wrong, since according to the docs when the read callback is called with a zero status that only means there is no data available to read at the moment. This can be safely ignored.
#520
cc @halter73

:shipit:

I still think we should find a way to turn the repro app into a test case somehow.
I know it the repro app depends on a lot dependencies on top of Kestrel, but maybe that would be OK if the test lived in the ServerTests repo. Were you only able to repro using the browser on the client?
The fix looks good though.

@halter73 where is the repro app and what was failing before?

You'd have to ask @cesarbs were the app is. The part I saw wasa form-based file upload that saved to disk. I know it took a while to get a repro initially, so there might have been done trick I'm leaving out. We already have large request tests that have never failed in this way, so it isn't trivial to test.

what was failing before?

I don't know what you mean. #520 covers it pretty well. Kestrel prematurely closed the connection in the middle of the upload because it misinterpreted the 0 status in the read callback.

Might be a PITA to repro. At least the docs are pretty clear about it.

It's definitely a PITA to repro. I almost gave it a :shipit:, but zero regression tests for this kind of fix feels bad. If we can't do a functional test, we should do a unit test. We already have a MockLibuv class we use to test SocketOutput.

@davidfowl The sample app is any app that can accept large file uploads. The issue likely also repros by just sending a large request body to Kestrel, but I've had more consistency/success when using an Mvc app and uploading a large (>1GB) file.
I used this to get a repro:
https://github.com/JosephGarrone/ASPNetUploadError
It's an RC1 app, but I moved it to the latest stuff.

Fixed the leak, now working on a test.

Rebased & squashed.

:shipit: Once you address my last comment.


Adding LICENSE File

Hey @Vincenius I observed that you have linked the MIT license link but in order to add the License to this repository one must create a file for it
Would it be fine if I add the License file?

Sure go for it! Thanks!


Revert "Adding a replication controller for all monitoring pods."

This change causes monitoring.sh to hang on the GKE provider.
Reverts GoogleCloudPlatform/kubernetes#3489

See #3558.

Self-merging to fix build.


Wrong format for sc.w

According to example in page 42 of RISC-V User-Level ISA V2.2, the format seems to be:

sc.w rd,rs2,(rs1)

and not

sc.w rd,rs1,rs2

as in the deployed docs.

Also according to the official testsuite, as my implementation of sc.w can only pass the testsuite if I use the former.


refactor: rename open to github

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 75.325%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
116

Relevant Lines:
154

💛  - Coveralls

/lgtm

LGTM


test: duplicate L1 layer

We overwrite L1 layers if compaction gets interrupted. We did not have a test showing that we do in fact do this.
The test might be a bit flaky due to timestamp usage, but separating for smaller diff in as part of #5172.

Now to get back to this: overwrite does not seem to happen every time.


TypeScript declarations

@niftylettuce Are you interested in hosting the typescript declarations in this repository or even convert this project to typescript?
There already exist type declarations under @types/later which in case you don't want to copy them to this repository, would need to be published under @types/breejs__later by doing a pull request to DefinitelyTyped. For users it might be easier to ship the declarations directly with this package.
Also I just saw that you combined all the files into a single huge index.js file which IMO makes it harder to read the code. Could you clarify why this change was made?
Thanks for maintaining later! ❤

Hey thanks for filing this, unfortunately I don't support TypeScript on any of my projects.  It's bad for open source and development in general.  I combined them and fixed the tests.  The code was already hard to read and had several bugs and I had limited time to do this so that was the best approach.

Curious as to why not leverage the work already done for @types/later?
Seems an easy fix for a relatively large win for any typescript users who want to use this library.

Like I said I strictly don't support TypeScript.  It's really bad for the open source JavaScript community.


implement CO-RE gripper

Thanks again!
A few comments which should be quick to resolve:

I don't think commands like get_core and put_core should be part of an abstract liquid handler backend, because they are extremely Hamilton specific. Instead, I think move_resource in Hamilton should have a flag use_arm that takes "iswap" or "core", and then calls the corresponding method on itself. Currently it always uses iswap (pick_up_resource, move_picked_up_resource and release_picked_up_resource, which could be renamed to iswap_*).

It seems that the channels used are hard coded. Could you make those parameters?

Could you remove the build/lib folder?

your wish is my command! I'm not sure I implemented these changes in the most developer-friendly way, but I do think it is now abstracted as you'd prefer. this makes a lot of sense from the perspective of supporting many different robots.

Could you enable the option "Allow edits from maintainers" on this PR so that I can push to your branch? I made some small refactoring changes.

It looks like github organization accounts don't have access to this option, so I just gave you write access instead - should be equivalent?

That works! I think "duplication is cheaper than the wrong abstraction" here.
I made iswap the default arm for movements, to be consistent with earlier versions.
Lastly, could you get a firmware string to write a unit test for this method?

Very nice changes - much better this way.
I made the CO-RE gripper the default arm for movements because in practice, we use it for >90% of all movements inside the deck. It is much faster, more reliable, and less error-prone than the iSWAP gripper. From a pure function standpoint, making the CO-RE gripper default will match how (I think) most hamilton experts will be using their robots.
Here are the firmware strings for your newest Move() function using the CO-RE gripper with pickup_distance_from_top=13:
Get CoRe gripper tool:        C0ZTid0020xs07975xd0ya1250yb1070pa07pb08tp2350tz2250th2450tt14
Get plate using CoRe gripper: C0ZPid0021xs04150xd0yj1145yv0050zj1876zy0500yo0890yg0830yw15th2840te2750
Put plate using CoRe gripper  C0ZRid0022xs04150xd0yj2105zj1876zi000zy0500yo0890th2840te2750
Discard CoRe gripper tool:    C0ZSid0023xs07975xd0ya1250yb1070tp2150tz2050th2450te2450

Let me know if I should make the tests too - unsure how granular these should be when you already have pretty great coverage on the iSWAP tests

I just noticed something interesting about the pick_up_tips function. Typically during a process, I won't know exactly what tiprack I am picking tips from. There is a good chance I will need to pick up tips from more than one different tiprack (if I am on tip #94, but on my next pick_up_tips command I need to pick up 8 more tips, so I should pick up 1 tip from the first rack and the other 8 tips from the next rack). But as the pick_up_tips implementation currently stands, there's no way I can handle tip pickup from an arbitrary number of different tipracks - I can only pick up tips from a single rack resource.
In pyhamilton, this is solved by inputting [(rack, index), (rack, index), ... ] but in pylabrobot, this is set up as rack[index, ... ]
What do you think is the ideal abstraction for adding this functionality?

Thanks for the strings, I'll add tests.

What do you think is the ideal abstraction for adding this functionality?

This should already be possible! When you index a tip rack, you get back a list of TipSpot objects (not Tip, because that wouldn't work with drop_tip). You should be able to pass a list with TipSpots from multiple tip racks: lh.pick_up_tips(tip_rack_a["A1"] + tip_rack_b["A1"]).
For your application, perhaps it'd be neat to use a generator:
def get_tips(n):
  index = 0
  max_tips = 96 * num_tip_racks
  spots = tip_rack_a.get_all_items() + tip_rack_b.get_all_items() + ...
  while index < max_tips:
    yield spots[index:index+n]
    index += n
  raise StopIteration()

What happens if the grippers are mounted before setup is called?

good catch! currently the STARlet will just throw the co-re grippers in the trash (same behavior if it detects pipettes during setup(). I am unsure if there is a way to detect the difference between a pipette tip and a CO-RE gripper...

Do you think anything should be changed before merging?

I think this is great to go. Thank you very much on all the help & feedback!

a historic occasion for PR #42 - thanks for making it happen!

Thanks for the work!


Azure Health Insights Sample Issue

Section link1, link2:

Reason:
@azure/identity is not installed.

Section link1:

Reason:
ClinicalDocumentTypeEnum is not defined.

Section link1:

Reason:
radiologyInsightsData is not defined.
@joheredi, @koen-mertens and @tomsft for notification.

Looks like the Monitor-ApplicationInsights team was mistakenly automatically added here.


client interface for Optic enhancements

The enhancements are as follows.
fromSearch() accessor
fromSearchDocs() convenience
groupByUnion() and groupToArrays() modifiers
facetBy() convenience
group(), rollup(), cube(), and namedGroup() helpers
hasGroupKey() aggregate
bind-as() modifier
in() operator

Includes unit tests
JavaDoc for new manually maintained interfaces still todo

Includes unit tests
JavaDoc for new manually maintained interfaces still todo

The latest commit (4634719) relaxes a limitation in that getString() now supports anything other than a binary node.
Previously, getString() only supported atomic values.
Thus, negative testing that confirms the limitation might start failing.

The latest commit (4634719) relaxes a limitation in that getString() now supports anything other than a binary node.
Previously, getString() only supported atomic values.
Thus, negative testing that confirms the limitation might start failing.


Error connecting with cloud provider vcloud

Hello everyone
I need to show the ManageIQ with VCloud with their graphics. Sadly, I can't connect to vcloud 5.5 like cloud provider. It always show me after the validation:
"Login failed due to a bad username or password." but the credentials are corrects.
Does anyone knows when will be the fix or what fix is there right now?
Should I make a configuration previously in manageiq or VCloud? -- I can do log in to VCloud using the web.
Please, I need someone help me or answer my question.
Thanks

@Joseluismantilla ensure you are specifying your username as  "user@ORG"; otherwise it will not work.
I have successfully logged added a vCloud 5.5 provider with the current latest ManageIQ bundle (euwe-2).

@Joseluismantilla has this issue been resolved?

Closing as stale; please feel free to reopen the issue if you're still having problems. Thanks!


Support passing custom metadata per query to middleware

Problem
Currently the middleware are essentially stateless. There is one example that uses global state but in practice this is not very common nor desirable. It would be necessary for a tracing middleware.
Suggested solution
It would be nice if all prisma calls add a context parameter that would be passed down to middlewares.
It could look like:
export type TicketCreateArgs = {
    select?: TicketSelect | null
    include?: TicketInclude | null
    data: XOR<TicketCreateInput, TicketUncheckedCreateInput>
    context: Record<string, any>
}

export type MiddlewareParams = {
    model?: ModelName
    action: PrismaAction
    args: any
    dataPath: string[]
    runInTransaction: boolean
    context: Record<string, any>
}

Alternatives
No good alternative currently if you want to respect typing, unsure if I could pass the context in the data and remove it in the middleware, but I would prefer not too.

Similar to https://github.com/prisma/prisma/issues/4217

I see a lot of moving around of the milestones on this one. Is this something that is considered for implementation short term?

Milestones mean we are looking at things or thinking about them. Things are also taken out of milestones because of changing priorities. Our only communicated roadmap is our Roadmap: http://pris.ly/roadmap It is on another level though, so will not reflect smaller features like this one most of the time.

This related issue lists a relevant use case for this and why this might be helpful: https://github.com/prisma/prisma/issues/5128#issuecomment-848890199

to provide context for middleware it's better like this, IMHO
const prisma = new PrismaClient()

// for per request
prisma.$context = ({ req }) => ({
    mydata: "foo"
 })

prisma.$use(async (params, next, /* !!! * /context) => {...}

like as Apollo

related https://github.com/prisma/prisma/issues/10895

I would also find this useful.  I'm trying to write a piece of auditing middleware and one of the things I want to store in the audit records is the userid of the user making the request. I can get this information from my GraphQL resolver and then I'd like to pass that as context in each Prisma query where it can then be read by my audit middleware.

+1.
Very useful for logging so we could track what sort of requests triggers what. A context: Record<string, unknown> or Record<string, string|undefined> would be nice

We are also very interested in this possibility as well.
At the moment we are using the following workaround:
We are adding a json field to the models, wich we will use in the middleware (prisma.schema).
model Abc {
  filterConfig Json? // Just for middleware purposes
}

This field is never holding data in our scenario. This field makes it possible to be used in findMany and findFirst where-arguments. Since it is a json field, we can pass in any data to the middleware like so:
prisma.abc.findMany({
  where: { filterConfig: { equals: [CONTEXT] } }
});

In the Middleware we have to Reset the Field, before it will be send to the database:
if (params.args?.where?.filterConfig) {
  delete params.args.where.filterConfig;
}

Hey folks, we started speccing this out this and we're ready to share our proposal. Please let us know what you think!
I'd also like to invite you to jump on a call with me to get your thoughts on the proposal.

Overview
Today Prisma users can’t selectively opt-in or out of middleware functionality.
If we allowed developers to turn on certain middleware per-query, we could make middleware more useful because the middleware would be able to make decisions based on the context the query was made.
Use Cases

Custom middleware that omits returning the password everywhere except login: https://github.com/prisma/prisma/issues/4217
Using metadata to run a set roles and users in a custom middleware for row-level security (RLS): https://github.com/prisma/prisma/issues/5128#issuecomment-848890199 & https://github.com/prisma/prisma/issues/10895
Selectively decrypt certain fields: https://github.com/prisma/prisma/issues/9879

For example, if a metadata object containing { decrypt: true } is passed, we decrypt fields. Otherwise the default is to pass fields back to the application in their encrypted state.

Pass a trace ID through and use custom middleware to add tracing: https://github.com/prisma/prisma/issues/6882

Goals and Product Requirements

You can pass arbitrary data per query to middleware
The metadata is modifiable along the middleware chain
Nice to have: There should be some way for users to make it type-safe. Sharing a user-defined type across files would be fine.

Out of Scope

Automatically passing context to multiple queries: We can potentially address this with a feature like [Model Scopes](https://sequelize.org/docs/v6/other-topics/scopes/), but for now you need to pass metadata per query.

Open Questions

Should metadata be modifiable along the middleware chain or read-only?
Yes, from @Andrew Carlson:

I can think of some use cases to updating the meta object within the middleware chain. Notifying of mutations, notifying of errors, etc.

How would this affect transaction rollbacks?

Would middleware be the only part of the API that has access to this metadata?

Is there a use case for global metadata? ([PR includes this support](https://github.com/prisma/prisma/pull/9759))

Approach
Add support for a meta field that can to be passed through all of our query objects.
code. This meta field has the type Record<string, any>. This meta data would be accessible through the middleware stack:
// include a password only when explicitly passed in
prisma.$use(async (params, next) => {
  const result = await next(params);

  // TODO: is there a way to make "params.meta" type-safe?
	if(params.model === "User" && !params.meta.includePassword) {
		const { password, ...rest } = result;
		return rest;
	}

	return result;
})

// encrypt by default
prisma.$use(async (params, next) => {
	if (params.model !== "User") {
    return next(params)
  }
  // encrypt by default
	if (params.action == "create") {
    if (args.data["secret"]) {
       args.data["secret"] = encrypt(secretKey, args.data["secret"])
    }
  }
	// pass along
  const result = await next(params);
  // return encrypted unless
  if (params.meta.decrypt) {
    result["secret"] = decrypt(secretKey, result["secret"])
  }
  return result
})

All APIs that can be modified by middleware would support this meta field:

// Omit passwords unless includePassword is true
prisma.user.findMany({
  where: {
    email<EMAIL_ADDRESS>  },
  meta: {
    includePassword: true
  },
})

// Encrypt secrets unless decrypt is true
prisma.user.findMany({
  where: {
    email<EMAIL_ADDRESS>  },
  meta: {
    decrypt: true
  },
})

// Create an encrypted user that gets returned back encrypted
prisma.user.create({
  data: {
    name: "Alice",
    email<EMAIL_ADDRESS>    secret: "my dark secret",
  },
  meta: {
    decrypt: false
  },
})

// Yes, even groupBy!
prisma.user.groupBy({
  by: ["email"]
  meta: {
    decrypt: true
  },
})

References

Discussion that aggregated some of these requests together https://github.com/prisma/prisma/discussions/13366

For type safety I would highly suggest to generate one meta interface per query that is an extension of the global one you have defined in your proposal. This would allow users to define meta per query if they need to or globally.
I know that custom types / extensions are coming at some point and I believe those functions will need access to meta. A simple example would be a luxon DateTime custom type that takes into account the timezone of the requester.
I believe a global context / meta is vital in the long run. In your encrypt / decrypt example the secret would be a good candidate for that, currently it appears from nowhere. Another example could be a shared redis connection / in-memory structure for used caching responses. The would be ideal for a prisma middleware solving the N+1 problem.
For the rollback problem. I am a fan of the "never throw, return a result" approach that is used in rust. I believe that prisma could take a page out of that book and the next function could guarantee to always return / never throw. The writer of the middleware would have to check if the result was an error or the data and handle it.
Hope that helps!

I believe a global context / meta is vital in the long run. In your encrypt / decrypt example the secret would be a good candidate for that, currently it appears from nowhere

Would wrapping middleware in a function satisfy this requirement for you @Sytten ?
E.g.
// Definition
function encryptor(secret) {
  return async (params, next) => {
    // use the secret...
  }
}

// Usage
prisma.$use(encryptor(someSecret))

Yeah the proposal seems good for the wrapper function.

What do you think about this @SevInf?

That seems sensible. However, one follow-up question: when we say "per query", do we mean having, say, FindFirstMeta type or UserFindFirstMeta?
With a single type, like in current proposal, ensuring meta type for both middleware callback and and an actual function is trivial. With separate type per action, it's still doable at the cost of generating slightly more complicated type for middleware params. With one type per model and action this type has to be huge union of cartesian product of all models * all actions which might be problematic for people with a lot of models and not a lot of use meta field. So, I'd suggest we stop at action only for now, proposal is updated.

which might be problematic for people with a lot of models and not a lot of use meta field. So, I'd suggest we stop at action only for now, proposal is updated.

This sounds very reasonable to me.

Awesome, it seemed like most issues have been resolved. Unless I hear otherwise, I'd say we have consensus around the design and so I've just candidated this. We'll get started on this soon!

@matthewmueller would the Prisma query engine log the arguments? As I understand, the middleware runs on NodeJS while the actually query under the hood is ran by a rust engine.
prisma.$on('query', (e) => {
  console.log('Args ' + e.args)
})

Would this be possible? I am trying to catch slow queries. Tracking how long time a query takes in the middleware is not accurate (I measured - e.duration in the prisma.$on is considerably smaller than measuring manually in the middleware.
If the arguments could be passed for the prisma.$on to access that would be perfect - it would then be possible to catch queries that take longer than X time and given the arguments know where they came from.

Any news about this feature? I would love it in order to cleanly implement audit trails using Prisma Middlewares 🙂

Any news?
We are developing a microservice-based project by using Prisma as our ORM, we need to set the correlationId generated by the gateway per request and set the correlationId in the context of the logs in Prisma Logging middleware.

No news yet unfortunately.
We added "Client Extensions" to Prisma recently as a preview feature. Its query component is similar to middlewares. We are currently working on improving that and think this might actually support this use case earlier than we add it to middleware (if ever - Client extensions seem to be more flexible in all ways).

One more thing to add: depending on your usecase, we might have a viable alternative with extensions already. If your metadata is session-scoped, you can create one extended client per request. Here is a simple logging extension example, that adds sessionId to each log:
app.get('/', (req, res) => {
   const sessionPrisma = prisma.$extends({
       query: {
          $allModels: {
             $allOperations({ model, operation}) {
                  logger.log(req.session.id, model, operation)
              }
          }
       }
   })
})

Don't worry, $extends is designed to be as lightweight as possible with this pattern in mind - it won't create any new connections to the database or do anything heavy.

Hi, just wanted to share this solution that @sbking provided on slack... it solved the problem for us:
You define an extension function that takes the metadata as an argument and returns the prisma client with the extension that uses the custom data:
function myExtension(user: string) {
  return Prisma.defineExtension({
    query: {
      myModel: {
        findMany({ args, query }) {
          // Here you can access the `user` context and mutate `args` before calling `query`
        },
      },
    },
  });
}

Here is how you use it:
const prisma = new PrismaClient();

const user1Prisma = prisma.$extends(myExtension("user1@example.com"));
const user2Prisma = prisma.$extends(myExtension("user2@example.com"));

Hope it helps.

Hi, just wanted to share this solution that @sbking provided on slack... it solved the problem for us: You define an extension function that takes the metadata as an argument and returns the prisma client with the extension that uses the custom data:
function myExtension(user: string) {
  return Prisma.defineExtension({
    query: {
      myModel: {
        findMany({ args, query }) {
          // Here you can access the `user` context and mutate `args` before calling `query`
        },
      },
    },
  });
}

Here is how you use it:
const prisma = new PrismaClient();

const user1Prisma = prisma.$extends(myExtension("user1@example.com"));
const user2Prisma = prisma.$extends(myExtension("user2@example.com"));

Hope it helps.

@mdesousa  You are not going to create a prisma instance per user. So I am not sure how it helps. Can you please explain?
One more doubt in general, not specific to your solution. Here we are putting the meta on the prisma client. But the same client is being used for all requests, but that is not a problem since node engine is single threaded? But then what if while prisma is waiting for data for request 1 another request 2 comes, which uses the same prisma client and overwrites its meta? How is this different from using a global hash map?

Using AsyncLocalStorage should mitigate the multi-request concerns.

Oh cool! So I can then simple write...
asyncLocalStorage.run(context, async () => {
    // All codes calling prisma. which need the context. Now I can read this context using asyncLocalStorage.getStore().
});

So, why are we requesting this feature for prisma? Because that will be more cleaner and type safety?

@mdesousa You are not going to create a prisma instance per user. So I am not sure how it helps. Can you please explain?
One more doubt in general, not specific to your solution. Here we are putting the meta on the prisma client. But the same client is being used for all requests, but that is not a problem since node engine is single threaded? But then what if while prisma is waiting for data for request 1 another request 2 comes, which uses the same prisma client and overwrites its meta? How is this different from using a global hash map?

@applegrew Prisma Client Extensions are designed to be lightweight, and you can create as many extended clients as your application needs. Each extended client shares the same connection pool and query engine, but calling $extends creates a new extended instance without affecting the base instance or other extended instances.
Depending on your framework, you can likely create an extended client instance per request. For example you can attach it to the req object in Express, the context object in GraphQL, etc.

What I'm doing wrong? I've tried prisma 4.7.0, 4.7.1 and 4.8.1 but I'm always getting this:

Update: I was only bumping "prisma", forgetting about "@prisma/client" dependency

For customers that are already using middleware, how can they use client extensions considering that the client extensions are entirely different type (i.e. lacking the $use property), so they can't consume middleware like regular clients? This puts at a bind, because:

We use middleware extensively and the PrismaClient speaks that.
We have a need for some context in queries. Using extensions (which do add context) is impossible because we can't hook them up with the middleware we already have.

More generally, I think Middleware and Extensions seem to be competing products that did not account for folks using both?

@why-el middlewares and extensions can be used together, but you have to add all middlewares before adding any extension:
// this works
prisma.$use(middleware1);
prisma.$use(middleware2);
const xprisma = prisma.$extends(extensions)

// this does not
const xprisma = prisma.$extends(extensions)
xprisma.$use(middleware)

This is implemented that way because middlewares and clients work slightly differently - extensions create new "fork" of the client, leaving original instance untouched, why middlewares modify it (and would modify ALL forks created before or after $use call as well if we allow to call $use after $extends).
So, if you need to use your existing middlewares together with extensions - go this route, add all middlewares before you add any extensions. For the future, you might also want to look into query component of the extensions - conceptually, they are very close to middlewares and we expect that most of the stuff you can do with middleware could also be done with query extension.

Moving some comments from https://github.com/prisma/prisma/issues/5923 over here:

Also looking for a solution like this! My current use case is a multitenant app where middleware could be used to augment all queries / inserts with the tenant id based on the request.

Originally posted by @brandonwestcott in https://github.com/prisma/prisma/issues/5923#issuecomment-822511686

This is indeed needed or some way to pass down contextual data. If you want to for example generate a papertrail of the changes in a record that you end up missing WHO did it because of this lack of context.
Perhaps a way to remove the middleware or something like client.setContext(whatever)
and
// Middleware 1
prisma.$use(async (params, next, context) => {
    // do something with the context here
    const result = await next(params, context);
    // See results here
    return result;
})

I was actually developing a library for Blitz.js but hit this roadblock

Originally posted by @ntgussoni in https://github.com/prisma/prisma/issues/5923#issuecomment-841865716

The context feature request is probably better covered here: #6882 + #4217

I think that what I specifically mean is a more global context and not specifically tied to any method.
For example: I want the prisma middleware to have access to the logged in user regardless of the method im calling.
With the approach being discussed in those tickets, I would have to add the ctx to every single method I run.
client.foo.findOne(..., context)
client.bar.findMany(..., context)

Which forces you to remember passing that every single time and it makes it impossible to write libraries on top of prisma, because you need the devs to change everything.
What Im aiming for is something more like this.
const client = new PrismaClient() // Initialised somewhere
...
client.context(whatever);

// middlewares now have access to context

This particular example gives you the chance to inject things like the logged in user or even a tenant and be able to use it safely.
With the current approach we have to call client.use$ in a closure  every time we want to change the context, but then we have no way to remove the middleware.

Originally posted by @ntgussoni in https://github.com/prisma/prisma/issues/5923#issuecomment-850292674

I wanted to add an example here as I had to solve this same use case. The solution is basically what's described here https://github.com/prisma/prisma/issues/6882#issuecomment-1363756085
What I wanted for logging/metric capture purposes was:

General scope context for a set of queries
Operation specific context for a given query within that scope

A quick example to achieve this leveraging extensions and mutating arguments is below.
const client = new PrismaClient();

const getClientWithContext = (scopeContext: string) => {
  return client.$extends({
    query: {
      async $allOperations(props) {
        const { __queryContext, ...args } = props.args as any;
        const query = props.query;
        // do whatever you want with the scopeContext and __queryContext
        return await query({ ...args });
      }
    }
  });
};

function withQueryContext<T>(args: T, { queryContext }: { queryContext: any | yourTypeHere }) {
  (args as any).__queryContext = queryContext;
  return args.
}

async function getFoo () {
  const fooClient = getClient('fooContext');

  const foo = await fooClient.bar.findUnique(withQueryContext({
    where: {
      id: 1
    }
  }, { queryContext: 'fooBarQueryContext' }));

  return foo;
}


Harden reflection scanner against invalid IL

Should help with the KnownGood test failures seen in #7157.
The IsValid check in Skip should be all that's needed to fix the observed failures, but I went ahead and hardened it against other invalid situations (end of body in the middle of an instruction, or bad calls).

Cc @sergiy-k

Thank you!


Broken links within README

Describe the bug
The hyperlinks for 'Install Dart' and 'Our main docs live here' do not work
To Reproduce
Steps to reproduce the behavior:

Go to README for the project
Click on both hyperlinks
Neither will load the proper webpage

Expected behavior
The correct web pages are displayed

going to rework documentation completely


Let types specify a display format

It can be helpful (think forms) to have display formats associated with each type.  I could do this with a behavior, but it seemed better to integrate it with types so that you only need to define the formatter function once (in the type definition).
Not sure if there's a simpler way to implement this, but here it is, if you're interested.
To the developer, the changes are:
Inside type definition, can add an attribute 'display':
Astro.createType({
    name: 'currency',
    cast: ...
    display: function(value) { return accounting.formatMoney(value); }
});

If I have a field 'dollars' with type 'currency', I can then simply do:
obj.getDisplay('dollars')

to get the properly formatted version.  getDisplay also supports requesting via the other fieldOrPattern styles.
You can also take a parameter argument in display() and pass it in getDisplay(), for example to specify a number of decimal points:
obj.getDisplay('dollars',2);

If you like it, I can update the documentation for types, as well.

Hmm I don't know if it's good idea to mess with types in this way. Number formatting is something more related with VIEW layer than MODEL. Type is type. Currency is still of number type. I see TYPES more like something that it's not of other already defined type. Let's take for example imaginary number, address (combination  of city and state), geolocation etc.
What I would suggest is creating conctructor Currency which would have getFormatted function. It would store number.
Currency = function(n) {
  this.amount = n;
};

Currency.prototype.getFormatted = function(params) {
};

And this type would be registered so you could do as follows.
obj.get('price').getFormatted(2)

What do you think? You could create behavior and that would be imho better. Let me know what you think.

I don't disagree.  I'm wondering if perhaps a parallel module would make the most sense.  Then each field could have a type (native type, what gets stored), validators (what's allowed in that field), and a displayFormat (how to show it to the user).
I was trying to save code by incorporating it in type, but you're right that it doesn't really belong there.  I'll take another cut.

Hmm maybe it's a good idea to have some kind of a Blaze helper? It's related with VIEW layer. So it could format numbers to a given precise and add some suffix. Just an idea. I think that the more atomic are astronomy modules then better. I wouldn't like to put too much features in main package. Some people complained on the autoforms package that it's too heavy. I would like people to allow choosing like 10 astronomy modules that will give then all needed features.

Agree. I've started it as a new module package. Will share soon.

Published in https://github.com/dovrosenberg/meteor-astronomy-displayFormat


fixing Trådfri dependency Cython

fixing Trådfri issue, where setup of component fails.
Cython is needed by DTLSSocket.
fixes issue #10022
If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] New dependencies have been added to the REQUIREMENTS variable ([example][ex-requir]).
[x] New dependencies are only imported inside functions that use them ([example][ex-import]).
[x] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.

If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass

I think we should do it like xml library on fritzbox and write to documenation that he should install it into env/host system.

The component used to work out for the box, if it was configured. I don't see how manual installation of dependencies is a nice user experience.

The proper way to address this issue would be to let DTLSSocket handle its requirements. Till then I agree with @flowolf that we should choose user experience over our standard way. Especially as Trådfri is a popular platform and may be used people who are not that experience with the command-line.
With https://github.com/home-assistant/home-assistant.github.io/pull/3672 it was introduced to the docs.

That is a problem of DTLSSocket and need address there.
Other module can also build itself with cython without we need pin this. In this case I disrate this PR and @flowolf should fix that on DTLSSocket repository.

I agree that this is a temporary fix. I wanted to get Trådfri working again, as it was before.
I will look to get this fixed within the DTLSSocket repo, but as this is not on github, but a closed university gitlab, getting a pull request there will take more time.

The tradfri platform has never worked without external dependencies, as it used to depend on libcoap, then depended on aiocoap and tinydtls being installed from git. The issue now is that cython isn't installed in Docker, which causes issues on component setup for docker users.
Installing cython like this isn't a solution, as all dependencies are collected together, and installed at the same time, but DTLSSocket requires that cython is installed before.
As mentioned, this needs to be fixed upstream in DTLSSocket if we want a cleaner installation method.

this is not only a Docker issue. I'm having this issue on my hassbian system as well as on my development setup.
Trådfri worked without any effort in 0.54. 0.55 started breaking it...

Hmm, did hassbian get updated to not install aiocoap/tinydtls/libcoap? It probably just needs to install cython instead. @Landrash

I'm new to hass dev but shouldn't hass run on any environment with as little effort as possible?
why are requirements specified in components when some stuff is assumed to be installed pre-hand?
configuring Docker, Hassbian, Hass.io etc. to all have the same dependencies is much more effort, than to define requirements within a component as it's partly done already.
also: what is the policy on pre-installing dependencies like Cython? should this be defined in requirements_all? on a component requirements basis or installed by hand aka by the runtime environment (hass.io, hassbian, docker)?

@flowolf absolutely! This is a bit of an unusual situation as two of our upstream dependencies for the component aren't packaged correctly/haven't released in a while.
In an ideal world aiocoap would depend on pydtls, but unfortunately it doesn't have support for Python 3 yet.
I don't think we want to put cython in requirements_all.txt, as it would need to be installed before requirements_all.txt to ensure any dependencies which don't explicitly define the dependency have it satisfied.

@lwis ok. since I just ran gen_requirements_all.py by the book, Cython is in requirements_all in this PR. Didn't realize one might need to comment that out.
I had a look at DTLSSocket. It uses Cython in the setup.py which makes handling the dependency upstream hard. Don't know of tricks to let pip install dependencies needed in setup.py.

Look to pymssql they build with cpython and can it install self if they not present on system for the build.

If Cython is required as base package after the next release it will break in Hassbian again yes.
@lwis removed the dependency on any external software was assumed because of https://github.com/home-assistant/home-assistant.github.io/pull/3558/files .
If there's still external components required for Tradfri to function correctly then that should probably  have been highlighted instead.

@Landrash since 0.56. home-assistant/home-assistant.github.io#3672 should have been merged to reflect this. Sorry for not communicating this to hassbian.

@lwis Then we should be "safe". Well have to modify our install a bit but hopefully this should be fairly painless :smile:

ok!
so I fixed DTLSSocket to install Cython before it tries to build.
fix can be found here. I've packed DTLSSocket with the tinydtls dependency into a tar.gz, that is referenced as dependency right now.
I hope @kabel42 pulls in this change. then it should be available in the DTLSSocket pip package.

@flowolf brilliant, we can't merge this pointing to your fork - so we'll need to get it merged upstream.

@lwis then let's hope @kabel42 is quick ;)

all changes to setup.py are merged.
I will push a new version to pipy later

the changes made it to upstream and the new DTLSSocket upstream version is now a requirement.
thanks @kabel42 for the quick release!

Brilliant, @pvizeli @Landrash no need to worry about the cython dependency now! 🎉
Thanks @flowolf & @kabel42 🐊


Users who are logged in with email A on sourcegraph.com and then try to log in/signup with email B via VSCode aren't able to successfully log in

If a user is logged in with X email on sourcegraph.com but tries to login with Y email via the VSCode extension, then we can:

Option 1: create a new account with Y, log the user out of X on sourcegraph.com and log the user into Y on sourcegraph.com as new user and take email Y through the new user flow
Option 2: Throw a message that says "The email you just selected doesn't match the email that's logged on in sourcegraph.com. Do you wish to associate email Y with your sourcegraph account that's currently associated with email X?"

<CTA 1 = Yes associate them>. Associates the 2 emails under 1 login and redirects the user to the new user sign in flow, so we can associate whether or not email Y is a work or personal email address.
<CTA 2= Don't associate them, Retry with another login" Takes the user back to VSCode to try another login

Option 2.5: Automatically associate the 2 emails under 1 account and log the user in, taking them through the new user sign in flow to associate whether or not email Y is a work or personal email address.
Option 3: throw an error and say "The email you just selected doesn't match the email that's logged on in sourcegraph.com. Either log out of sourcegraph.com or log into email X in VSCode"
Option 4: remove the SSO options on the signup flow and take the user to sourcegraph.com (what we're doing for JetBrains)

I think this is why JetBrains isn't running into this same bug, because the JetBrains login flow directs the user directly to sourcegraph.com, instead of taking them to an SSO provider like what we do in VSCode. so if:

the user is already logged in in Sourcegraph.com, we'll sign in with that account.
if the user is not logged in sourcegraph, then we take them to https://sourcegraph.com/sign-in

Order of my preferences:

option 1 - easiest user experience, doesn't require the user to remember what account they were signed in on on sourcegraph.com
option 4 - it introduces 1 extra step (and onto a page that needs a bit of design polish but it'll work for now)
option 2 - it gives the user an extra important step to know what's going on with their accounts, but it's an extra step
option 3 - introduces an extra step, but confusing and requires too many extra steps.
option 2.5 - smooth, but potentially too aggressive of a user experience, especially if it's a shared computer (low likelihood but associating 2 emails from 2 different people in 1 account is too confusing to risk happening a few times. the disassociation process may be easy but I haven't looked into it yet)

CC: @dominiccooney @vdavid @unknwon

More context in this Slack thread

Problem definition by @pjlast (edited for brevity):

The same-email issue we are experiencing is a side-effect of VS Code linking directly to the sign-in page for each provider instead of going through the normal Sourcegraph flow. It's going straight to the sign-in page, but you actually have a valid Sourcegraph session active. If you log out of sourcegraph.com before you click the button in VS Code, then it works fine.

(Note: the new account isn't getting associated with the old account, at least.)
@pjlast think about the solution:

I think we can maybe just not hard link like that 🥲  feels like it's an unnecessary coupling.
I also think if it recognizes the session, it will still be confusing.

So, I guess the solution would be to remove the GitHub/GitLab/Google buttons from the VS Code UI, and instead, just link directly to https://sourcegraph.com/user/settings/tokens/new/callback like we do in the JetBrains plugin here. Did I understand correctly the solution you suggested, @pjlast?

@vdavid that's correct yes, but just minor correction: The new account is being associated with the old account.
Since there's an active Sourcegraph session in the browser, the new sign-in is being associated with that active session, which is the old account. But, because we don't expect this to happen, there are now multiple Google accounts associated with that Sourcegraph account, but the new one isn't visible because only the first account is displayed in the Admin Security page

I'm not sure how possible Option 1 is, because then we have no way of distinguishing between whether a user is trying to sign in with a new account, or if they are trying to link it to their existing account (like clicking on the Connect button in the Account Security page for example)

@toolmantim came up with an elegant way of doing Option 3 that I can get behind. Adds very little friction and I think is a straightforward user experience.
Essentially it's this:

Here's the Figma to the interstitial link: https://www.figma.com/file/INGthyKM1cYki5H02JPDpW/VS-Code-Beta-2-<>-App-Onboarding?type=design&node-id=228-2365&mode=design&t=SSiAx0TJjYuBLOew-4
What do folks think on the eng side? I'm hoping this is a straightforward eng implementation since we're logging one user out and logged them in with another.

@chenkc805 I think something like this could work. I think the important bits here are:

Make it very visible as to what Sourcegraph account is active and being used
Make it easy to switch to a different account right from there

This way a user can spot if something looks off, and correct it before continuing. And the ideal case where it is a completely new user still proceeds as before.


Tutorial controller Pages and file_exists() case sensitivity

The PHP function file_exists() follows OS handling of case sensitivity. In the tutorial the view file is to be named  using uppercase first - Home.php . Then the tutorial code uses a  conditional in  Pages::view.
public function view($page = 'home')
{
	if ( ! file_exists(APPPATH.'Views/Pages/'.$page.'.php'))
	{
		// Whoops, we don't have a page for that!
		throw new \CodeIgniter\PageNotFoundException($page);
	}

When the url http://example.com//index.php/pages/view is requested, and the OS is case-sensitive, the above conditional results in the exception being thrown.  "home.php" is not a file that exists in a case-sensitve OS.
In the context of the tutorial, there are many ways to fix this issue. Any one of these will work

Change the file name to "home.php" (lower case first)
Redefine the method to public function view($page = 'Home');
Make sure $page will match the designed file name, i.e. $page = ucfirst($page);
Require that view files use the UC first naming convention, which doesn't really eliminate the need for  $page = ucfirst($page);

Seems to me this problem begs the question about a file naming convention for view files. There is nothing in the CI4 PHP Style Coding Guide regarding naming of "view" files. Should there be? Or does the framework need a helper that looks twice (UC-first and LC-first) for view file names? Or does the documentation need to point out case-sensitivity as a potential issue for developers? All of the above?
I'm happy to contribute a PR to the tutorial code and/or documentation if given some direction on what needs to be done.

Hmmm - the tutorial does ask that the user create a file application/views/pages/home.php (https://www.codeigniter.com/user_guide/tutorial/static_pages.html#adding-logic-to-the-controller). Note the case!
The tutorial has other issues, with potentially confusing method names, but I don't see the problem you suggest is there.
View filenames do not have a convention, on purpose - they can be whatever case you want, so long as you ask for them the same way. We do not want to go anywhere near trying to guess a developer's intent. UCfirst then LCfirst leads to UCsecond and LCfirstUCsecond ... and so on.
Am I missing something?

jim, you're wrong, in the CI4 userguide : https://bcit-ci.github.io/CodeIgniter4/tutorial/static_pages.html?adding-logic-to-the-controller
"In that directory, create two files named Home.php and About.php. "
So, then, the following example does not work, as he says and probably avoid confusion.
I always saw views files in lowercase (since CI2). I think that's the way to do it ... maybe the CI4 userguide should always has views filenames in lowercase.

With regard to the tutorial, I think Pages::view() would be better off without the file_exists() check. The existence of the file will eventually to be checked by View::render()  which will throw an exception if the file isn't found. Shouldn't that be enough of a heads-up during the development phase?
Barring some other fix, the documentation should probably add some admonishments regarding "precisely matching view file names in your code". As an example, the tutorial could show what happens when you don't (for those with case-sensitve systems).

I've committed a fix for the user guide. Thanks for bringing it to our attention!
As for throwing the error inside of Pages::view() - the developer should be encouraged to throw a PageNotFoundException there still. The exception thrown within the the View class is intended for the developer and doesn't work well in production. Since the Pages::view method is intended to display any page that a view exists for, it should display a 404 - Page Not Found if it can't actually be found.


Add 500 error monitoring

The tile server through a bunch of 500 errors on May 25/6 but we never received notifications for this.

Use cloudwatch dashboard, possibly set up an alert too if possible

We have set up cloudwatch dashboards and fixed the issue where rollbar errors aren't being caught by the tile server


Add default namespace endpoint

A namespace where backend is actually deployed might be useful in cluster environments. It can  be exposed as a REST endpoint

Closed by https://github.com/KaotoIO/kaoto-backend/pull/160


Manual Merge Request for Change Logo

I want to manuel merge to my PR #17067, i want to change my token image. Thanks

merged


Unable to insert a BigDecimal with high scale

Driver version or jar name
mssql-jdbc-7.0.0.jre8.jar
SQL Server version
SQL Server 2017
Client operating system
Windows 10 x64
Java/JVM version
Oracle JDK 9.0.4
Problem description
When trying to insert a BigDecimal value parsed from text like "9.99E+99" I've got an error
com.microsoft.sqlserver.jdbc.SQLServerException: Error converting data type nvarchar to decimal.

Hi @cheenamalhotra ,
thank you for your response. My column type is NUMERIC. I would expect an error like "Too high value precision" then. Message "Error converting data type nvarchar to decimal" is IMHO very misleading.

Hi @jan-krakora ,
Please test PR #796 changes for Out of Range Exception to be thrown instead.

How can I test it? Is there a way to get a PR as a branch and build the jdbc driver? Looking at your commit it  seems fine to me.

Hi @jan-krakora
Please find the Jars for testing: mssql-jdbc-PR796.zip

Hi @cheenamalhotra,
I can confirm the exception with 'out of range' message is thrown. Thank you.

Hi @jan-krakora
PR #796 has been merged and changes will be available since v7.1.1 release. Closing issue.


Remove reference to Cloud debugger API in bidding_auction_services_gcp_guide.md

Cloud Debugger was deprecated in May 2023, but the bidding_auction_services_gcp_guide.md document still references it in the API list despite it no longer being available.
$ gcloud services list --project ps-dev-pa-baservers-978b | grep de
confidentialcomputing.googleapis.com  Confidential Computing API

Hi @dankocoj-google, would you be able to help update the B&A GCP explainer and also address this issue? Thanks.

Thanks for reporting this Roscoe.
https://github.com/privacysandbox/protected-auction-services-docs/pull/123