TY Page UI extension component isn't rendered after a Post Purchase step

Please list the package(s) involved in the issue, and include the version you are using
"@shopify/checkout-ui-extensions-react": "0.27.3",
"@shopify/post-purchase-ui-extensions-react": "0.13.4",

Describe the bug
If both Post-purchase and Thank you page extensions are enabled for a single checkout process, the Thank you page extension callback isn't triggered.
When a customer goes through the Post-purchase step and accepts or declines the extension's offer, the customer is landed on the Thank you page, where the extensions are not available at all.
If I make the Post Purchase step skipped, the Thank you page extension works properly.
Steps to reproduce the behavior:

Create Post-purchase and Thank you page extensions using the same app
Make sure a Post-purchase extension is enabled
Make sure a Thank you page extension is enabled
Create an order as a customer and navigate to the post-purchase step
Accept or decline the post-purchase extension's offer
Land on the Thank you page
Checkout::ThankYou::Dynamic::Render callback is NOT executed. The behavior is the same as if the checkout extension would be disabled in the Shopify Theme customizer.

Expected behavior
1-6 steps
7. The Thank you page extension Checkout::ThankYou::Dynamic::Render callback is triggered
Additional context
If I repeat the same steps but make the Post-purchase step skipped (not being shown to a customer), the Thank you page extension works fine.

hi there! This issue should be resolved now


Theme switching: Add TypeScript types

@grgia
Details

Adds TS types for the theme and colors and adapts files to the new types.
The PR is based on this PR by @grgia, which introduces the light theme.
Fixed Issues

$ https://github.com/Expensify/App/issues/24118
PROPOSAL:
Tests

[ ] Verify that no errors appear in the JS console

Offline tests

QA Steps

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

@aimane-chnaif  @chrispader
Please don't merge this PR until the TS migration team also reviews this PR 🙇
cc: @fabioh8010 @blazejkustra

@chrispader @aimane-chnaif Let's hold this PR on https://github.com/Expensify/App/pull/22986

Still on HOLD for https://github.com/Expensify/App/pull/22986

Not on HOLD anymore. 👍

@grgia i feel like the light/dark theme's don't match in keys. We have some colors from light that are not in dark and vice versa...
Should we change this?
E.g. receiptDropUIBG is only in dark/default, and dropTransparentOverlay is only in light theme

@grgia i feel like the light/dark theme's don't match in keys. We have some colors from light that are not in dark and vice versa...
Should we change this?
E.g. receiptDropUIBG is only in dark/default, and dropTransparentOverlay is only in light theme

@chrispader yes, anything only in light theme, let's delete. Anything in dark theme thats not in light theme, copy into light theme. I can help with color keys if it's not 1:1 (i.e darkAppBG -> lightAppBG)

I can help with color keys if it's not 1:1 (i.e darkAppBG -> lightAppBG)

We've got rgba(3, 212, 124, 0.84) for receiptDropUIBG and need it for light theme. What should it be? cc @grgia

@chrispader we can use the same color in this case

So i think currently we're holding on #27660

@chrispader I opened https://github.com/Expensify/App/pull/27660 to review, could you please take a look? Thanks!

@chrispader cc @fabioh8010 where are we at with the theme/style related TS?
If you have any outstanding questions let me know!

@chrispader cc @fabioh8010 where are we at with the theme/style related TS?
If you have any outstanding questions let me know!

Gonna take a look at @fabioh8010 's PR now

please bump me when hold is removed!

#27660 has been merged a few days ago, so i just updated this PR 👍  This is ready :)
cc @grgia

@aimane-chnaif no C+ review, I'll handle the review checklist.

Reviewer Checklist

[X] I have verified the author checklist is complete (all boxes are checked off).
[X] I verified the correct issue is linked in the ### Fixed Issues section above
[X] I verified testing steps are clear and they cover the changes made in this PR

[X] I verified the steps for local testing are in the Tests section
[X] I verified the steps for Staging and/or Production testing are in the QA steps section
[X] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[X] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[X] I checked that screenshots or videos are included for tests on all platforms
[X] I included screenshots or videos for tests on all platforms
[X] I verified tests pass on all platforms & I tested again on:

[X] Android: Native
[X] Android: mWeb Chrome
[X] iOS: Native
[X] iOS: mWeb Safari
[X] MacOS: Chrome / Safari
[X] MacOS: Desktop

[X] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[X] I verified proper code patterns were followed (see Reviewing the code)

[X] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[X] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[X] I verified that comments were added to code that is not self explanatory
[X] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[X] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[X] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[X] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[X] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[X] I verified the JSDocs style guidelines (in STYLE.md) were followed

[X] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[X] I verified that this PR follows the guidelines as stated in the Review Guidelines
[X] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[X] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[X] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[X] If a new component is created I verified that:

[X] A similar component doesn't exist in the codebase
[X] All props are defined accurately and each prop has a /** comment above it */
[X] The file is named correctly
[X] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[X] The only data being stored in the state is data necessary for rendering and nothing else
[X] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[X] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[X] All JSX used for rendering exists in the render method
[X] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[X] If any new file was added I verified that:

[X] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[X] If a new CSS style is added I verified that:

[X] A similar style doesn't already exist
[X] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[X] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[X] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[X] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[X] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[X] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[X] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

@fabioh8010 @blazejkustra mind doing a final review of this one?

@chrispader can we verify no build/console errors on each platform?

Couldn't find any build/console errors on any platform 👍 cc @grgia

friendly bump @grgia @fabioh8010 @blazejkustra :)

@chrispader sorry for the delay I was OOO last week, mind merging main?

@chrispader sorry for the delay I was OOO last week, mind merging main?

done ✅

@grgia can we merge this? :)

^ merged before letting the PR review checklist test re-run

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/grgia in version: 1.3.96-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.3.96-15 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.3.97-7 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


CUDA Client

Adding a client wich is capable of cuda processing

Due to the calculation time of a cuple of minutes, a CUDA client is not really nessesary


Rename texture_offset and unclamp it

In TileData, this PR renames texture_offset to texture_origin as it is a bit better name and avoids confusion.
Also, it unclamps it. It was previously forbidding values that would put the base tile (like, the tile on the grid) outside of the drawn region. It is now possible to use any kind of value, but that meant I had to modify the tile atlas view to avoid a mess.
Now, positions in the tile atlas editor get displayed only if they fit the texture region. Otherwise, the value is displayed as text:
https://user-images.githubusercontent.com/6093119/214912027-dcf4ddc3-5964-4160-a41c-654e58f1d344.mp4
Closes https://github.com/godotengine/godot/issues/68277.
It's not super urgent for 4.0, but since it renames something, and cleans up things a bit, I think it might be worth merging.

The classref needs to be synced too.

I think it's worth breaking compat now to clarify, but for the sake of existing users, you should likely add some compatibility code in TileSet by overriding _set and _get to handle existing serialized values for texture_offset.

Thanks!


Feat: Avatar component and responsive layout

Description:

Completed Avatar component
Made website responsive.

APP link: https://gear-ui-avatar.netlify.app/components/avatar/


sh switches command's stderr into fullstop's stdout

Is there a way to tell sh not to output the stderr of it's given command?
git clone is sending it's output to stderr; however, once sh gets ahold of it fullstop sends it to stdout.
The fix for me is to send the stderr of git clone to /dev/null but I'm not sure if this is ideal since I don't think it can be logged anymore once I do that, shown below:
         warn "deleting #{repo_dir} before cloning"
         FileUtils.rm_rf repo_dir
       end
-      unless sh("git clone #{repo_url}") == 0
+      unless sh("git clone #{repo_url} 2> /dev/null") == 0
         exit_now!("checkout dir already exists, use --force to overwrite")
       end
       Repo.new(repo_dir)

before sending git clone to /dev/null:
➜  fullstop master ✓ HOME=/tmp/fakehome bundle exec bin/fullstop --force /tmp/dotfiles.git 2> /dev/null
deleting dotfiles before cloning
stderr output of 'git clone /tmp/dotfiles.git': Cloning into 'dotfiles'...
done.

after sending git clone to dev/null:
➜  fullstop master ✓     HOME=/tmp/fakehome bundle exec bin/fullstop --force /tmp/dotfiles.git
deleting dotfiles before cloning

Is there a better way to go about grabbing a command's stderr with sh?
Edit:
Taking a look at Methadone::SH it looks like sh is logging the stderr output of git log here:
sh_logger.warn("stderr output of '#{command}': #{stderr}") unless stderr.strip.length == 0

And it also seems like warn outputs to stdout.
In the case of full stop wouldn't we not want this output:
    stderr output of 'git clone /tmp/dotfiles.git': Cloning into 'dotfiles'...
    done.

by going to stdout by default?

If you want to prevent stdout and stderr logging ,you can set the sh logger.  You can also access that logger and set its level higher (though note by default that logger is the app-wide logger).
You can then access the stderr using the block form:
sh "git clone" do |stdout,stderr|
  # ...
end

The thinking behind the default behavior is that when you use sh you generally aren't expecting stderr, so if you get some, it gets output to the log.  If git is producing non-error messages to stderr, that is git deviating from UNIX standard and methadone can't possibly know about that to squelch the error output (you'd have the same issue using bash).

git has a --quiet switch that will prevent it from sending logging info to stderr see the docs for more info and this pr for an example 😄


KAFKA-16863 : Deprecate default exception handlers

Resolves : https://issues.apache.org/jira/browse/KAFKA-16863
Related kip : https://cwiki.apache.org/confluence/display/KAFKA/KIP-1056%3A+Remove+`default.`+prefix+for+exception+handler+StreamsConfig

Removing default. prefix for exception handler config
Related kip removing default. prefix for exception handler config

More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

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

@mjsax pls take a look

Committed the fix.
LGTM now, assuming build passes...

Great, thanks.

Yeah. Looks related. Can you take a look and push a fix?

Pushed a fix, also updated config-streams.html. ptal. thanks.

I have updated the upgrade section.

Pushed that change. Will get site-docs running locally from next time. Thought this would be a smaller one.

Actually got the site-docs running locally now. Should have done this before. Nice, thanks. Learning a lot in this pr.

Merged to trunk. Congrats!
Thanks for the KIP and PR!

@mjsax Thank you for the great review and support.


npm start tmp/lib/server

npm start fails with following error:
> cross-env NODE_ENV=production node tmp/lib/server

module.js:544
    throw err;
    ^

Cannot find module 'users/n/react-universal-starter/tmp/lib/server'

Is this some missing code?

Hey, thanks for pointing this out. Can you send a PR with the fix in the readme ? I will be happy to add you as a contributor.

#46


Fix 'tcp+tls' protocol not being accepted

Fixes #20042

/cc @calavera

Job: Docker-PRs-WoW-TP4 FAILED:

---
9caaf59.
+ ec=125
+ set +x

----------------------------------
ERROR: Failed to build test binary
----------------------------------

-----------------------------------------------
ERROR: Failed with exitcode 125 at Mon Feb  8 17:32:34 CUT 2016.
-----------------------------------------------

INFO: Tidying up at end of run
INFO: Nuking /d/CI
INFO: Zapped successfully
INFO: End of cleanup
INFO: Ended at Mon Feb  8 17:32:35 CUT 2016 (1m 5s)
Build step 'Execute shell' marked build as failure
[PostBuildScript] - Execution post build scripts.
[docker] $ sh -xe D:\temp\hudson536471586602731619.sh
+ set +e
+ set +x
INFO: End of cleanup
Notifying endpoint 'HTTP:https://leeroy.dockerproject.org/notification/jenkins'
---

Job: Docker-PRs-WoW-TP4 FAILED:

---
0892c3c.
+ ec=125
+ set +x

----------------------------------
ERROR: Failed to build test binary
----------------------------------

-----------------------------------------------
ERROR: Failed with exitcode 125 at Mon Feb  8 17:36:40 CUT 2016.
-----------------------------------------------

INFO: Tidying up at end of run
INFO: Nuking /d/CI
INFO: Zapped successfully
INFO: End of cleanup
INFO: Ended at Mon Feb  8 17:36:41 CUT 2016 (1m 2s)
Build step 'Execute shell' marked build as failure
[PostBuildScript] - Execution post build scripts.
[docker] $ sh -xe D:\temp\hudson6394010700858978679.sh
+ set +e
+ set +x
INFO: End of cleanup
Notifying endpoint 'HTTP:https://leeroy.dockerproject.org/notification/jenkins'
---

LGTM

LGTM

Job: Docker-PRs-WoW-TP4 FAILED:

---
18d51a.
+ ec=125
+ set +x

----------------------------------
ERROR: Failed to build test binary
----------------------------------

-----------------------------------------------
ERROR: Failed with exitcode 125 at Mon Feb  8 17:49:35 CUT 2016.
-----------------------------------------------

INFO: Tidying up at end of run
INFO: Nuking /d/CI
INFO: Zapped successfully
INFO: End of cleanup
INFO: Ended at Mon Feb  8 17:49:36 CUT 2016 (0m 47s)
Build step 'Execute shell' marked build as failure
[PostBuildScript] - Execution post build scripts.
[docker] $ sh -xe D:\temp\hudson3027972994516708106.sh
+ set +e
+ set +x
INFO: End of cleanup
Notifying endpoint 'HTTP:https://leeroy.dockerproject.org/notification/jenkins'
---


🪐 Update cosmos-sdk to 0.47

This PR is intended to update the new cosmos-sdk version from 0.46.6 to 0.47.1.
That implies also to migrate from tendermint to cometbft.
📋 Todo

[x] Apply changes on app.go
[x] Update to cosmwasm 1.2.1
[x] Update Dockerfile
[x] Migrate x/mint module
[x] Migrate x/logic module
[x] Migrate x/vesting module

🧪 Tests

[x] Chain
[x] Vesting module
[x] Mint module
[x] Logic module
[x] contracts storage and communication between us and logic module

🔗 Dependencies

[x] Needs https://github.com/okp4/docker-images/pull/154 to build new proto and proto documentation
[ ] Use a no released version of ignite-cli : https://github.com/ignite/cli/pull/3455

🦅 Migrations
Migrations will be the subject of another PR since this PR will be difficult to read, and to make the migrations script more easier to read and check if all is good ;)
See #334

@amimart @ccamel Thanks, Yes I know, difficult to check if all is good, I propose to merge it, then we can make as much test as possible and also not forget to update ignite-cli dependency when version with 0.47 will be released.
We can now switch to the PR that will handle upgrade from 0.46 #334 ;).

:tada: This PR is included in version 5.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Won't run

java -jar CscKeystringDecrypt.jar PLS_keystrings.dat
Exception in thread "main" java.lang.NoClassDefFoundError: Encrypt64
at Main.main(Main.java:15)
Caused by: java.lang.ClassNotFoundException: Encrypt64
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 1 more

You need to include Encrypt64.java and SemLog.java when building the JAR as well.
Here's a precompiled JAR:
CscKeystringDecrypt-1.0-SNAPSHOT-Java11.zip
Btw, this repo is probably outdated. I have hard-coded the private key I extracted from my S20+. I may not work with newer models if they use a different key.


card count in right upper corner

Move card count into right upper corner, without adding extra line, as currently page blinks and shift done as the plugin updates page
Actually it was so before

but now

Will look into this

I found a solution by installing "CardCounter for Trello" https://chrome.google.com/webstore/detail/cardcounter-for-trello/miejdnaildjcmahbhmfngfdoficmkdhi
I works well, but with the plugin installed, now I'd like to hide/remove card count done by this plugin

I am going to close this issue. If you want to add a PR for removing card count as an option I'd happily consider it.


[Bug] Compilation of TinyLlama in Android not working

🐛 Bug
I was able to compile the TinyLlama to Android using MLC-LLM. While running the prepare_libs.sh file, I'm getting some errors.
I saw a similar error over here, but that solution didn't work.
[100%] Built target mlc_llm_static
[100%] Building CXX object CMakeFiles/tvm4j_runtime_packed.dir/mnt/c/Users/aadar/Documents/mlc-llm/3rdparty/tvm/jvm/native/src/main/native/org_apache_tvm_native_c_api.cc.o
/mnt/c/Users/aadar/Documents/mlc-llm/3rdparty/tvm/jvm/native/src/main/native/org_apache_tvm_native_c_api.cc:232:31: error: cannot initialize a parameter of type 'void **' with an rvalue of type 'JNIEnv **' (aka 'JNIEnv_ **')
    _jvm->AttachCurrentThread(&env, nullptr);
                              ^~~~
/usr/lib/jvm/java-11-openjdk-amd64/include/jni.h:1924:37: note: passing argument to parameter 'penv' here
    jint AttachCurrentThread(void **penv, void *args) {
                                    ^
/mnt/c/Users/aadar/Documents/mlc-llm/3rdparty/tvm/jvm/native/src/main/native/org_apache_tvm_native_c_api.cc:309:31: error: cannot initialize a parameter of type 'void **' with an rvalue of type 'JNIEnv **' (aka 'JNIEnv_ **')
    _jvm->AttachCurrentThread(&env, nullptr);
                              ^~~~
/usr/lib/jvm/java-11-openjdk-amd64/include/jni.h:1924:37: note: passing argument to parameter 'penv' here
    jint AttachCurrentThread(void **penv, void *args) {
                                    ^
2 errors generated.
make[3]: *** [CMakeFiles/tvm4j_runtime_packed.dir/build.make:76: CMakeFiles/tvm4j_runtime_packed.dir/mnt/c/Users/aadar/Documents/mlc-llm/3rdparty/tvm/jvm/native/src/main/native/org_apache_tvm_native_c_api.cc.o] Error 1
make[2]: *** [CMakeFiles/Makefile2:268: CMakeFiles/tvm4j_runtime_packed.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:275: CMakeFiles/tvm4j_runtime_packed.dir/rule] Error 2
make: *** [Makefile:203: tvm4j_runtime_packed] Error 2

Expected behavior
The model should be built and /build/output folder needs to be populated.
Environment

Operating system (e.g. Ubuntu/Windows/MacOS/...): WSL2
How you installed MLC-LLM (conda, source): conda
How you installed TVM-Unity (pip, source): source
Python version (e.g. 3.10): 3.8

https://github.com/mlc-ai/mlc-llm/issues/691
The solution mentioned here, seems to work :)


Dev

Ⅰ. Describe what this PR did
为ParsePortBinding, ValidatePortBinding增加单元测试案例
Ⅱ. Does this pull request fix one issue?

fixes #1905
Ⅲ. Describe how you did it
分别对 ip, hostPort, constainerPort 增加测试案例
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


New package: MyExample v0.1.0

Registering package: MyExample
Repository: https://github.com/grahamhindle/MyExample.jl
Created by: @grahamhindle
Version: v0.1.0
Commit:<PHONE_NUMBER>7e0f65ff62e50269dfe2a8c4cf4b29
Reviewed by: @grahamhindle
Reference: https://github.com/grahamhindle/MyExample.jl/issues/3

It looks like this is an example package for testing out a workflow. Does it need to be registered in the General registry?

No - sorry about not informing you, soon i will have something real
Sent from my iPhone

On 14 Jun 2020, at 19:20, Dilum Aluthge<EMAIL_ADDRESS>wrote:

It looks like this is an example package for testing out a workflow. Does it need to be registered in the General registry?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


How can  find mFuncName:fuseAttention function

The attention functiuon use the cudalunch call, how can  find mFuncName:fuseAttention function

Sorry, I don't understand your question.
Can you point out where do you concert?

For example, in fastertransformer/trt_fused_multihead_attention/fused_multihead_attention_v2.h ,the line is 190 ,"fused_multihead_attention_v2_int8_128_64_kernel_sm72_interleaved" this is the function name  well give the line 184 struct FusedMultiHeadAttentionKernelMetaInfoV2:mFuncName and last  it well call mDriver.cuLaunchKernel to use.  so where the fused_multihead_attention_v2_int8_128_64_kernel_sm72_interleaved implement

The function name is fused_multihead_attention_v2_int8_128_64_kernel_cubin, and in fastertransformer/trt_fused_multihead_attention/fused_multihead_attention_v2_int8_128_64_kernel.sm72.cpp

Thanks your review in time, I got it, so it is machine code, can not read and modify.


Allow tags to be used as dep references

Closes #97
Test with:
dependency_table("x/y", "repo@host", ref = "my_tag")

for appropriate x/y and my_tag
End to end tests will be added here once I can tag the staged.deps example repos.
Note after testing this functionality and checking out main, you will need to clear the staged deps cache (once this is merged in then clearing cache will not be required)

start debug:
remotes::install_github("openpharma/staged.dependencies", ref = "97tags@main")
x <- dependency_table("insightsengineering/tern", "repo@host", ref = "2021_07_07")


🐛 @backstage/plugin-azure-devops: fron-end request not sending component name

Plugin Name
@backstage-community/plugin-azure-devops
📜 Description
the following cards:
EntityAzureGitTagsContent
EntityAzureReadmeCard
EntityAzurePullRequestsContent
i have try the versions 0.4.4 to 0.4.7 same behavior

Are not sending the component name on the request to the backend.
http://localhost:3000/api/azure-devops/pull-requests/TEAMPROJECT/undefined?top=25&status=1&entityRef=component%3Adefault%2Ftest.backstageio.service
for some reason we get a undefined on the request.
👍 Expected behavior
the strange part is EntityAzurePipelinesContent is workin normally.
example of the REQUEST:
http://localhost:3000/api/azure-devops/builds/TEAMPROJECT?entityRef=component%3Adefault%2Fhiae.core.backstageio.service&definitionName=test.BackstageIO.service&top=26
👎 Actual Behavior with Screenshots

👟 Reproduction steps
install the plugin on backend and frontend
go to a component entity.
click on the README
OR
install the plugin on backend and frontend
go to a component entity.
click on the GitTags
OR
install the plugin on backend and frontend
go to a component entity.
click on the Pull Request
📃 Provide the context for the Bug.
On backstage 1.20.3 i didn't have this issue..
I'm current work-in on a version bump to 1.29.3, i encouter this bug on a brand new backstage implementation.
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, but I'm happy to collaborate on a PR with someone else

Hi @enryson, can you share a few more details: it would be great to get the actual error message, any errors in the backend logs, as well as the results from yarn backstage-cli info, please?

no problem..
the only thing that i changed is the domain and team project for obvious reasons
On the README card:
No error message on the backend, the API returns a 404 (probably because the frontend component send the wrong payload)
{   "error": {     "name": "NotFoundError",     "message": "https://dev.azure.com/COMPANY_NAME/PROJECT/_git/undefined?path=README.md could not be read as https://dev.azure.com/COMPANY_NAME/PROJECT/_apis/git/repositories/undefined/items?api-version=6.0&path=README.md, 404 Not Found",     "stack": "NotFoundError: https://dev.azure.com/COMPANY_NAME/PROJECT/_git/undefined?path=README.md could not be read as https://dev.azure.com/COMPANY_NAME/PROJECT/_apis/git/repositories/undefined/items?api-version=6.0&path=README.md, 404 Not Found\n    at AzureUrlReader.readUrl (/Users/enryson/Documents/GitHub/newBackstage/backstage/node_modules/@backstage/backend-defaults/src/entrypoints/urlReader/lib/AzureUrlReader.ts:109:13)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at AzureDevOpsApi.getReadme (/Users/enryson/Documents/GitHub/newBackstage/backstage/node_modules/@backstage-community/plugin-azure-devops-backend/src/api/AzureDevOpsApi.ts:577:22)\n    at <anonymous> (/Users/enryson/Documents/GitHub/newBackstage/backstage/node_modules/@backstage-community/plugin-azure-devops-backend/src/service/router.ts:383:20)"   },   "request": {     "method": "GET",     "url": "/readme/PROJECT/undefined?entityRef=component%3Adefault%2Ftest.backstageio.service"   },   "response": {     "statusCode": 404   } }
on the git tags and Pull Requests is KINDA the same.. but i got a 500 error
on this case i got a 500 and a backend error

Error log on the backend
[1] 2024-07-26T00:37:59.152Z backstage error Request failed with status 500 No repository found for Project "NOT_GONA_SHARE" with Repository "undefined" on host "undefined" under organization "undefined". type=errorHandler stack=Error: No repository found for Project "NOT_GONA_SHARE" with Repository "undefined" on host "undefined" under organization "undefined". [1]     at AzureDevOpsApi.getGitTags (/Users/enryson/Documents/GitHub/newBackstage/backstage/node_modules/@backstage-community/plugin-azure-devops-backend/src/api/AzureDevOpsApi.ts:271:13) [1]     at process.processTicksAndRejections (node:internal/process/task_queues:95:5) [1]     at <anonymous> (/Users/enryson/Documents/GitHub/newBackstage/backstage/node_modules/@backstage-community/plugin-azure-devops-backend/src/service/router.ts:170:21)
Same on the tags 500 on the backend..
For shure this is looking a front end component problem because the weird payload..
is missing the component name (AKA entity name) on the request..
To confirm this i replicate the request but fixing the missing argument on the request.
i done this on Insomnia

Samething on the tags

to me this confirm as a 100% problem on the front-end plugin..
this 3 requests are missing the "entity name"on the request.
/api/azure-devops/readme/TEAMPROJECT/undefined
/api/azure-devops/git-tags/TEAMPROJECT/undefined
/api/azure-devops/pull-requests/TEAMPROJECT/undefined
The correct way is like this
/api/azure-devops/readme/TEAMPROJECT/test.BackstageIO.service
/api/azure-devops/git-tags/TEAMPROJECT/test.BackstageIO.service
/api/azure-devops/pull-requests/TEAMPROJECT/test.BackstageIO.service
So far the only front-end component workin fine is the azure CI-CD
yarn backstage-cli info
`yarn run v1.22.22
$ /Users/enryson/Documents/GitHub/newBackstage/backstage/node_modules/.bin/backstage-cli info
OS:   Darwin 23.5.0 - darwin/arm64
node: v18.16.1
yarn: 1.22.22
cli:  0.26.11 (installed)
backstage:  1.29.2
Dependencies:
@backstage/app-defaults                                          1.5.9
@backstage/backend-app-api                                       0.8.0
@backstage/backend-common                                        0.23.3
@backstage/backend-defaults                                      0.4.1
@backstage/backend-dev-utils                                     0.1.4
@backstage/backend-openapi-utils                                 0.1.15
@backstage/backend-plugin-api                                    0.6.21, 0.7.0
@backstage/backend-tasks                                         0.5.27
@backstage/backend-test-utils                                    0.4.4
@backstage/catalog-client                                        1.6.5
@backstage/catalog-model                                         1.5.0
@backstage/cli-common                                            0.1.14
@backstage/cli-node                                              0.2.7
@backstage/cli                                                   0.26.11
@backstage/config-loader                                         1.8.1
@backstage/config                                                1.2.0
@backstage/core-app-api                                          1.14.1
@backstage/core-compat-api                                       0.2.7
@backstage/core-components                                       0.14.9
@backstage/core-plugin-api                                       1.9.3
@backstage/e2e-test-utils                                        0.1.1
@backstage/errors                                                1.2.4
@backstage/eslint-plugin                                         0.1.8
@backstage/frontend-plugin-api                                   0.6.7
@backstage/integration-aws-node                                  0.1.12
@backstage/integration-react                                     1.1.29
@backstage/integration                                           1.13.0
@backstage/plugin-api-docs                                       0.11.7
@backstage/plugin-app-backend                                    0.3.71
@backstage/plugin-app-node                                       0.1.22
@backstage/plugin-auth-backend-module-atlassian-provider         0.2.3
@backstage/plugin-auth-backend-module-aws-alb-provider           0.1.14
@backstage/plugin-auth-backend-module-azure-easyauth-provider    0.1.5
@backstage/plugin-auth-backend-module-bitbucket-provider         0.1.5
@backstage/plugin-auth-backend-module-cloudflare-access-provider 0.1.5
@backstage/plugin-auth-backend-module-gcp-iap-provider           0.2.17
@backstage/plugin-auth-backend-module-github-provider            0.1.19
@backstage/plugin-auth-backend-module-gitlab-provider            0.1.19
@backstage/plugin-auth-backend-module-google-provider            0.1.19
@backstage/plugin-auth-backend-module-guest-provider             0.1.8
@backstage/plugin-auth-backend-module-microsoft-provider         0.1.17
@backstage/plugin-auth-backend-module-oauth2-provider            0.2.3
@backstage/plugin-auth-backend-module-oauth2-proxy-provider      0.1.15
@backstage/plugin-auth-backend-module-oidc-provider              0.2.3
@backstage/plugin-auth-backend-module-okta-provider              0.0.15
@backstage/plugin-auth-backend-module-onelogin-provider          0.1.3
@backstage/plugin-auth-backend                                   0.22.9
@backstage/plugin-auth-node                                      0.4.17
@backstage/plugin-auth-react                                     0.1.4
@backstage/plugin-bitbucket-cloud-common                         0.2.21
@backstage/plugin-catalog-backend-module-logs                    0.0.1
@backstage/plugin-catalog-backend-module-scaffolder-entity-model 0.1.20
@backstage/plugin-catalog-backend                                1.24.0
@backstage/plugin-catalog-common                                 1.0.25
@backstage/plugin-catalog-graph                                  0.4.7
@backstage/plugin-catalog-import                                 0.12.1
@backstage/plugin-catalog-node                                   1.12.4
@backstage/plugin-catalog-react                                  1.12.2
@backstage/plugin-catalog                                        1.21.1
@backstage/plugin-events-node                                    0.3.8
@backstage/plugin-org                                            0.6.27
@backstage/plugin-permission-backend-module-allow-all-policy     0.1.19
@backstage/plugin-permission-backend                             0.5.46
@backstage/plugin-permission-common                              0.7.14, 0.8.0
@backstage/plugin-permission-node                                0.7.32, 0.8.0
@backstage/plugin-permission-react                               0.4.24
@backstage/plugin-proxy-backend                                  0.5.3
@backstage/plugin-scaffolder-backend-module-azure                0.1.14
@backstage/plugin-scaffolder-backend-module-bitbucket-cloud      0.1.12
@backstage/plugin-scaffolder-backend-module-bitbucket-server     0.1.12
@backstage/plugin-scaffolder-backend-module-bitbucket            0.2.12
@backstage/plugin-scaffolder-backend-module-gerrit               0.1.14
@backstage/plugin-scaffolder-backend-module-gitea                0.1.12
@backstage/plugin-scaffolder-backend-module-github               0.4.0
@backstage/plugin-scaffolder-backend-module-gitlab               0.4.4
@backstage/plugin-scaffolder-backend                             1.23.0
@backstage/plugin-scaffolder-common                              1.5.4
@backstage/plugin-scaffolder-node                                0.4.8
@backstage/plugin-scaffolder-react                               1.10.0
@backstage/plugin-scaffolder                                     1.23.0
@backstage/plugin-search-backend-module-catalog                  0.1.28
@backstage/plugin-search-backend-module-pg                       0.5.32
@backstage/plugin-search-backend-module-techdocs                 0.1.27
@backstage/plugin-search-backend-node                            1.2.27
@backstage/plugin-search-backend                                 1.5.14
@backstage/plugin-search-common                                  1.2.13
@backstage/plugin-search-react                                   1.7.13
@backstage/plugin-search                                         1.4.14
@backstage/plugin-signals-react                                  0.0.4
@backstage/plugin-techdocs-backend                               1.10.9
@backstage/plugin-techdocs-module-addons-contrib                 1.1.12
@backstage/plugin-techdocs-node                                  1.12.8
@backstage/plugin-techdocs-react                                 1.2.6
@backstage/plugin-techdocs                                       1.10.7
@backstage/plugin-user-settings-common                           0.0.1
@backstage/plugin-user-settings                                  0.8.10
@backstage/release-manifests                                     0.0.11
@backstage/test-utils                                            1.5.9
@backstage/theme                                                 0.5.6
@backstage/types                                                 1.1.1
@backstage/version-bridge                                        1.0.8`

Thanks @enryson, one last thing, I forgot it's not included in the info results any more, can you share the versions of the Azure DevOps plugin packages you are using? Also, what is you azureDevOps config look like in your app-config and what annotations are on the entity.
More generally, the Azure DevOps plugin has seen several changes since December 2023 (that's when the 1.20.x release of Backstage came out) and I might suggest doing a full reinstall of the plugin following the current docs. There might be a change there that you haven't made.
I'm going to dig into this on my end but there hasn't been many recent changes that would account for this 🤔

I have try the 0.4.4, 0.4.5 and 0.4.7 versions.. same behaviour.
my integrations is ok on the app-config
integrations:
  azure:
    - host: dev.azure.com
      credentials:
        - personalAccessToken: ${PERSONAL_ACCESS_TOKEN}

I do no think this is the problem, because on the backend side of this plugin, things are fine..
So far this is looking to be a fron-end bug..
Even because the CI-CD is working fine...
i will try some diferent things, and post the results.

That's fair, I don't disagree with you assessment but I want all the details to reproduce as I don't have this issue if I run this in the repo right now and I don't suspect I will have issues with doing this net new.
Can you share the annotations you are using? That will help me as well.

Oww boy...
i manage to debug this more.. and found the issue.
the problem lies on ..
my entity code
    backstage.io/techdocs-ref: url:https://dev.azure.com/........../........../_git/TEST.BackstageIO.service
    dev.azure.com/project-repo: TEST/TEST.BackstageIO.service
    dev.azure.com/project: TEST
    dev.azure.com/build-definition: TEST.BackstageIO.service

because the dev.azure.com/project annotation, the method getAnnotationValuesFromEntity did not return the important stuff.
this method return almost all parameters undefined
definition: "TEST.BackstageIO.service"
host: undefined
org: undefined
project: "TEST"
readmePath : undefined

getAnnotationValuesFromEntity.ts
const project =
    entity.metadata.annotations?.[AZURE_DEVOPS_PROJECT_ANNOTATION]; //if he found this

if (definition) {
    console.log('definition:', definition); // he steps into here.. causing missing parameters..
    if (project) {
      console.log('project:', project);
      return {
        project,
        definition,
        readmePath: readmePath,
        ...hostOrg,
      };
    }
    if (projectRepo.project) {
      return {
        project: projectRepo.project,
        repo: projectRepo.repo,
        definition,
        readmePath: readmePath,
        ...hostOrg,
      };
    }
    throw new Error(
      `Value for annotation "${AZURE_DEVOPS_PROJECT_ANNOTATION}" was not found`,
    );
  }

This causes the behavior that i describe..
After i removed the "dev.azure.com/project: " from the entity yaml this fixes the problem..
The reason to the CI-CD worked is because the request is little diferent..
so far on my side i will remove this "dev.azure.com/project: " parameters from the entities.
i do not know this code, but is normal to return only this when the project tag is defined?
return {
       project,
       definition,
       readmePath: readmePath,
       ...hostOrg,
     };

Thanks again for digging into this. That makes more sense to me as to why this would fail. There's a lot of tests for this function but we must have missed this when expand this feature to support other cases. There is a test for those three annotations:
https://github.com/backstage/community-plugins/blob/70079c5191b1a42c89b48bb854efcd708761dde8/workspaces/azure-devops/plugins/azure-devops/src/utils/getAnnotationValuesFromEntity.test.ts#L432-L457
Not sure what we missed but glad we have this narrowed down.

This is the issue related to this feature: https://github.com/backstage/backstage/issues/22082 and this is the PR: https://github.com/backstage/backstage/pull/22153
@R-Beck-2020 @afscrome - do you have any feedback on this? Are you using the annotations in the same way? Is it working for you?

If your pipelines aren't in a separate project to your build definition, then I strongly recommend you don't set the project attribute at all.  Even if things "should" work, it adds a whole bunch of ambiguity and potential for things to go wrong.  At my company I don't think any of our apps use this annotation since we don't have any pipelines in seperate projects to the code repo.
Similarly, I'd advise against setting build-definition if the auto detection logic for pipelines doesn't work.  (Either because you have more than one application in the same repo, or your pipelines are in a different project).
How to calculate the project when both project and project-repo annotations are set is a bit ambiguous - should the project from the project-repo annotation be used, or should the project from project be used.  It sort of depends on the context, but since getAnnotationValuesFromEntity is shared by all contexts, it's hard to differentiate.  I forget exactly why we chose that test case in the end - looking at it fresh now, I'd expect project-repo to trump project + definition.  IF I had to guess, I'd say we were trying to maintain the behavior prior to our Pr, but from quickly scanning the Pr it looks like project-repo would have won prior to our PR.
Personally, I'd like to see the project annotation retired due to the ambiguity it brings. I'd rather see it renamed to definition-repo to make it clear it only applies to pipelines, or allow build-definition to be prefixed by a project (e.g. my-definition or PROJECT\my-definition).  That in turn has some more knock on effects as now getAnnotaitonValuesFromEntity can no longer return a single project as it doesn't know whether it being called to get repo data (in which case repo-project should win) or for pipeline data (in which case the pipeline project should win).
Alternatively, this problem only occurs if you have your pipeline in a separate project to your repos, whilst this can theoretically be done, I've never seen it in the wild.  Given this is the first problem been reported in 6 months, you could say the problem is worth solving.  (Especially as based on the sample data provided, both project-repo and project use the same project, so the problem could be solved by removing the project annotation.  In which case, maybe the solution is to remove the project annotation completely?


New ObjectLiteralRule

Proposal to add a new ObjectLiteralRule to determine if Type information should be included with classes marked with the [ObjectLiteral] attribute.

Name
Options
Description

objectLiteral
"Managed" or "Plain"
Set to "Plain" to exclude Type information. Default is "Managed".

This proposal would also require, by default, adding Type information to the generated metadata when [ObjectLiteral] is used. Currently, no Type information is added to the metadata unless [ObjectLiteral(ObjectCreateMode.Constructor)] is applied.
If "objectLiteral": "Plain" (proposed default functionality), the following sample with a DateTime object would have enough type information to deserialized correctly. Currently, fails unless [ObjectLiteral(ObjectCreateMode.Constructor)].
https://deck.net/e9b94490409ad48e416084311e38a60e
public class Program
{
    public static void Main()
    {
        Product product = new Product();
        product.ExpiryDate = new DateTime(2008, 12, 28);

        string output = JsonConvert.SerializeObject(product);

        Product deserializedProduct = JsonConvert.DeserializeObject<Product>(output);
        Console.WriteLine(deserializedProduct.ExpiryDate);
    }
}

[ObjectLiteral]
public class Product
{
    public DateTime ExpiryDate { get; set; }
}

I think that there may be two different use cases and I want to ensure if you're trying to address one or both (or neither!) of them..
The first case is for when I have an instance "x" of [ObjectLiteral] class "MyClass" and I want to interrogate its meta data - for example, I want to know what properties are available on instance "x".
The second case is for when I know that I want to deserialise an instance of "MyClass" and I want to interrogate the meta data of that class to know what properties are available.
I would imagine that the first case would require additional Bridge-specific fields being added to the ObjectLiteral representation (such as a $type or $getType value)? This could potentially cause problems for people using [ObjectLiteral] to generate types to communicate with external JS code? But I guess that's why you'll be making this a configurable option!
It's the second case that I'm really interested in, though. When I'm deserialising, I know that I want to deserialise to type "Product" and so it's important that the properties of the Product class be retrievable so that DateTime values (for example) can be deserialised correctly. If this was a deeper object graph than just a single Product that I wanted to deserialise then it would be important to be able to get the types of other properties because one property may be of a different [ObjectLiteral] type that also has a DateTime field that must be correctly parsed. For this use case, I not have thought that any additional properties would need to be injected into the representation of the [ObjectLiteral] class at runtime, it would only need to generate some additional metadata so that when I call typeof(Product).GetProperties() that the properties data comes back?
I've read the initial proposal here several times but I'm not completely sure which of these use cases (if not both) that you are tackling. If the serialisation example you've shown will work with the new setting then surely the second case is covered - I'm just trying to get my head around any possible ramifications of doing so (and by this behaviour being the default)!

Thanks for the excellent feedback. Can you demonstrate both scenarios in code by sharing a Deck? That way we're all on the same page.

Here's some code that hopefully demonstrates what I'm talking about:
public class Program
{
    public static void Main()
    {
        // This isn't either use case 1 or 2, it's just what I imagine the most common
        // [ObjectLiteral] usage to be: I want to pass an object to some external JavaScript
        // library and I want that object to have zero Bridge.NET annotations - just a clean,
        // simple object
        var config = new MyLibraryConfig { Id = 123 };
        PretendExternalJavaScriptMethod(config);

        // This is use case 1: I have an instance of something and I want to use reflection
        // to look at its properties.. for some reason. Personally, I am not particularly
        // interested in this case.
        var properties = config.GetType().GetProperties();
        if (properties.Any())
        {
	        foreach (var property in properties)
    	        Console.WriteLine("config has property " + property.Name);
        }
        else
            Console.WriteLine("config has no properties");

        // This is use case 2: I want to deserialise some JSON to a known [ObjectLiteral]
        // and I want to be confident that it will deserialise correctly. I imagine that,
        // order for this to work, "typeof(MyLibraryConfig).GetProperties()" will return
        // the properties on the class, even though "config.GetType().GetProperties()"
        // above returned zero results (because there is no way for the runtime to know
        // that the object literal is of type "MyLibraryConfig" unless additional values
        // are injected into it, such as $type or $gettype values - but we don't want them
        // if we're using [ObjectLiteral] to get free-from-Bridge-annotations objects).
        var json = "{\"Id\":456}";
        Console.WriteLine(json);
        var deserialised = JsonConvert.DeserializeObject<MyLibraryConfig>(json);
    }

    private static void PretendExternalJavaScriptMethod(object config)
    {
        /*@
        // Parse config options
        var id = -1;
        for (var propertyName in config) {
        	switch (propertyName) {
        		default:
                	throw new Error("Unrecognised config value: " + propertyName);
                case "Id":
                	id = config[propertyName];
            }
        }
        */
    }
}

[ObjectLiteral]
public class MyLibraryConfig
{
    public int Id { get; set; }
}

(Available at deck.net/b8ae33d45647d58a8fb79f700d452a09).
It's quite possible that my assumption that [ObjectLiteral] is mostly used when "I want to pass an object to some external JavaScript library and I want that object to have zero Bridge.NET annotations" is not something that you agree with.

Hello,
I found myself in this scenario:
I want to pass an object to some external JavaScript library and I want that clean object to pass.
However, I also want to create "bridge managed objects" that rely on the metadata for type marked as ObjectLiteral.
For example. I have this class:
[ObjectLiteral]
public class RatingInfo
{
    public float value;
}

To fire an event I do this:
this.fireEvent<RatingInfo>("change", new RatingInfo {
    value = this.getProperty<float>("value")
});

However, to define the events I need to do something like:
new UI5EventInfo() {
    parameters = new Dictionary<string, UI5ParameterInfo>() {
        { "value", new UI5ParameterInfo() { type = "float" }}
    }
}

And with the metadata, I just can do:
TypedMetadata.CreateUI5EventInfo<RatingInfo>()

having this code:
public static partial class TypedMetadata
{
    public static UI5EventInfo CreateUI5EventInfo<T>()
    {
        var paramDict = new Dictionary<string, UI5ParameterInfo>();

        // copies non static fields
        foreach (FieldInfo field in typeof(T).GetFields().Where(f => !f.IsStatic)) {
            paramDict[field.ScriptName] = new UI5ParameterInfo() {
                type = GetUI5Type(field.FieldType)
            };
        };

        UI5EventInfo evt = new UI5EventInfo() {
            parameters = paramDict
        };

        return evt;
    }
}

I'm using a workaround that consits in using a class not marked with [ObjectLiteral] but marked as [Constructor("{}")], but it feels ugly and dirty, as the semantic meaning given by the ObjectLiteralAttribute is lost.
Please add the option to object literal to support this scenario. Thank you!

@emumanu, do you think Bridge.Script.ToPlainObject() can be helpful for your scenario?
https://deck.net/33a8776596073c4eb2f1bc9c8335920d
public class Program
{
    public static void Main()
    {
        var person = new Person
        {
            FirstName = "John",
            LastName = "Smith"
        };

        var plainPerson = Script.ToPlainObject(person);

        //@ console.log(person);
        //@ console.log(plainPerson);
    }
}

class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

@AndreyChechel,
I don't think so.
I'm in case 1 described by @ProductiveRage and the example I posted above works perfectly if I define RaingInfo like:
[Constructor("{}")]
public class RatingInfo
{
    public float value;
}

and semantically, it feels very natural (it is a strongly typed version with some candy compared to using the javascript library directly) and straightforward except for the missing [ObjectLiteral] in the top of RatingInfo.
I can live with that but I think that something like [ObjectLiteral(TypeInformation.Managed)] would be nicer and more cohesive.


setting dimensions of window

Implemented set_dimensions function, to be used like so:
open Joy.Shape

let _ =
  set_dimensions 800 800;
  init ();
  let c = circle 50 in
  render_shape c;
  close ();
  exit 0

I think that should be good? Had to use some features of Git that I don't have a lot of experience with so you may want to double check, but everything looks good on my end :)

Thanks for the contribution @FayCarsons!


End to end testing: Fixture moved to a separate file

Changes done:

Fixture fx_federation moved out of conftest.py to newly created common_fixtures.py under tests/end_to_end/utils to keep conftest file short and simple.
Correction made to docker workflow for OpenFL image creation step.
Correction made to task runner workflow for memory logs.
README.md updated to indicate that utils contain fixture file.

Successful jobs:

Task Runner workflow - https://github.com/noopurintel/openfl/actions/runs/12292745031
Task Runner via Docker workflow - https://github.com/noopurintel/openfl/actions/runs/12292746636

TaskRunner (docker/gramine-direct) pipeline is failing. please check

TaskRunner (docker/gramine-direct) pipeline is failing. please check

on rerunning it worked


dependencies: change python-igraph to igraph

Please see https://github.com/igraph/python-igraph/issues/699 for the explanation.

Thanks for raising this!
The conda-forge package would still by python-igraph though?

The conda-forge package would still by python-igraph though?

Yes, that one stays python-igraph, see https://github.com/conda-forge/python-igraph-feedstock/issues/42 for the reasoning. I hope this is not causing any problems for you.

No problems, I just wanted to know if I had to update the conda recipes as well :)


[SourceKit] Make explicitly we're casting away a qualifier.

This fixes a clang warning introduced with this code. NFCI.

@swift-ci please smoke test


KerbalFoundries Fix respository error from KSpace

its set to "include in the install" at kerbalspace, correcting thsi with the actual download URL"

Rather than having this set to the download itself, can we have it just point to https://kerbalstuff.com/mod/58/ ? That means it'll still go to the right place even if there's a new release.
(Also, in CKAN v1.10.0 bad download links get ignored by everything, which will reduce the impact from things like this.)

sure, putting the fix in shortly

Merging with thanks!


Create client for Eclipse Che

https://www.eclipse.org/che/docs/assemblies/sdk-language-server-protocol/index.html

answer from jaivardhan kumar on #openshift.io channel:

#openshiftio-che is the right channel , for LSP of analytics we have it wriiten in Typescript and got help from rh-che team while integrating , can see details here https://github.com/redhat-developer/rh-che/tree/master/plugins/che-plugin-bayesian-lang-server , we also need to register as agent  as in https://github.com/redhat-developer/rh-che/tree/master/plugins/ls-bayesian-agent @mario @tsmaeder can help @apupier ^^

currently sidecars are not available (expected in 6 months).
So need ot have the "Che agent" availab directly in Che (or rh-che for openshift;io)
They canbe deactivated by default, so it might be possible ot have a first integration.
i started to create the "Che agent" on this branch: https://github.com/apupier/che/tree/CamelLsp


Link files menu

Description
other(model-service): Remove collapse menu for properties of a metadata record. Properties should always be visible and no need to add clutter with additional ways to collapse.
How Has This Been Tested?
Visual inspection on local branch.
This PR has no functional changes
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have pushed the final commit message using the changelog format

Updated UI

other(model-service): Remove collapse menu for properties of a metadata record. Properties should always be visible and no need to add clutter with additional ways to collapse.


Please add reference on how to change the default convention for a datatype.

I'd like the EFCore default string definition to be varchar(500) not null.  However, I have a limited need for different string lengths, and for unicode strings.  Pre-model configuration doesn't work for this as it ignores any custom configurations applied in the entity.  Its an all or nothing approach.
If would be nice if this page could explain or link to instructions to change the default definition for a data type mapping.

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

ID: 5628451b-252f-b206-3dfc-ae91fb9224bd
Version Independent ID: 5628451b-252f-b206-3dfc-ae91fb9224bd
Content: Model Bulk Configuration - EF Core
Content Source: entity-framework/core/modeling/bulk-configuration.md
Product: entity-framework
Technology: entity-framework-core
GitHub Login: @AndriySvyryd
Microsoft Alias: avickers

@wdhenrik

Pre-model configuration doesn't work for this as it ignores any custom configurations applied in the entity.

This sounds like a bug. Explicit configuration for properties should override whatever is done in pre-convention model configuration. Please attach a small, runnable project or post a small, runnable code listing that reproduces what you are seeing so that we can investigate.


[security]: Show easy installation and update logs for extensions

similar issue?: Haven't found.

I was today afraid, that I have an extension which was not installed by me.
To solve this it would be awesome if I could easily see, when an extension was initially added and also when it was updated to detect security issues.

You could see when it was last updated by opening the extension and in the details tab.

Is this sufficient?

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!


Variable to get a list of results of a task

Feature request
if a i have a list of results
kind: Task
metadata:
  name: some-task
spec:
  results:
    - name: A
    - name: B
    - name: C
    - name: D
    - name: E
    - name: F

I want a variable that tells me the list so i can loop through it in in a task shell
      script: |
        # loop through $(results.list)

A variable which lists the results defined in a task
Use case
I have a list of 10 results , i want to set them to some value.
Right now i have to
echo "X" > "$(results.A.path)"
echo "Y" > "$(results.B.path)"
echo "Z" > "$(results.C.path)"
...

Would be great if i can loop through the results list/

Supports DRY principle.

Thanks for opening this @hokadiri !
Are you able to share any more details around the use case you need this for? e.g. a specific Task with specific results would really help us understand why this is needed.
(I'm also wondering if in this case you'd prefer to be able to have an array or dictionary type result - but I think even if we supported those, we've been hesitant to support variable replacement for going from an array to a string b/c it's hard to say how it should be formatted - e.g. separated by commas? spaces? something else?)

Hi @bobcatfish, I have a tekton task that runs a tool which takes a git commit and outputs the list of tests to run with some additional metadata
{
  "test-a": {
    "cmd": "some cmd",
     ... some other metadata
  },
  "test-c": {
    "cmd": "some cmd",
    ... some other metadata
  },
  "test-d": {
    "cmd": "some cmd"
    ... some other metadata
  },
  "test-e": {
    "cmd": "some cmd"
    ... some other metadata
  },
}

Ideally I want to take this json and trigger concurrent task runs (One test per task).
Since results can't be lists/dictonaries, workaround is i'm creating a result for each test, looping thru and setting it.
To set it, I wanted to loop through the result list
For each test in $(results.list)
  if test in json:
    set result.test to true
  else:
    set result.test to false

Ideally if results can support multiple types (not just string), then I can do:
run task to generate json output -> convert json to results dict -> pass results dict to tekton taskB iterparams -> task-loop concurrently -> fan-in -> done

ooooo thanks for the additional info!! i've actually just created 2 proposals that might help you out:

TEP-0076 array results
TEP-0075 dictionary params + reseults

(Eventually I think we should allow even more complex types, e.g. arrays of dictionaries, etc.)
Maybe even just having array results support would be enough to unblock you for now? (it sounds like task-loops might be relevant to your interests also, if you wanted to run the same Task "for each" test)

@bobcatfish , yeah having array results support - in conjunction with task-loops - would be enough to unblock me.
In general being able to convert a json/yaml file to an equivalent object tekton understands and vice versa would be a very helpful feature.

/lifecycle frozen
Adding frozen lifecycle given its relevance to the array results & indexing TEP.


Add option to use primary X selection instead of clipboard

Terminology: https://specifications.freedesktop.org/clipboards-spec/clipboards-latest.txt
It should be possible to control which X selection enpasscli copy writes to. By default it always writes to clipboard but primary may be useful for many scenarios, e.g. paste by middle mouse click or bypass clipboard managers logging entries.

Fixed in https://github.com/hazcod/enpass-cli/commit/ff67a8221fb3370ab1a7ebe09e2f90a4ed02628f , thanks @msladek !

@hazcod the release build was successful for linux but failed for darwin https://github.com/hazcod/enpass-cli/runs/4702500913
this is probably because github.com/atotto/clipboard has os specific go files and the Primary property is available in clipboard_unix.go but not in clipboard_darwin.go.
thus clipboard.Primary = true should only be set on unix, right? I'm not familiar enough with go, how can this be done?

@msladek Hmm, we probably should write a wrapper file with the primary clipboard thing being set in e.g. clipboard_linux.go only.

If I understand you correctly something along those line:

extract clipboard.WriteAll to a new clipboard.go file
pass clipboardPrimary boolean to it, the default clipboard.go implementation does nothing with it
add clipboard_linux.go that additionally sets clipboard.Primary = true
Does that sound about right?

@hazcod see #108
not sure if we could somehow solve this without a clipboard_darwin.go but providing a default implementation, but this should work as well.


WIP: Replace MSSQL dialect with Tedious.js implementation

DO NOT MERGE THIS PULL REQUEST YET -- See below
Tedious.JS MSSQL dialect driver
Hello Knex,
I have been working on deprecating the use of node-mssql in favour of tedious which is the underlying TDS stream driver for talking with Microsoft SQL server for about six months now.  I wanted to take it into production before I made people aware of this patch to make sure it was worth submitting.
Rationale
I ran into major issues with every ORM or query library that uses node-mssql under the hood for MSSQL, which ultimately completely prevented me from running my system in production.
In a nutshell, the problem is that node-mssql is in itself a high-level driver that contains its own mechanisms which Knex either doesn't need, or conflicts with.  To summarize the problems with using this library for this dialect:

Timeout acquiring resource messages, killing the application,
Random, huge latency spikes between query and result, making performance unstable,
Connection timeouts on startup, and
Inability to recover from error conditions

The SQL dialect experience with Microsoft SQL Server on node.js, and Knex in particular, is very poor because of this driver.
Patch details
This patchset contains a working implementation of tedious backed by a few months of my internal product running in production without issues.  The patch discards the second-level connection pool provided by node-mssql and simply attaches Tedious connection objects to Knex's pooling mechanism like every other dialect.
With my driver running in production there have been no resource timeouts, no connection issues, and Knex receives the results of the query as fast as Tedious.js can deserialize the token stream. This implementation has been the most stable my project has ever been on MSSQL.
This driver patch is not yet complete, thus my goal is to raise awareness that a replacement mssql driver exists for Knex and there is hope yet for Microsoft SQL users.  I don't use some of MSSQL's functions so I am unable to complete some of the driver, but it is good enough for me to roll into production right now.
Some areas I could use some help on are:

Rebase against current Knex
Transaction support may be buggy
Most tests pass, some don't
Migration tests don't seem to pass, concurrency issues?
It appears some of the test suite has been lapsed for mssql, perhaps on part of driver quality?
Some of the esoteric data types might need attention

You can checkout this pull request and use tedious.js to connec to MSSQL directly right now.  I am looking for some help though, If you use Microsoft SQL and have some time to spare, together we can help make MSSQL great again .
Thanks for looking! :+1:

Crap! Totally forgot those were in there! I will clean ‘m up ASAP.

@tylerjwatson I would like to contribute to the effort (e. g. sync with master), may I ask for a write permissions on your fork?

@kibertoad Can do, I just need to be careful for the time being.
The reason for the lib trash on this branch is because I needed to point yarn somewhere to the built sources so I can use it in production, and this seemed the least path of resistance to "get it working".
I'll ship my internal software onto a separate branch away from this pull, clean up the lib trash, and we'll take it from there.
Stand by.

Alright everyone, some cleanup has been done.  The lib trash has been removed and some meta files that I didn't mean to touch have been checked out from master to bring them back to where they should be.
Some things I'll need some help with now:

Configuration format, I just jammed Knex's connection configuration straight into tedious, this is probably not what we want,
For the life of me I could never get npm run tape to work on plaintest, so I just removed it to develop the driver.
Transaction stuff could use a lookover
Migration tests aren't too happy

Hopefully now we can get some review happening :+1:

I just jammed Knex's connection configuration straight into tedious

Isn't that what knex does for other dialects, though? I think {connection: {}} branch is always passed to driver as-is.
Can I get write access to your repo so that I could start fixing stuff, or you still need to remove some things?

Done mate, knew there was something I forgot. :P

@dhensby Do you think that there is still value in this PR? Most connection management issues with node-mssql were resolved in v5 already, and it is likely that v6 will address the remaining ones.

Whilst that's true, it does seem a bit strange to go through the mssql lib to access connections given the pools we create internally.
I think there's value to it, but it's a lot of effort for diminishing returns at the moment.
Given the effort has been put in, it would feel a shame not to get it over the line... But this is a few versions behind now...
It's probably 50/50 at the moment

I think there's value to it, but it's a lot of effort for diminishing returns at the moment.

Respectfully, the effort was simply because node-mssql is unsuitable for production.  Its use of generic-pool and forcing futures to go through this silly arbitration mechanism that breaks the very concept that futures provide programmers means it can never be the basis of a truly stable driver.
I suppose it depends on what your values are, but for myself I can't risk the application going down for our customers simply because a dialect driver isn't stable.  The benefits are night and day for us and well worth the time investment.  We can never go back to to the previous driver as the trust has been broken here, and it doesn't look like the clashing high-level pool fundamentals are changing.  Sequelize is also a victim of the same problems and their issue trackers are a mess with these sorts of problems.
That said, upstreaming this driver means I don't have to maintain a fork which is great for me but it relies on community engagement as Knex's surface area on what it requires of a dialect far exceeds my use case and there are going to be people who use functionality that I don't.  I may have broken that for some users, but we'll never know if the community has no need to engage with another driver.
At the end of the day if the community is happy with the way it is now, there is no point in merging this.
Cheers

@tylerjwatson it's great to hear candid feedback and I've only started working on the mssql library in the last few months as we need it in production. The only reason we use it is because we need stored procedure support and that doesn't seem to be available anywhere else (that I know of).
I've tried to make quite a lot of progress around issues with pooling and so on.

For example, their support has people performing bulk operations with Bluebird.mapSeries and other insane stuff like increasing pool timeouts because the driver can't understand that futures and database connections aren't, and should never be explicitly tied together. Future mechanisms like Promises shouldn't be used for queues, and doing so should be regarded as an error.

I think this has been removed as of v4 (I'm not familiar with the history of the library or how it worked, but there were issues complaining about queuing being removed when people were upgrading from 3 -> 4) so perhaps some of those issues have gone now?
Regardless, if you have any time or inclination to open some issues against the library, that'd be a big help.
We had some really bad issues in production with pool leakage, connection issues and other problems which, through various contributions and maintenance, are now gone.
I have no attachment or incentive to see Knex use mssql and it does make sense to me for it to make use of the tedious library directly but, like you say, it's up to the community / maintainers to take on any of the extra work to make it feature complete.

Regardless, if you have any time or inclination to open some issues against the library, that'd be a big help.

Sure mate, how can I help?
I last dealt with node-mssql around the turn of v3 to v4.  The main impetus for this driver was the fact that it would choose random queries to just... stop.  It was un-reproducible. It would happen at indeterminate times to any query, and knex would just stop responding to requests from the clients, grinding our show to a complete halt.  I never quite figured out what it was, so after many sleepless nights and expletives I simply gave up and did my own.  Sometimes it would cough up a message saying resource aquisition timeout and other times it would just stop issuing queries.  The root cause is somewhere in node-mssql because my driver has had no downtime in production since we adopted it, ever.
I just could not produce a test case for any reports to be of use to anyone.  I feel that a report without reproducibility is just whinging.  I'm happy to help, what would you have me do?

Thanks for that @tylerjwatson
As you've said that this was around the turn of v3 -> v4, I think that it's likely a lot of the behaviour you've experienced has been resolved and there may not be a lot off feedback that is applicable anymore.
It seems like there was quite a fundamental shift in v3 -> v4.
I'm glad that you've managed to resolve your production issues by running tedious directly. We don't use knex in prod, just mssql and over the past few months we've got it into a pretty healthy shape for prod compared to when we started - but this is all relatively recent and it sounds like your experience is from quite some time ago.

I would be still happy to change mssql -> tedious, but I don't see it as urgent as before, since the worst of the problems did seem to be resolved and my own stress tests did pass on newer mssql version.  I still consider mssql driver as an unnecessary piece that is not adding any value to knex.

Hi guys, I'm back with a later revision of this patch.  I've just completed a rebase of the tedious MSSQL driver onto Knex 0.20.
Some things of note here:

All the MSSQL-specific monkey patches have been removed
All tests pass locally, but travis seems to fail some unrelated MySQL things, and configuration resolver stuff that appears to be new.
Some tests have been modified: ; select @@rowcount is redundant as tedious has these counts natively from the stream
The tape has been modified for MSSQL as tedious itself handles transaction stuff.
In mssql, rollback is analogous to rollbackTo.

@tylerjwatson Looking at https://travis-ci.org/knex/knex/jobs/604778022?utm_medium=notification&utm_source=github_status, I see failures only for MSSQL tests. Could you take a look at them?

@elhigu Do we still want to replace node-mssql with Tedious, given that node-mssql seem to be finally fixed properly?

Ah, I see your previous comment on exactly this matter, I guess that stands.

Just to give my thoughts on mssql - it does seem a bit overkill to use mssql as the dependency (though it provides a bit of syntactic sugar on the top of tedious), but as @kibertoad points out a lot of the problems with mssql (especially with pooling) have been fixed and I'm about to release v6, which should prove to be a pretty simple upgrade.
It'll definitely be leaner to use tedious directly but the maintenance effort might not be worth it

I’m confused at how having clashing pooling layers with a high-level driver talking to another high-level driver is less maintenance than simply talking to the stream like all the other dialects. Could you please elaborate?
I still get “unable to acquire connection” errors when using stock mssql dialect implementation so I will still be forced to use my downstream version. I’m happy to maintain the dialect once it’s been upstreamed if need be, or I can publish the dialect driver as a separate downstream package in knex-mssql as another option for people to use.
The general sentiment is mssql seems to be fixed which is not a good place to be. It needs to be stable, and not relying on monkey-patching to get us there.
Cheers
Sent from my iPhone
On 4 Nov 2019, at 4:15 am, Daniel Hensby<EMAIL_ADDRESS>wrote:

Just to give my thoughts on mssql - it does seem a bit overkill to use mssql as the dependency (though it provides a bit of syntactic sugar on the top of tedious), but as @kibertoadhttps://github.com/kibertoad points out a lot of the problems with mssql (especially with pooling) have been fixed and I'm about to release v6, which should prove to be a pretty simple upgrade.
It'll definitely be leaner to use tedious directly but the maintenance effort might not be worth it
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/knex/knex/pull/2857?email_source=notifications&email_token=ABGFBQEWPZGHEPEKGPGL2OTQR4IKXA5CNFSM4F3KMB6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5ZFYI#issuecomment-549163745, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGFBQB52TOO7AC4DUCPOADQR4IKXANCNFSM4F3KMB6A.

I’m confused at how having clashing pooling layers with a high-level driver talking to another high-level driver is less maintenance than simply talking to the stream like all the other dialects. Could you please elaborate?

I don't think it's important for us to get bogged down in that discussion. Whether the maintenance burden is greater or less is for the maintainers of this library to decide, it is just a point I was raising.

The general sentiment is mssql seems to be fixed which is not a good place to be. It needs to be stable, and not relying on monkey-patching to get us there.

The mssql driver has gone through 2 major versions since the original pooling problems and the pooling library has been replaced with tarn and is much more stable. We should not rely on monkey-patches to keep mssql stable.

Simpler is better, I guess. So as long as we can make tests pass on this PR, should be fine to merge it.

@tylerjwatson Any estimates on when you would have time to take a look at test failures? I'd like to bump prettier version in dependencies, but doing so is going to cause lots of conflicts for your changes, so I'd prefer to avoid that until this PR is merged.

Hi mate.
Apologies for going dark; I’m sporting an injury at the moment and won’t be back in the game until next week at the very least.
Feel free to do your changes, and I will look after the downstream forks if need be.
Cheers!
Sent from my iPhone
On 15 Nov 2019, at 5:20 am, Igor Savin<EMAIL_ADDRESS>wrote:

@tylerjwatsonhttps://github.com/tylerjwatson Any estimates on when you would have time to take a look at test failures? I'd like to bump prettier version in dependencies, but doing so is going to cause lots of conflicts for your changes, so I'd prefer to avoid that until this PR is merged.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/knex/knex/pull/2857?email_source=notifications&email_token=ABGFBQFU7GJVLZTJ6FEKLOTQTWQJHA5CNFSM4F3KMB6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEC7NDY#issuecomment-554038927, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGFBQFHVNWI6RBEMPH5ALLQTWQJHANCNFSM4F3KMB6A.

Getting closer!
Hope you are feeling better now.

This PR looks like it will be very handy!
However, we've also been refactoring a lot of the core Transaction / Dialect logic lately.  On the plus side, this should make it easier to introduce new Dialects in the future.  But, on the downside, I suspect that there are some very major merge conflicts between this branch and master now.
Would you like a hand w/ getting this branch updated?
(On a side-note: it might actually be easier to implement this alongside the existing clients rather than as a wholesale replacement.  This would help to avoid merge conflicts and allow potential end-users to beta-test the new implementation)

@tylerjwatson Just a heads-up - I'm currently working on syncing your branch up with the master, hopefully this PR can finally be merged after all this time.

@tylerjwatson Way more tests are failing now, which is to be expected after syncing with such a significat internal refactoring, I guess :-/. Will try to catch breakages now.

@tylerjwatson There are two large groups of failing tests left: response processing being broken and migration table being unlocked. Also I see that transaction reimplementation is incomplete, e. g. rollbackTo is not implemented. Would you be able to pick any of these items?

Wow I thought this PR was abandoned.  Appreciate it, I will take a look.
Get Outlook for Androidhttps://aka.ms/ghei36

From: Igor Savin<EMAIL_ADDRESS>Sent: Friday, February 5, 2021 11:57:15 PM
To: knex/knex<EMAIL_ADDRESS>Cc: Tyler Watson<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [knex/knex] WIP: Replace MSSQL dialect with Tedious.js implementation (#2857)
@tylerjwatsonhttps://github.com/tylerjwatson There are two large groups of failing tests left: response processing being broken and migration table being unlocked. Also I see that transaction reimplementation is incomplete, e. g. rollbackTo is not implemented. Would you be able to pick any of these items?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/knex/knex/pull/2857#issuecomment-774047898, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGFBQF6VRFZVNBSVPSTOSTS5P2LXANCNFSM4F3KMB6A.

That seems to have resolved the majority of problems! Only 6 tests are failing, looks like this will be good to go after transaction support is completed.

Hooray!  The 6 failing tests seem to be the transaction tape and all of them are savepoint stuff that are guarded with statements like
      let expectedTrx1QueryCount =
        knex.client.driverName === 'oracledb' ||
        knex.client.driverName === 'mssql'
          ? 1
          : 3;

MSSQL has quite strange support for savepoints.  I'm not sure these tapes are valid.

The tapes assume that transaction statements emit query events, which in tedious they do not.  I can either try and emit fake query events or modify the tapes to take this into account.

@tylerjwatson Why did they use to pass in the past then? Does node-mssql has its own logic for handling transactions? What would be your suggested path forward?

@tylerjwatson Do you think that it is likely that someone might have been relying on these events in the past in their production logic? That would imply we should be firing them on our end now.

@kibertoad It's impossible for me to say for certain, and I would struggle to find a decent use case that would need to handle transaction semantics inside events.
knex(table).transaction(async function trx1() {
  trx1.on('query', data => {
    if (/begin/i.test(data.sql) {
       // ... seems farfetched.
    }
  });
});

It is not my place to tell others what they do with their production code, and since changing a tape that affects all dialects is much more risky than just faking events, I'll look into emitting query events on the transaction.  Behavioural consistency between all dialects as much as possible is also better.

@tylerjwatson Yes, that sounds reasonable. Thank you!

@tylerjwatson Tests are still green, so I would say we can merge it after updating that one transaction test.

It should be ready now.  Let me know if you need me to pay attention to other areas.

This is great, thank you!
Note: while I was syncing with master, I dropped few of previous changes from your branch, to focus on driver change per se, without changing the behaviour.
Notably: passing query context to errors; JSON support; removing explicit select rowcount from queries. Since I assume that you had good reasons for these changes, and you would need them should you return upstream, maybe we could discuss them and restore some or all of them in a separate PR?

Awesome!  Glad to see this has finally landed after all this time.  I am very excited about coming back upstream, it's never nice being left in the dark with new features.  I'm particularly excited about the deprecation of Bluebird for native promises.

We're finding that when an SQL query error is generated we have no idea where it came from.  Passing express req objects as query context is a small-overhead way to attach meaning to errors in the callbacks.  Since query errors are logically owned by queries which have a query context we found no harm in sinking the query context into error emits.  We can simply log them to the logger attached to the express request and we can get meaningful information like requesting user, response time, etc.

There's little use in the query-error event otherwise as there's nothing for our devops team to relate back to.  This change is important and we'll need it before we return upstream unless I can figure out something else.

I can't remember what JSON support entails.

Removing @@rowcount was erroneous functionality and can be left alone as-is.

@tylerjwatson Gotcha, I'll make a PR restoring query context and JSON support shortly for your reviewn then.
Another thing missing are the TS type changes. Could you look into syncing current knex mssql config types with what is currently supported?

@kibertoad Nah let's do it properly in separate PRs.
For JSON support see #4278,
I'll look at doing query-error support properly shortly
I'll also update the types appropriately