Speed up Yaks

I recently watched a presentation on ActiveModel::Serializers. They were talking about how they added caching of serialization. I was thinking that it was kind of silly, because the only thing that ActiveModel::Serializers can cache is the serialization itself, the objects are still fetched from the database, which I thought was incomparably slower.
So I decided to benchmark serializing one simple user object with about 10 attributes. I compared AMS, Yaks and fetching that user object from the database, you can see the benchmark. This is what I've got:
     ams:    10048.9 i/s
database:     3069.7 i/s - 3.27x slower
    yaks:     2430.1 i/s - 4.14x slower

Yaks turn out to be more than 4 times slower than AMS, that it's even slower than a database query. I tried with HAL, it's the same thing.
If you guys find this as important as I do, I would gladly work on speeding Yaks up. Would you be willing to accept a PR with eventual refactorings for the sake of performance?

Speed improvements are always nice. I have my suspicions of where that time is going, but we really should measure and verify.
We might need a pretty big overhaul of how things work to really get much improvement. But maybe there are some quick wins as well. I would suggest you start by doing more measurements, and then propose specific changes.

Looks like a good idea. Another idea could be to also add a rake task on Travis CI that does a benchmark to see if any new change improves or decreases the overall performance.

Hey everyone,
Have a look at the performance_experiments. I did some poking around and already managed to get some quick wins. I tried to split things into separate commits so they can be tested and discussed separately.
It seems the slowest steps in our pipeline are map and primitivize. Especially primitivize becomes a lot faster with these changes. Some changes force breaking the public API though, so we'll have to see in which cases that is worth it.
@janko-m I started with your benchmark then started playing around with it. It's a bit of a mess now as I measured different things in different ways and commented/changed/added things as I went along.
What I'd like to do is look at each change in turn again, measure before/after speed for various data sets and uses, and then add them to the main tree if cost/benefit looks good.
One thing I haven't focused on much is object allocation and garbage collection. This is an area where we probably have quite some space for improvement. There are some good tools for benching these things on recent rubies, but I haven't gotten to play with them much recently.

@plexus great job! :+1: I'm looking at it right now and I might add a few comments here and there.

To be clear, ear slowest step by far is the mapping, but in primitivize the wins were a bit more obvious. We'll definitely have to have a closer look at mapping next.

This is really great. Yeah, it would be awesome to note the performance improvement for each commit in the commit description.
When I benchmarked the first time, I also checked memory usage with the memory_profiler gem, and it looked really good as far as I remember, I think it was much less than AMS. But it's good to check again :)


Unit test fails when building latest release

I have downloaded the latest release and when running
mvn clean install -P release
the build consistently fails with the following output
`
[ERROR] Tests run: 24, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.808 s <<< FAILURE! - in org.tinylog.path.DynamicPathTest
[ERROR] getMultiTokenFiles(org.tinylog.path.DynamicPathTest)  Time elapsed: 0.014 s  <<< FAILURE!
java.lang.AssertionError:
Expecting:
<[/var/folders/4y/0h2fbwbs7hg_12ltvff3g29m0000gn/T/junit4167999617599005228/2018_2.log,
/var/folders/4y/0h2fbwbs7hg_12ltvff3g29m0000gn/T/junit4167999617599005228/2018+3.log,
/var/folders/4y/0h2fbwbs7hg_12ltvff3g29m0000gn/T/junit4167999617599005228/2018_1.log]>
to contain exactly in any order:
<[/var/folders/4y/0h2fbwbs7hg_12ltvff3g29m0000gn/T/junit4167999617599005228/2018_1.log,
/var/folders/4y/0h2fbwbs7hg_12ltvff3g29m0000gn/T/junit4167999617599005228/2018_2.log]>
but the following elements were unexpected:
<[/var/folders/4y/0h2fbwbs7hg_12ltvff3g29m0000gn/T/junit4167999617599005228/2018+3.log]>
at org.tinylog.path.DynamicPathTest.getMultiTokenFiles(DynamicPathTest.java:224)

`

Which operating system are you using? All JUnit tests run consistently on the Linux build server (https://travis-ci.org/pmwmedia/tinylog/builds/510059156) as well as on my private Windows 10 machine. What JDK are you using?
Could you debug the test org.tinylog.path.DynamicPathTest.getMultiTokenFiles()? For analyzing why this test fails on your machine, I would be helpful to know what are the values of the variables folder and files in org.tinylog.path.DynamicPath.collectFiles() and the value of the field plainTexts.

@gabrielnasser I have found the cause why this test failed on your machine. The reason is the underscore in your path. I will fix the index in org.tinylog.path.DynamicPath.collectFiles().

For good measure, I'll add the environment info to the original comment.

I also confirm the build passes with this fix. Thank you.


Make a way to define hidden files/folders

The user needs a way to define specific hidden files/folders.  The solution must not let a user be able to browse this list publicly.

Resolved.


Incomplete npm dependencies for sap.m?

I'm trying the new approach, installing OpenUI5 runtime from npm, when I discovered that sap.m package has no dependency on sap.ui.layout?
According to my limited knowledge (may be incorrect), some components in sap.m are dependents of sap.ui.layout, an advanced code search reveals 11 occurences of sap.ui.layout or sap/ui/layout within /src/sap.m/src/sap/m folder.
If the dependency is there, you may want to add them to the dependency list (or refactor the code so that it no longer depends on the said library), otherwise some functionality may become broken I think?

Hello @zypA13510 ,
Thank you for sharing this finding. I've created an internal incident<PHONE_NUMBER>. The status of the issue will be updated here in GitHub.
Regards,
Alex

@codeworrior, @matz3: do you know whether the missing sap.ui.layout dependency in the sap.m .library file is an error or intentionally?
There are a couple of layout dependencies in sap.m controls. Examples:

https://github.com/SAP/openui5/blob/b9f14206bd1ff5f18a8bbde6bf20762b6238cd2a/src/sap.m/src/sap/m/P13nFilterPanel.js#L402
https://github.com/SAP/openui5/blob/b9f14206bd1ff5f18a8bbde6bf20762b6238cd2a/src/sap.m/src/sap/m/QuickViewPage.js#L10-L12

Dependencies within controls alone are NOT sufficient as an indicator for a library dependency. The colleagues responsible for the sap.m library decided in the past to model only very common dependencies (those where it is unlikely that a user of sap.m can work without those dependencies).
Any hard dependency would add to the initial load for every app loading sap.m.
As long as many common controls of sap.m can be used without loading sap.ui.layout,  I would assume that it was a conscious decision to omit the dependency. But the colleagues should know best.
The source of truth is the .library file and it only lists sap.ui.core (which is mandatory) and sap.ui.unified (as a lazy dependency). So the NPM module seems to be consistent with that.
Strangely, the pom.xml lists a dependency to sap.ui.layout, We usually suggest to add a lazy dependency then to the .library file (as it was done for sap.ui.unified). Not sure why this was not done for sap.ui.layout.
Last but not least: there must be no cycles in the dependencies. As far as I can see, there's no dependency from sap.ui.layout to sap.m, that's fine.

Ping @codeworrior

Ping @codeworrior: do you think we should add sap.ui.layout as a dependency in the package.json of sap.m?

Hey @zypA13510, we added the sap.ui.layout dependency to sap.m. This change will probably get released with the next minor OpenUI5 release. Thanks for reporting!


Added support for scalars in dictionary interface

As part of improving support for associating additional information with paths we decided that the dictionary interface should allow scalars as part of the format, avoiding having to duplicate the scalar value for each sample of a path/polygon. This PR makes this possible, while follow up PRs will start adding support for using this to represent scalar values associated with paths.

Glad to see this coming together!
I think we should work together on the documentation to make sure we convey how all these different threads come together (multi-interface, associated user API that still needs fleshing out, support for constant columns added in this PR). In theory, there could also be plotting code changes e.g supporting changing color along a path but that is less critical.

There will be a path/polygon/geometry user guide to go alongside the gridded and columnar ones.  Once this PR is merged I can start working on that while I actually start implementing support for plotting scalar and continuously varying variables associated with paths. The user API, which I expect to be fairly minimal additions on top of what we currently have, can follow shortly after that. So the steps from here are:

Expand Path/Polygon key dimensions to allow additional scalar variables and add validation to ensure that these variables are indeed scalar.
Extend Path/Contour and Polygons plot implementations to support scalar and continuous variables and color the glyph/artists accordingly.
Start writing a path/geometry user guide to demonstrate how to construct and work with path data.
Decide on and implement any additional user level API necessary for easily working with paths.

Anyway, this PR is ready to merge once tests pass.

For your step 2) don't we also want the op/norm system in place first?

For your step 2) don't we also want the op/norm system in place first?

Not really, colormapping is never really going to fit into that since that's done client-side.

I think there are possibilities other than just colormapping - for instance, mapping a vdim to the thickness along the path. Not about how technically feasible that might be but it does fit in conceptually with the improved vdim support for path types.

for instance, mapping a vdim to the thickness along the path.

Oh absolutely! There's a bunch of possibilities from line widths to alphas and other things I can't imagine right now, but that can happen independently from the path stuff I described above.

Ready to merge.

I think another optional improvement for the dictionary interface will be to allow combining multiple dimensions, letting you do something like this:
{('x', 'y'): np.random.rand(10, 2), 'z': 1}

Might be a more natural way to represent paths.

... letting you do something like this:

{('x', 'y'): np.random.rand(10, 2), 'z': 1}
I think we might have discussed something similar in the past (related, if not exactly the same). It seems like a reasonable thing to support at some point.
Anyway, tests have passed and I'll merge now.

I think we discussed in context of the grid interfaces for the value dimensions, for example for RGBs.


Added FontAwesomeViews for storyboard

I've created some subclasses to use controls like an UISegmentedControl in storyboard with IBDesignable support. You can type in the CSS-Code and the Storyboard will show the correct icon from FontAwesome. Apple does not render UITabBarItem and UIBarButtonItem in storyboard, but they will have the correct appearance at run time. I've only created subclasses of UI-elements that does not support attributed texts.

          1 Message

:book:
@Maik639 is not a contributor yet, would you like to be a FontAwesome.swift maintainer?

  Generated by :no_entry_sign: Danger

Thank you for your contribution!


Explorer Component Hidden On Mobile View

Describe the bug
Explorer component disappears when on mobile or resizing the screen on desktop.
To Reproduce
Access the site on a mobile device or shrink the browser window on desktop.
Expected behavior
Explorer links should still be viewable and clickable. Can't navigate on mobile.
Desktop (please complete the following information):

Quartz Version: [e.g. v4.2.3]
node Version: [e.g. v21.7.1]
npm version: [e.g. v10.5.0]
Browser [e.g. chrome, edge]

This is not a bug, we re-arrange the layout on mobile/smaller screens.
Closing as duplicate of https://github.com/jackyzha0/quartz/issues/455

How is the layout "rearranged?" The explorer navigation seems to simply go away. I see no way to access the navigation at all, or the TOC. Shouldn't there be something like a hamburger menu, or swipe gesture to show the sidebars (like Obsidian)?

Yeah, I am having the same experience as @nickian - left/right components just disappear when resizing the window smaller instead of the desired behaviour (going on top).
Thanks for your awesome project!


Comment on: Getting Started

getting-started.md

Enter your comment here:

The first line reads:

4D View Pro is a 4D component that includes a 4D form area an specific methods.

Replace the determiner an with the conjunction and.
The revision will make the first line appear as:

4D View Pro is a 4D component that includes a 4D form area and specific methods.

Note that an now reads and.

thank you, it is now fixed in all branches


Feature/ma 187 audit

https://allyapp.atlassian.net/browse/MA-187
Improvements for the findings from the audit.

:+1: after travis is green :)


RNA_quant single strand + fastp

1.Implement what is proposed in #233
2. Use fastp for adapter removal
3. accommodate single strands

@hsun3163 thanks it reads very good! I've made some concrete comments. My only additional request is that you document as much as you can for what you have learned about fastp that you believe useful -- while it is still fresh in your head! Please commit and resolve all my comments, and i'll merge after that.

APEX, tensorQTL, ss_merger output documentation update as discussed.

@hsun3163 i'll merge it anyways for others to see but please keep working on resoving my other comments from yesterday (if not already) after I merge

@hsun3163 thanks it reads very good! I've made some concrete comments. My only additional request is that you document as much as you can for what you have learned about fastp that you believe useful -- while it is still fresh in your head! Please commit and resolve all my comments, and i'll merge after that.

Those are all done


Use a nonce to verify shell integration command lines

This is a follow up to improve the UX of rerunning and trusting a command line from shell integration scripts https://github.com/microsoft/vscode/issues/179701

To verify repeat these steps for each shell type (bash, zsh, fish, pwsh):

Open a terminal and ensure shell integration is activated
Run the toggle escape sequence logging command
Run a command in the terminal, verify you see a line with a guid in the escape sequence log like this:

Click the shell integration decoration and select rerun command, verify that it reruns the command immediately, without a confirmation prompt

For bash only run echo -e '\x1b]633;E;fake', verify that you get a confirmation prompt


Bump to JDK 17 or at least 11

Use case description
Trying to develop with a local checkout, following https://github.com/androidx/media/blob/release/README.md#locally,  is problematic because of the JDK 8 target.
warning: [options] target value 8 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
warning: unknown enum constant Level.FULL
  reason: class file for com.google.j2objc.annotations.ReflectionSupport$Level not found
4 warnings

Java compiler has deprecated support for compiling with source/target compatibility version 8.
Set Java Toolchain to 17
Change Java language level and jvmTarget to 11 in all modules if using a lower level.
Pick a different compatibility level...
Pick a different JDK to run Gradle...
...
Execution failed for task ':media3-lib-common-ktx:compileDebugKotlin'.
> Inconsistent JVM-target compatibility detected for tasks 'compileDebugJavaWithJavac' (1.8) and 'compileDebugKotlin' (17).

Proposed solution
Bump to JDK 17 and assume apps are using desugar to target older devices.  This is already effectively required for Androidx and most popular android libs.
Alternatives considered
Pin permanently to old Gradle, AGP versions and remove support for local checkout.

This needs to be addressed. Currently working to implement this library into our application and I have had the same message come up while trying to compile it.

I'm not sure I fully understand the problem here.
I can git clone this project and open the resulting directory in Android Studio without issue.
What are the concrete repro steps to see the problem?

Minimal repro is to try to follow the local development instructions, but you need 2 project checkouts. 1) the app using media3, 2) media3.

Trying to develop with a local checkout, following https://github.com/androidx/media/blob/release/README.md#locally

That said, I was under the impression that Androidx was already ahead, but it seems like libraries are still building against Java 8.
https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:buildSrc/private/src/main/kotlin/androidx/build/AndroidXImplPlugin.kt;l=1464;bpv=1
But if so, we might have to accept that "local checkout" mode is broken for most apps.

Depending locally on the media3 git checkout from another AS project is working for me, following the linked instructions.
This is with the following Gradle, AGP & AS versions:
agp = "8.9.0-alpha03"

distributionUrl=https\://services.gradle.org/distributions/gradle-8.10.2-bin.zip

Android Studio Meerkat | 2024.3.1 Canary 3
Build #AI-243.21565.193.2431.12691553, built on November 21, 2024
Runtime version: 21.0.5+-12651406-b631.16 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Toolkit: sun.awt.X11.XToolkit
Linux 6.10.11-1rodete1-amd64
GC: G1 Young Generation, G1 Concurrent GC, G1 Old Generation
Memory: 8192M
Cores: 96
Registry:
  ide.index.image.max.size=0
  debugger.watches.in.variables=false
  reasonable.application.thread.pool.size=256
  ide.experimental.ui=true
  i18n.locale=
Current Desktop: XFCE


Virtual keyboard, dropdown to top and other issues

Firstly, awesome plugin.
Issues: v4. Branch: select2-ng

Tried using my iphone on your example page but the virtual keyboard opens and closes immediately, which makes it unable to type. This also happens when, onclick on the single select input box.
iphone again: Dropdown on the first select on your example page is showing to the top, making the dropdown hidden under the top menu.
minimumResultsForSearch is set to "-1" but searchbox still appears.
closeOnSelect doesnt seem to work.

Thank you for sharing this plugin with all of us!

Also noticing this issue. Doesn't happen the initial appearance is a text field.

Hi. We are experiencing issue #1 on iOS devices for both Chrome and Safari.

We have the same problem ! It would be great to solve it !

This issue is not useful because it covers too many different problems.  Furthermore, I believe most of these are already covered by other open issues or have already been resolved:

#3493
This may be something that can be solved with dropdownParent
minimumResultsForSearch should be set to Infinity, not -1.  See #3055
It appears that closeOnSelect was dropped in early beta versions of v4, but was reintroduced in https://github.com/select2/select2/commit/c9a8508a39a1ec8b398b988add5f17f2391ff6f2.


boost::scoped_ptr demo

Example code in response to https://github.com/dtolnay/cxx/issues/251#issuecomment-735275024.
Note this line is using cxx::kind::Opaque:
https://github.com/dtolnay/cxx/blob/bb4fda0682611b11c494abee2ad752114e88058b/scoped_ptr_demo/src/main.rs#L16
because passing a boost::scoped_ptr by value across the FFI is not possible due to both of the following being true:

It uses the "small class" ABI in C++ which Rust has no representation for. Any Rust data structure will always either look like "small POD" or "big classes" as far as the ABI in C++.

It exposes no way to exit out of "small class" state (analogous to unique_ptr<T>::release which is what we use for making UniquePtr work by value on the language boundary).

For a different smart pointer for which one or both of these doesn't apply you'd probably use cxx::kind::Trivial because Rust's move semantics are non-problematic for anything pointer-like.

#525 shows an approach where item 1 in https://github.com/dtolnay/cxx/pull/524#issue-529004118 does not apply -- it just works around "small class" by adding padding, which isn't great, but is compatible with Rust.


[UI] Google Auth - Issue with "Authorized domains" section of instructions

Version: master-head (7/12/19)
What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):

Try to set up Google Auth
When you get to Step 2 under "Authorized domains" and copy the FQDN to clipboard and then paste into "OAuth consent screen" you'll notice a message like this:

Result:
This is more or less okay -- Google UI accepted our FQDN and just trimmed the rest off the front. It would be nice, if the UI could do this somehow instead. This way user will copy domain and suffix only and paste in the and the Google UI won't complain in this section.

Note, this is a nice-to-have for v2.3; it could help reduce user confusion here. But if it's not a simple fix I recommend considering for post-v2.3 only.

Or just for 2.3, in the note in Rancher UI that says "Authorized domain must be fqdn", we can add that it has to be a top domain?

I think in this issue I was wondering if we can actually modify UI so it can make this determination for us. If the UI could do this without any significant effort that would be great. Should show proper URI and copy to clipboard correctly as well.
Alternatively, if this is not easy, we can close this issue and use this instead for simple changes to en-us translation key %authPage.googleoauth.notAuthenticated.ul.li2.helperText% : https://github.com/rancher/rancher/issues/21511


Node: Renamed preprocess category to augment

Changes:

Renamed preprocess category to augment
Updated descriptions of node categories in node_types.drawio.svg
Removed incorrect return of img arrow in yolo_demo.drawio.svg

Thanks, it has been updated.


Chapter 12 - Edit Invoice, changing invoice status

When I change only the invoice status and nothing else in the "Edit Invoice" section it doesn't update on the main table. Possible solution adding noStore() to the async function updateInvoice() in actions.ts ?

Hey @impuls666, I'm sorry I haven't been able to reproduce this. Do you have a reproduction?
One thing to make sure you are doing is invoking revalidatePath in your action.

I can reproduce it, mainly when the status is pending and wanna change it to paid
https://dashhboard-app.vercel.app/dashboard/invoices
added the revalidatePath in action and noStore in data file
I am working on chapter 15

I experienced this as well, but it wasn't just status. It was caching everything. Adding noStore() fixed the issue.

Thank for checking it,
I fixed the issue, it was related to next-auth. I should add the secret environment variable.
NEXTAUTH_SECRET
https://next-auth.js.org/configuration/nextjs#secret
I added noStore to fetchFilteredInvoices, but still face the issue

sorry for late reply, it's in the chapter 12 :
looks like the function:  "export async function updateInvoice..."  in  file "/app/lib/actions.ts" has no "noStore();" therefore it keeps cached data, but it is fixed in chapter 14 since the file is changed almost completly :)

noStore in the data file when fetching the data. not in action.
https://nextjs.org/docs/app/api-reference/functions/unstable_noStore
so we have a post API for action call,  something like
https://dashhboard-app.vercel.app/dashboard/invoices/5d12aebf-cc98-458b-9dbb-89d2301ff61b/edit
and in the request header Cache-Control is set to no-cache

Closing this one as stale, but please open a new issue if you are still having trouble here. Thank you!


etlas cheatsheet shows wrong command

At https://eta-lang.org/docs/cheatsheets/etlas-cheatsheet an alternative to etlas --version is given as etlas -v. The latter command does not work:
~$ etlas -v
etlas: unrecognised command: -v (try --help)

@justjoheinz Thanks for pointing out. There was a minor typo in the cheatsheet.
The correct command is etlas --v, which should be updated on the docs now.
So closing this one.


Avoid multiple bootstraps

I want to implement an application that automatically does the redirect and the login for the user. Currently Angular gets bootstrapped twice. Once at the beginning and once after the redirect.
I wanted to ask if there is a possibility to avoid multiple bootstraps? Maybe by using a similar approach like Silent Refresh?

I think there is no such feature built into the library. You'd have to customize things in your app, which is not complex, though not trivial either. I don't know of any guidance or example of this setup though.
However, I would not worry about it either. Typically, you would have a "remember me" option in your IDS. On startup, I suggest trying a silent refresh before redirecting a user at all. Since that'll usually succeed, Angular will only be bootstrapped once (except for the very first login).

Hoping my previous comment provided enough guidance. Let us know (here, or in a fresh issue) if there's still any open points. Closing for now.


TSP, TCGC common layer, adopt SdkNullableType

pay attention to union A | B | null case.
Link https://github.com/Azure/typespec-azure/pull/870/files

complete in https://github.com/Azure/autorest.java/pull/2816


A sample lambda is created when enabling cloud-api

Hi,
Good day.
Why is a sampleCloudApi function created? Can it be renamed? And if it is removed it still stays in the folder.
$ awsmobile cloud-api enable

Adding lambda function code on
/Users/thejj/work/angular/projects/testing/awsmobilejs/backend/cloud-api/sampleLambda/
...

To test the api from the command line (after awsmobile push) use this commands
awsmobile cloud-api invoke sampleCloudApi <method> /items [init]

Regards.

Hi,
When you enable cloud-api on your project like you did. awsmobile-cli creates a sample function so you can test your api against that function. Is an starting point to create your own functions on  serverless express.
awsmobile-cli is not removing the folder in purpose so wont lose your code accidentally.
If you run awsmobile cloud-api enable -p (if you dont have that feature enabled) or awsmobile cloud-api configure (in case you have and select create new api) you can configure the function name that will create a directory with the same name.


Aurora started up and crashed

What are you experiencing an issue with?

[x] Aurora
[ ] Aurora supported game, (Fill in the game)
[ ] Aurora Wrapper
[ ] Aurora Profile
[ ] Aurora supported device, (Fill in problematic devices)
[ ] Aurora Scripts
[ ] Aurora Updater
[ ] Aurora Lighting issue
[ ] Other, (Fill in another issue here)

What kind of an issue is it?

[x] Crash
[ ] Performance problems
[ ] Visual bug
[ ] Localization issue
[ ] Enhancement suggestion
[ ] Device issue
[ ] Other, (Fill in another type of issue here)

Expected behavior:
Aurora start with Windows normally.
Actual behavior:
This window appeared

Aurora has stopped working
Aurora fatally crashed. Please report the follow to author:
System.NullReferenceException: Object reference not set to an instance of an object.
at Aurora.Profiles.Application.LoadSettings(Type settingsType)
at Aurora.Profiles.Application.Initialize()
at Aurora.Profiles.LightingStateManager.Initialize()
at Aurora.Program.Main(String[] args)

I press OK and open Aurora.exe in the folder and it start normally.
How often does this problem occur?
1/1 startup
Please describe the steps to reproduce this issue:
not sure.
What is the version of Aurora you are experiencing this issue with?

My version is 0.6.1 dev3
Does the previous version of Aurora have this issue?
I have used 0.6.0b and never seen this before
Please include any logs, screenshots, or files that are related to this issue:

log file : https://pastebin.com/EZbmXvpT

Also, update


Reduce coupeling between Http2FrameCodec and Http2Multiplex*

Motivation:
Http2MultiplexCodec and Http2MultiplexHandler had a very strong coupeling with Http2FrameCodec which we can reduce easily. The end-goal should be to have no cupeling at all.
Modifications:

Reduce cupeling by move some common logic to Http2CodecUtil
Move logic to check if a stream may have existed before to Http2FrameCodec
Use ArrayDeque as replacement for custom double-linked-list which makes the code a lot more readable
Use WindowUpdateFrame to signal consume bytes (just as users do when they use Http2FrameCodec directly)

Result:
Less coupleing and cleaner code.

@ejona86 PTAL... this is basically a followup of https://github.com/netty/netty/pull/9239

@netty-bot test this please

@netty-bot test this please

@netty-bot test this please


Unable to set local path to build from Fork

Hi,
I need to build from source of a specific branch. So I pulled to branch and tried to build it, but it looks like the path is not accepted:
$ XK6_K6_REPO="$PWD" xk6 build

2021/08/24 11:52:11 [INFO] Temporary folder: /tmp/buildenv_2021-08-24-1152.237197142

2021/08/24 11:52:11 [INFO] Writing main module: /tmp/buildenv_2021-08-24-1152.237197142/main.go

2021/08/24 11:52:11 [INFO] Initializing Go module

2021/08/24 11:52:11 [INFO] exec (timeout=10s): /home/jaunius/.gvm/gos/go1.16.6/bin/go mod init k6

go: creating new go.mod: module k6

go: to add module requirements and sums:

	go mod tidy

2021/08/24 11:52:11 [INFO] Pinning versions

2021/08/24 11:52:11 [INFO] exec (timeout=0s): /home/jaunius/.gvm/gos/go1.16.6/bin/go mod edit -require go.k6.io/k6@latest

2021/08/24 11:52:11 [INFO] exec (timeout=10s): /home/jaunius/.gvm/gos/go1.16.6/bin/go mod edit -replace
go.k6.io/k6=/home/jaunius/dev/builds/xk6/k6

go: errors parsing go.mod:

/tmp/buildenv_2021-08-24-1152.237197142/go.mod:5: require go.k6.io/k6: version "latest" invalid: must be of the form v1.2.3

2021/08/24 11:52:11 [INFO] Cleaning up temporary folder: /tmp/buildenv_2021-08-24-1152.237197142

2021/08/24 11:52:11 [FATAL] exit status 1

can you please try to run go install go.k6.io/xk6/cmd/xk6@latest and try again?

Thanks! That worked. Looks like I might have missed one step.

We had a bug last week you like didn't upgrade since then :).

Is there any way to build directly from repository fork instead of pulling it first locally?

Are you talking about a k6 fork or an extension fork ... I think in both case you can just give the fork "url" instead.

Apologies for the confusion, what I meant is a specific branch. Like this:
--branch feature/SourceMaps https://github.com/grafana/k6.git

You can use K6_VERSION=whatever xk6 build ... but it doesn't work with branches with / in them, but it works with commit has so K6_VERSION=1065bcf xk6 build ... works .

Closing this as it appears to be fixed, but let us know if not @mjkapkan.


(TEST) Live branch auth check

PR Summary

Affected Files

Foo

Repository documentation and configuration (.git/.github/.vscode etc.)
Docs build files (.openpublishing.* and build scripts)
Docset configuration (docfx.json, mapping, bread, module folder)

Bar

Files in docs-conceptual

Cmdlet reference & about_ topics

Preview content
Version 7.2 content
Version 7.1 content
Version 7.0 content
Version 5.1 content

PR Checklist

[ ] I have read the contributors guide and followed the style and process guidelines
[ ] PR has a meaningful title
[ ] PR is targeted at the staging branch
[ ] All relevant versions updated
[ ] Includes content related to issues and PRs - see Closing issues using keywords.
[ ] This PR is ready to merge and is not Work in Progress. If the PR is work in progress,
please add the prefix WIP: or [WIP] to the beginning of the title and remove the prefix when
the PR is ready.

Expectations
To see our process for reviewing PRs, please read our editor's checklist and
process for managing pull requests in particular. Below is a brief,
high-level summary of what to expect, but our contributor guide has expanded details.
The docs team begins to review your PR if you request them to or if your PR
meets these conditions:

It is not a draft PR.
It does not have a WIP prefix in the title.
It passes validation and build steps.
It does not have any merge conflicts.
You have checked every box in the PR Checklist, indicating you have completed all
required steps and marked your PR as Ready to Merge.

You can always request a review at any stage in your authoring process, the docs team is here to
help! You do not need to submit a fully polished and finished draft; the docs team can help you get
content ready for merge.
While reviewing your PR, the docs team may make suggestions, write comments, and ask questions. When
all requirements are satisfied, the docs team marks your PR as Approved and merges it. Once your
PR is merged, it is included the next time the documentation is published. For this project, the
documentation is published daily at 3pm Pacific Standard Time (PST).

Expectations
To see our process for reviewing PRs, please read our editor's checklist and
process for managing pull requests in particular. Below is a brief,
high-level summary of what to expect, but our contributor guide has expanded details.
The docs team begins to review your PR if you request them to or if your PR
meets these conditions:

It is not a draft PR.
It does not have a WIP prefix in the title.
It passes validation and build steps.
It does not have any merge conflicts.
You have checked every box in the PR Checklist, indicating you have completed all
required steps and marked your PR as Ready to Merge.

You can always request a review at any stage in your authoring process, the docs team is here to
help! You do not need to submit a fully polished and finished draft; the docs team can help you get
content ready for merge.
While reviewing your PR, the docs team may make suggestions, write comments, and ask questions. When
all requirements are satisfied, the docs team marks your PR as Approved and merges it. Once your
PR is merged, it is included the next time the documentation is published. For this project, the
documentation is published daily at 3pm Pacific Standard Time (PST).

Expectations
To see our process for reviewing PRs, please read our editor's checklist and
process for managing pull requests in particular. Below is a brief,
high-level summary of what to expect, but our contributor guide has expanded details.
The docs team begins to review your PR if you request them to or if your PR
meets these conditions:

It is not a draft PR.
It does not have a WIP prefix in the title.
It passes validation and build steps.
It does not have any merge conflicts.
You have checked every box in the PR Checklist, indicating you have completed all
required steps and marked your PR as Ready to Merge.

You can always request a review at any stage in your authoring process, the docs team is here to
help! You do not need to submit a fully polished and finished draft; the docs team can help you get
content ready for merge.
While reviewing your PR, the docs team may make suggestions, write comments, and ask questions. When
all requirements are satisfied, the docs team marks your PR as Approved and merges it. Once your
PR is merged, it is included the next time the documentation is published. For this project, the
documentation is published daily at 3pm Pacific Standard Time (PST).

Expectations
To see our process for reviewing PRs, please read our editor's checklist and
process for managing pull requests in particular. Below is a brief,
high-level summary of what to expect, but our contributor guide has expanded details.
The docs team begins to review your PR if you request them to or if your PR
meets these conditions:

It is not a draft PR.
It does not have a WIP prefix in the title.
It passes validation and build steps.
It does not have any merge conflicts.
You have checked every box in the PR Checklist, indicating you have completed all
required steps and marked your PR as Ready to Merge.

You can always request a review at any stage in your authoring process, the docs team is here to
help! You do not need to submit a fully polished and finished draft; the docs team can help you get
content ready for merge.
While reviewing your PR, the docs team may make suggestions, write comments, and ask questions. When
all requirements are satisfied, the docs team marks your PR as Approved and merges it. Once your
PR is merged, it is included the next time the documentation is published. For this project, the
documentation is published daily at 3pm Pacific Standard Time (PST).

Expectations
To see our process for reviewing PRs, please read our editor's checklist and
process for managing pull requests in particular. Below is a brief,
high-level summary of what to expect, but our contributor guide has expanded details.
The docs team begins to review your PR if you request them to or if your PR
meets these conditions:

It is not a draft PR.
It does not have a WIP prefix in the title.
It passes validation and build steps.
It does not have any merge conflicts.
You have checked every box in the PR Checklist, indicating you have completed all
required steps and marked your PR as Ready to Merge.

You can always request a review at any stage in your authoring process, the docs team is here to
help! You do not need to submit a fully polished and finished draft; the docs team can help you get
content ready for merge.
While reviewing your PR, the docs team may make suggestions, write comments, and ask questions. When
all requirements are satisfied, the docs team marks your PR as Approved and merges it. Once your
PR is merged, it is included the next time the documentation is published. For this project, the
documentation is published daily at 3pm Pacific Standard Time (PST).

Expectations
Thanks for your submission! Here's a quick note to provide you with some context for what to expect
from the docs team and the process now that you've submitted a PR. Even if you've contributed to
this repo before, we strongly suggest reading this information; it might have changed since you last
read it.
To see our process for reviewing PRs, please read our editor's checklist and
process for managing pull requests in particular. Below is a brief,
high-level summary of what to expect, but our contributor guide has expanded details.
The docs team begins to review your PR if you request them to or if your PR
meets these conditions:

It is not a draft PR.
It does not have a WIP prefix in the title.
It passes validation and build steps.
It does not have any merge conflicts.
You have checked every box in the PR Checklist, indicating you have completed all
required steps and marked your PR as Ready to Merge.

You can always request a review at any stage in your authoring process, the docs team is here to
help! You do not need to submit a fully polished and finished draft; the docs team can help you get
content ready for merge.
While reviewing your PR, the docs team may make suggestions, write comments, and ask questions. When
all requirements are satisfied, the docs team marks your PR as Approved and merges it. Once your
PR is merged, it is included the next time the documentation is published. For this project, the
documentation is published daily at 3 p.m. Pacific Standard Time (PST).


Fix map access in order

Fixes https://github.com/querydsl/querydsl/issues/1624

Could you also add a test case that hits these lines?

Test coverage should be improved now.

Looks good to me.

Looks good.


fr translation hotfix

What
fr translation hotfix

Codecov Report

Merging #2270 (b6af66a) into develop (2ea0da3) will decrease coverage by 1.15%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           develop   #2270      +/-   ##
==========================================
- Coverage     8.86%   7.70%   -1.16%
==========================================
  Files          161     181      +20
  Lines         6623    9227    +2604
==========================================
+ Hits           587     711     +124
- Misses        6036    8516    +2480

Impacted Files
Coverage Δ

...kages/smooth_app/lib/widgets/attribute_button.dart
0.00% <0.00%> (-92.00%)
:arrow_down:

...s/smooth_app/lib/data_models/user_preferences.dart
8.73% <0.00%> (-23.57%)
:arrow_down:

packages/smooth_app/lib/themes/smooth_theme.dart
60.00% <0.00%> (-22.98%)
:arrow_down:

...p/lib/generic_lib/dialogs/smooth_alert_dialog.dart
19.23% <0.00%> (-14.98%)
:arrow_down:

...mooth_app/lib/data_models/product_preferences.dart
26.47% <0.00%> (-4.96%)
:arrow_down:

.../smooth_app/lib/pages/onboarding/welcome_page.dart
0.00% <0.00%> (-3.13%)
:arrow_down:

.../smooth_app/lib/pages/onboarding/scan_example.dart
0.00% <0.00%> (-2.28%)
:arrow_down:

packages/smooth_app/lib/main.dart
15.74% <0.00%> (-2.16%)
:arrow_down:

...s/smooth_app/lib/pages/onboarding/next_button.dart
2.22% <0.00%> (-1.78%)
:arrow_down:

...p/lib/pages/onboarding/consent_analytics_page.dart
0.00% <0.00%> (-1.57%)
:arrow_down:

... and 169 more

Continue to review full report at Codecov.

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


Improvement/upgrade dependencies

Anyone going to merge this? It's been a year!

Anyone going to merge this? It's been a year!


Unable to connect

The problem
Logger: homeassistant.config_entries
Source: custom_components/asusrouter/bridge.py:246
Integration: AsusRouter (documentation, issues)
First occurred: 18:38:07 (1 occurrences)
Last logged: 18:38:07
Error setting up entry <IP_ADDRESS> for asusrouter
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/asusrouter/connection.py", line 206, in async_request
json_body = await r.json()
File "/usr/src/homeassistant/homeassistant/helpers/aiohttp_client.py", line 52, in json
return await super().json(*args, loads=loads, **kwargs)
File "/usr/local/lib/python3.10/site-packages/aiohttp/client_reqrep.py", line 1119, in json
return loads(stripped.decode(encoding))
orjson.JSONDecodeError: unexpected end of data: line 2 column 18 (char 19)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/asusrouter/connection.py", line 114, in async_run_command
result = await self.async_request(command, endpoint, self._headers)
File "/usr/local/lib/python3.10/site-packages/asusrouter/connection.py", line 255, in async_request
json_body = parsers.pseudo_json(text=string_body, page=endpoint)
File "/usr/local/lib/python3.10/site-packages/asusrouter/util/parsers.py", line 550, in pseudo_json
return json.loads(data.encode().decode("utf-8-sig"))
File "/usr/local/lib/python3.10/json/init.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/local/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/local/lib/python3.10/json/decoder.py", line 353, in raw_decode
obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Expecting ',' delimiter: line 1 column 21 (char 20)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/asusrouter/connection.py", line 206, in async_request
json_body = await r.json()
File "/usr/src/homeassistant/homeassistant/helpers/aiohttp_client.py", line 52, in json
return await super().json(*args, loads=loads, **kwargs)
File "/usr/local/lib/python3.10/site-packages/aiohttp/client_reqrep.py", line 1119, in json
return loads(stripped.decode(encoding))
orjson.JSONDecodeError: unexpected end of data: line 2 column 18 (char 19)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 382, in async_setup
result = await component.async_setup_entry(hass, self)
File "/config/custom_components/asusrouter/init.py", line 24, in async_setup_entry
await router.setup()
File "/config/custom_components/asusrouter/router.py", line 731, in setup
await self.update_devices()
File "/config/custom_components/asusrouter/router.py", line 773, in update_devices
api_devices = await self.bridge.async_get_connected_devices()
File "/config/custom_components/asusrouter/bridge.py", line 263, in async_get_connected_devices
return await self._get_data(self.api.async_get_devices)
File "/config/custom_components/asusrouter/bridge.py", line 246, in _get_data
raw = await method()
File "/usr/local/lib/python3.10/site-packages/asusrouter/asusrouter.py", line 1037, in async_get_devices
await self.async_monitor_devices()
File "/usr/local/lib/python3.10/site-packages/asusrouter/asusrouter.py", line 816, in async_monitor_devices
data = await self.async_hook(AR_HOOK_DEVICES)
File "/usr/local/lib/python3.10/site-packages/asusrouter/asusrouter.py", line 363, in async_hook
raise ex
File "/usr/local/lib/python3.10/site-packages/asusrouter/asusrouter.py", line 359, in async_hook
result = await self.connection.async_run_command(
File "/usr/local/lib/python3.10/site-packages/asusrouter/connection.py", line 129, in async_run_command
return await self.async_run_command(
File "/usr/local/lib/python3.10/site-packages/asusrouter/connection.py", line 133, in async_run_command
raise ex
File "/usr/local/lib/python3.10/site-packages/asusrouter/connection.py", line 114, in async_run_command
result = await self.async_request(command, endpoint, self._headers)
File "/usr/local/lib/python3.10/site-packages/asusrouter/connection.py", line 255, in async_request
json_body = parsers.pseudo_json(text=string_body, page=endpoint)
File "/usr/local/lib/python3.10/site-packages/asusrouter/util/parsers.py", line 550, in pseudo_json
return json.loads(data.encode().decode("utf-8-sig"))
File "/usr/local/lib/python3.10/json/init.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/local/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/local/lib/python3.10/json/decoder.py", line 353, in raw_decode
obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Expecting ',' delimiter: line 1 column 21 (char 20)
Your device model
RT-AC86U
Firmware type
Stock
Firmware version
<IP_ADDRESS>.386_48260
Integration version with the issue
0.17.4
Method of the integration installation
HACS
What version and type of Home Assistant installation do you use
2023.1.4
Is there anything useful in the logs?
No response
Diagnostics information
No response
Additional information
No response

Reboot of the router resolved this issue

Hello,
Apparently, the API on your device has partially stuck and reported some incorrect data.
That's good, it was resolved with a reboot.
I'll use your logs to improve the integration to avoid such issues in the future. Thanks!

With the next release the backend library will be handling JSON errors by itself and users will not see the errors that you saw in your log. I am closing the issue. Thanks for your report!


Access to native pickers

Hello,
Is it possible to get access to the OSX/Windows native pickers source code?
I would like to add additional features, like keyboard navigation, and see if this is possible to also return the picker position, (to detect the display, and find the color profile for color conversion)
Thanks

The repo is at mockingbot/mb_colorpicker_desktop_native,
and the code kept minimal to just do the job.
If more additional features is needed and bloat is OK, you may check the previous Qt version at mockingbot/mb_colorpicker_desktop_qt.

Thanks, I agree this should stay minimal.
But the picker works in sRGB color space, which returns wrong results if your display is not in sRGB. So I believe an option/way to adjust that should be included.
I'll try to provide a PR in the next few weeks.

That's a problem we did not fully solve, it'll be great if you can work it out.
In our use case, mainly it's for getting color from browser. But last time we checked, the same CSS color in different browser displays different on screen. Maybe it's software related too, and there's so questions like this.

Yes, I'm well aware of this issue. Even with browsers you can get different color results: Firefox use sRGB color space, while Chrome and Safari use the display colorSpace.
And if, like me, you have 2 displays, with 2 diff. colorSpace2, and you test on multiple browsers, that's a nightmare to get accurate results :)
So it's not possible to fix this because the picker can't know what browser he's hovering, but at least I can try to make it possible for the user to choose the colorSpace for the picker to operate, or, to convert it to.


feature: Ability to output in json from ibc-setup

Overview
Inorder to use ts-relayer as a standalone relayer like hermes, it might make sense to have additional flag of --output <json | yaml | default> for all the queries with ibc-setup *.
Why
To be able to use jq with ibc-setup directly in bash instead of having to create a custom wrapper around the relayer. This will reduce the overhead of running the relayer with the current opperators as well (moving ts-relayer to more production usecases).
Will be a nice to have

I agree, this would be a nice improvement. I don't have time for this now, but happy to review and approve a pr

Cool, will try to get this done.

Hmmm... looks like there is no abstraction here, just some console.log stuff. Happy if you make all those lines in inc-setup if statements for two outputs. No need to auto-generate them from some meta-format.
Also, note the verbose/debug logs will always be the same. You can just turn down log level for scripts (via -q), so you only get the final (JSON) output.


Link with null attribute

Creating a Link with a null attribute, I get an InvalidArgumentException. I'm not 100% sure about it but I guess that having null attributes should be allowed in Hal links
Code to reproduce the issue
new Link('a', 'b', false, ['c' => null]);

Expected results
I would expect to get a Link with a c attribute with a null value
Actual results
An InvalidArgumentException with message Zend\\Expressive\\Hal\\Link expects the $value to be a PHP primitive or array of strings; received NULL is thrown

This repository has been closed and moved to mezzio/mezzio-hal; a new issue has been opened at https://github.com/mezzio/mezzio-hal/issues/6.


Multiple references to consecutive withParam in same workflow will fail.

Checklist

[x] Double-checked my configuration.
[x] Tested using the latest version.
[x] Used the Emissary executor.

Summary
When using withParam to read values from a json file written by previous steps, the workflow will fail to parse the json file upon the 3rd consecutive reference to withParam.
To emphasize the issue, i have written a test workflow with the 2nd task calling withParam (Task C) but not actually relying on any values from it.  This will cause the subsequent task (Task D) to fail at parsing its json input, but if withParam is commented out in task C the subsequent task D will parse the json input just fine.
What version are you running?
v3.3.9
Diagnostics
Paste the smallest workflow that reproduces the bug. We must be able to run the workflow.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: dag-diamond-jsontest-
  annotations:
    workflows.argoproj.io/description: |
      This is an example of of breaking withParam.
spec:
  serviceAccountName: workflow
  entrypoint: diamond
  templates:
  - name: diamond
    dag:
      tasks:
      - name: A
        template: writeJson
        arguments:
          parameters:
            - name: dummyv1
              value: "dv1"
            - name: dummyv2
              value: "dv2"
      - name: B
        arguments:
          parameters:
            - name: dummyv1
              value: "tmp"
            - name: dummyv2
              value: "tmp2"
            - name: jsonOut
              value: "{{item}}"
        withParam: "{{tasks.A.outputs.parameters.stepout}}"
        depends: "A"
        template: writeJson
      - name: C
        arguments:
          parameters:
            - name: dummyv1
              value: "tmp"
            - name: dummyv2
              value: "tmp2"
            - name: jsonOut
              value: "{{item}}"
        withParam: "{{tasks.B.outputs.parameters.stepout}}"
        depends: "B"
        template: writeJson
      - name: D
        arguments:
          parameters:
            - name: dummyv1
              value: "{{item.dummyv1}}"
            - name: dummyv2
              value: "{{item.dummyv2}}"
        withParam: "{{tasks.C.outputs.parameters.stepout}}"
        depends: "B && C"
        template: writeJson

  - name: writeJson
    inputs:
      parameters:
      - name: dummyv1
      - name: dummyv2
    script:
      image: python:alpine3.6
      command: [python]
      source: |
        import json
        args = [dict(dummyv1='one', dummyv2='two')]
        with open("/tmp/myfile.json", "w") as fd:
          tmp = json.dumps(args)
          fd.write(tmp)
    outputs:
      parameters:
      - name: stepout
        valueFrom:
          path: /tmp/myfile.json

STEP                                                      TEMPLATE   PODNAME                                DURATION  MESSAGE
 ⚠ dag-diamond-jsontest-kf7td                             diamond
 ├─✔ A                                                    writeJson  dag-diamond-jsontest-kf7td-1806111301  3s
 ├─✔ B(0:dummyv1:one,dummyv2:two)                         writeJson  dag-diamond-jsontest-kf7td-3988660372  3s
 ├─✔ C(0:[{\"dummyv1\": \"one\", \"dummyv2\": \"two\"}])  writeJson  dag-diamond-jsontest-kf7td-913068289   3s
 └─⚠ D                                                    writeJson                                                   failed to resolve {{item.dummyv1}}

# Logs from the workflow controller:
kubectl logs -n argo deploy/workflow-controller | grep ${workflow}
time="2022-08-30T23:35:01.305Z" level=info msg="Processing workflow" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:01.309Z" level=info msg="Updated phase  -> Running" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:01.309Z" level=info msg="DAG node dag-diamond-jsontest-kf7td initialized Running" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:01.309Z" level=info msg="All of node dag-diamond-jsontest-kf7td.A dependencies [] completed" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:01.309Z" level=info msg="Pod node dag-diamond-jsontest-kf7td-1806111301 initialized Pending" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:01.314Z" level=info msg="Created pod: dag-diamond-jsontest-kf7td.A (dag-diamond-jsontest-kf7td-1806111301)" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:01.314Z" level=info msg="TaskSet Reconciliation" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:01.314Z" level=info msg=reconcileAgentPod namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:01.318Z" level=info msg="Workflow update successful" namespace=default phase=Running resourceVersion=6712 workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:11.316Z" level=info msg="Processing workflow" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:11.316Z" level=info msg="Task-result reconciliation" namespace=default numObjs=0 workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:11.316Z" level=warning msg="workflow uses legacy/insecure pod patch, see https://argoproj.github.io/argo-workflows/workflow-rbac/" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:11.316Z" level=info msg="node changed" new.message= new.phase=Succeeded new.progress=0/1 nodeID=dag-diamond-jsontest-kf7td-1806111301 old.message= old.phase=Pending old.progress=0/1
time="2022-08-30T23:35:11.318Z" level=info msg="TaskGroup node dag-diamond-jsontest-kf7td-1755778444 initialized Running (message: )" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:11.318Z" level=info msg="All of node dag-diamond-jsontest-kf7td.B(0:dummyv1:one,dummyv2:two) dependencies [A] completed" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:11.318Z" level=info msg="Pod node dag-diamond-jsontest-kf7td-3988660372 initialized Pending" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:11.327Z" level=info msg="Created pod: dag-diamond-jsontest-kf7td.B(0:dummyv1:one,dummyv2:two) (dag-diamond-jsontest-kf7td-3988660372)" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:11.327Z" level=info msg="TaskSet Reconciliation" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:11.327Z" level=info msg=reconcileAgentPod namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:11.330Z" level=info msg="Workflow update successful" namespace=default phase=Running resourceVersion=6744 workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:11.336Z" level=info msg="cleaning up pod" action=labelPodCompleted key=default/dag-diamond-jsontest-kf7td-1806111301/labelPodCompleted
time="2022-08-30T23:35:21.329Z" level=info msg="Processing workflow" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:21.329Z" level=info msg="Task-result reconciliation" namespace=default numObjs=0 workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:21.329Z" level=warning msg="workflow uses legacy/insecure pod patch, see https://argoproj.github.io/argo-workflows/workflow-rbac/" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:21.330Z" level=info msg="node changed" new.message= new.phase=Succeeded new.progress=0/1 nodeID=dag-diamond-jsontest-kf7td-3988660372 old.message= old.phase=Pending old.progress=0/1
time="2022-08-30T23:35:21.331Z" level=info msg="node dag-diamond-jsontest-kf7td-1755778444 phase Running -> Succeeded" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:21.331Z" level=info msg="node dag-diamond-jsontest-kf7td-1755778444 finished: 2022-08-30 23:35:21.33152398 +0000 UTC" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:21.332Z" level=info msg="TaskGroup node dag-diamond-jsontest-kf7td-1772556063 initialized Running (message: )" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:21.332Z" level=info msg="All of node dag-diamond-jsontest-kf7td.C(0:[{\\\"dummyv1\\\": \\\"one\\\", \\\"dummyv2\\\": \\\"two\\\"}]) dependencies [B] completed" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:21.332Z" level=info msg="Pod node dag-diamond-jsontest-kf7td-913068289 initialized Pending" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:21.341Z" level=info msg="Created pod: dag-diamond-jsontest-kf7td.C(0:[{\\\"dummyv1\\\": \\\"one\\\", \\\"dummyv2\\\": \\\"two\\\"}]) (dag-diamond-jsontest-kf7td-913068289)" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:21.341Z" level=info msg="TaskSet Reconciliation" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:21.341Z" level=info msg=reconcileAgentPod namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:21.344Z" level=info msg="Workflow update successful" namespace=default phase=Running resourceVersion=6782 workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:21.350Z" level=info msg="cleaning up pod" action=labelPodCompleted key=default/dag-diamond-jsontest-kf7td-3988660372/labelPodCompleted
time="2022-08-30T23:35:31.343Z" level=info msg="Processing workflow" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.343Z" level=info msg="Task-result reconciliation" namespace=default numObjs=0 workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.343Z" level=warning msg="workflow uses legacy/insecure pod patch, see https://argoproj.github.io/argo-workflows/workflow-rbac/" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.343Z" level=info msg="node changed" new.message= new.phase=Succeeded new.progress=0/1 nodeID=dag-diamond-jsontest-kf7td-913068289 old.message= old.phase=Pending old.progress=0/1
time="2022-08-30T23:35:31.345Z" level=info msg="node dag-diamond-jsontest-kf7td-1772556063 phase Running -> Succeeded" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.345Z" level=info msg="node dag-diamond-jsontest-kf7td-1772556063 finished: 2022-08-30 23:35:31.345323089 +0000 UTC" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.345Z" level=info msg="Skipped node dag-diamond-jsontest-kf7td-1722223206 initialized Error (message: failed to resolve {{item.dummyv2}})" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.346Z" level=info msg="Outbound nodes of dag-diamond-jsontest-kf7td set to [dag-diamond-jsontest-kf7td-1722223206]" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.346Z" level=info msg="node dag-diamond-jsontest-kf7td phase Running -> Error" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.346Z" level=info msg="node dag-diamond-jsontest-kf7td finished: 2022-08-30 23:35:31.346203587 +0000 UTC" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.346Z" level=info msg="Checking daemoned children of dag-diamond-jsontest-kf7td" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.346Z" level=info msg="TaskSet Reconciliation" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.346Z" level=info msg=reconcileAgentPod namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.346Z" level=info msg="Updated phase Running -> Error" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.346Z" level=info msg="Marking workflow completed" namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.346Z" level=info msg="Checking daemoned children of " namespace=default workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.352Z" level=info msg="cleaning up pod" action=deletePod key=default/dag-diamond-jsontest-kf7td-1340600742-agent/deletePod
time="2022-08-30T23:35:31.381Z" level=info msg="Workflow update successful" namespace=default phase=Error resourceVersion=6821 workflow=dag-diamond-jsontest-kf7td
time="2022-08-30T23:35:31.393Z" level=info msg="cleaning up pod" action=labelPodCompleted key=default/dag-diamond-jsontest-kf7td-913068289/labelPodCompleted

# If the workflow's pods have not been created, you can skip the rest of the diagnostics.

# The workflow's pods that are problematic:
kubectl get pod -o yaml -l workflows.argoproj.io/workflow=${workflow},workflow.argoproj.io/phase!=Succeeded

# Logs from in your workflow's wait container, something like:
kubectl logs -c wait -l workflows.argoproj.io/workflow=${workflow},workflow.argoproj.io/phase!=Succeeded

Here is an example i meant for how commenting out one of the withParams for task C will now permit this workflow to complete for task D.  Even though it should have changed nothing for task D as far as I understand it
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: dag-diamond-jsontest-
  annotations:
    workflows.argoproj.io/description: |
      This is an example of of breaking withParam.
spec:
  serviceAccountName: workflow
  entrypoint: diamond
  templates:
  - name: diamond
    dag:
      tasks:
      - name: A
        template: writeJson
        arguments:
          parameters:
            - name: dummyv1
              value: "dv1"
            - name: dummyv2
              value: "dv2"
      - name: B
        arguments:
          parameters:
            - name: dummyv1
              value: "tmp"
            - name: dummyv2
              value: "tmp2"
            - name: jsonOut
              value: "{{item}}"
        withParam: "{{tasks.A.outputs.parameters.stepout}}"
        depends: "A"
        template: writeJson
      - name: C
        arguments:
          parameters:
            - name: dummyv1
              value: "tmp"
            - name: dummyv2
              value: "tmp2"
            - name: jsonOut
              value: "{{item}}"
#        withParam: "{{tasks.B.outputs.parameters.stepout}}"
        depends: "B"
        template: writeJson
      - name: D
        arguments:
          parameters:
            - name: dummyv1
              value: "{{item.dummyv1}}"
            - name: dummyv2
              value: "{{item.dummyv2}}"
        withParam: "{{tasks.C.outputs.parameters.stepout}}"
        depends: "B && C"
        template: writeJson

  - name: writeJson
    inputs:
      parameters:
      - name: dummyv1
      - name: dummyv2
    script:
      image: python:alpine3.6
      command: [python]
      source: |
        import json
        args = [dict(dummyv1='one', dummyv2='two')]
        with open("/tmp/myfile.json", "w") as fd:
          tmp = json.dumps(args)
          fd.write(tmp)
    outputs:
      parameters:
      - name: stepout
        valueFrom:
          path: /tmp/myfile.json

STEP                               TEMPLATE   PODNAME                                DURATION  MESSAGE
 ✔ dag-diamond-jsontest-nklct      diamond
 ├─✔ A                             writeJson  dag-diamond-jsontest-nklct-3272336441  4s
 ├─✔ B(0:dummyv1:one,dummyv2:two)  writeJson  dag-diamond-jsontest-nklct-2037240488  4s
 ├─✔ C                             writeJson  dag-diamond-jsontest-nklct-3238781203  4s
 └─✔ D(0:dummyv1:one,dummyv2:two)  writeJson  dag-diamond-jsontest-nklct-3224523118  4s

As far as I can tell reading the docs I never came across a section that seemed to imply there was a limitation on how many times you could reference using a json file as input and reading it via withParams within a single workflow

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

I had to slightly change your example to fix some other bugs that came up. But I was able to get this to work on 6b086368f6480a2de5e2d43eec73514de0ad01ac
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: dag-diamond-jsontest-
  annotations:
    workflows.argoproj.io/description: |
      This is an example of of breaking withParam.
spec:
  entrypoint: diamond
  templates:
  - name: diamond
    dag:
      tasks:
      - name: a
        template: write-json
        arguments:
          parameters:
            - name: dummyv1
              value: "dv1"
            - name: dummyv2
              value: "dv2"
      - name: b
        arguments:
          parameters:
            - name: dummyv1
              value: "tmp"
            - name: dummyv2
              value: "tmp2"
            - name: jsonOut
              value: "{{item}}"
        withParam: "{{tasks.a.outputs.parameters.stepout}}"
        depends: "a"
        template: write-json
      - name: c
        arguments:
          parameters:
            - name: dummyv1
              value: "tmp"
            - name: dummyv2
              value: "tmp2"
            - name: jsonOut
              value: "{{item}}"
        withParam: "{{tasks.b.outputs.parameters.stepout}}"
        depends: "b"
        template: write-json
      - name: d
        arguments:
          parameters:
            - name: dummyv1
              value: "tmp"
            - name: dummyv2
              value: "tmp2"
            - name: jsonOut
              value: "{{item}}"
        withParam: "{{tasks.c.outputs.parameters.stepout}}"
        depends: "b && c"
        template: write-json

  - name: write-json
    inputs:
      parameters:
      - name: dummyv1
      - name: dummyv2
    script:
      image: python:alpine3.6
      command: [python]
      source: |
        import json
        args = [dict(dummyv1='one', dummyv2='two')]
        with open("/tmp/myfile.json", "w") as fd:
          tmp = json.dumps(args)
          fd.write(tmp)
    outputs:
      parameters:
      - name: stepout
        valueFrom:
          path: /tmp/myfile.json

v3.4.3 was released yesterday. @AlanD88 are you able to test and confirm on latest for us? Thanks

@caelan-io sorry things have been a bit hectic for me, i'll get a chance to test this out this week and report back.

@isubasinghe @caelan-io Sorry it took a bit, was able to test locally.  Looks to work fine now.

Fantastic! All good, and thanks a lot for confirming for us, @AlanD88. That's really helpful. We'll close this issue as fixed in v3.4.3.

@caelan-io This needs to be reopened.   I work in an air gapped environment, so when I tested this, i started up a session on my home computer and tested and just copied @isubasinghe template to do the quick test again.  When my internal system at work got updated v3.4.3 and I attempted to retest our workflow design I noticed this issue was actually still occurring.  Looking back through the template @isubasinghe modified, I noticed they actually removed the logic from step D that was demonstrating the issue where on the 3rd attempt reading dynamic input, it will no longer correctly parse a json input artifact so you can't do key access on the contents like you normally should be able to.
The point of step D was to demonstrate key access failure.
The step from my original template
      - name: D         arguments:           parameters:             - name: dummyv1               value: "{{item.dummyv1}}"             - name: dummyv2               value: "{{item.dummyv2}}"         withParam: "{{tasks.C.outputs.parameters.stepout}}"         depends: "B && C"         template: writeJson
Where as the template that was tested to demonstrate it had been fixed
      - name: d         arguments:           parameters:             - name: dummyv1               value: "tmp"             - name: dummyv2               value: "tmp2"             - name: jsonOut               value: "{{item}}"         withParam: "{{tasks.c.outputs.parameters.stepout}}"         depends: "b && c"         template: write-json

Thanks for checking on this for me @AlanD88, I will re-open this in that case. I can confirm that actually using the values from step c does cause the issue to reappear.

https://github.com/isubasinghe/argo-workflows/blob/multiple-references-to-consecutive/output.txt

Any update on this issue?


github copilot sign in

Type: Bug
hi there vs code
often when one starts up vs code, copilot (and other github dependent ext's) are not signed in, and to get the sign in process to trigger and work properly, one needs to go bacck and forth re opening vs code. seems to be happening to my colleauges also
cheers
nels
VS Code version: Code 1.76.2 (ee2b180d582a7f601fa6ecfdad8d9fd269ab1884, 2023-03-14T17:53:46.528Z)
OS version: Darwin arm64 22.6.0
Modes:
Sandboxed: No
Extensions (42)

Extension
Author (truncated)
Version

better-comments
aar
3.0.2

vscode-django
bat
1.10.0

docs-view
bie
0.0.11

jsonviewer
cci
1.4.0

githistory
don
0.6.20

python-environment-manager
don
1.0.4

python-extension-pack
don
1.7.0

gitlens
eam
13.5.0

prettier-vscode
esb
10.1.0

code-runner
for
0.12.0

copilot
Git
1.105.350

copilot-labs
Git
0.14.884

vscode-github-actions
git
0.26.1

vscode-pull-request-github
Git
0.60.0

global-config
Gru
0.0.16

todo-tree
Gru
0.0.226

nbpreviewer
jit
1.2.2

jsonhero-vscode
JSO
0.1.4

vsc-python-indent
Kev
1.18.0

autopep8
ms-
2023.6.0

gather
ms-
2022.3.2

isort
ms-
2023.10.1

python
ms-
2023.4.1

vscode-pylance
ms-
2023.5.30

jupyter
ms-
2023.2.1200692131

jupyter-keymap
ms-
1.1.0

jupyter-renderers
ms-
1.0.15

vscode-jupyter-cell-tags
ms-
0.1.8

vscode-jupyter-powertoys
ms-
0.0.6

vscode-jupyter-slideshow
ms-
0.1.5

remote-ssh
ms-
0.102.0

remote-ssh-edit
ms-
0.86.0

makefile-tools
ms-
0.7.0

remote-explorer
ms-
0.4.0

vsliveshare
ms-
1.0.5883

autodocstring
njp
0.6.1

vscode-print
pdc
0.11.15

material-icon-theme
PKi
4.29.0

intellicode-api-usage-examples
Vis
0.2.7

vscodeintellicode
Vis
1.2.30

jinja
who
0.0.8

code-debuger
wow
0.1.2

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.81.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

/duplicate of #190949

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


Expose constructors with a defaulted cache

Right now all of our examples and test code uses a default &mut FilesystemResourceCache for loading, as it only handles a single map. It would be wise to expose a loading method that doesn't take in a cache and another one that does (with a _cached postfix) as it would confuse new users less and would result in less boilerplate for small applications and whatnot.

Since I'm not sure about providing an easy way to load files without caching tilesets, might it help to provide a "factory object", like a MapLoader struct that would wrap the cache and possibly other stuff we'd add in the future?
let mut loader = tiled::Loader::new();
let map = loader.load_map_file(map_path).unwrap();

Or, since we allow providing a custom cache:
let mut cache = CustomResourceCache::new();
let mut loader = tiled::Loader::new_with_cache(cache);
let map = loader.load_map_file(map_path).unwrap();

No no, there's no need. We could just construct a default cache internally from the "non-cached" function, and pass it into the cached function.

My main point was to simplify things for the user by moving the exposed loading API out of the Map and Tileset structs, into an object that can internally hold the cache, such that the user doesn't need to pass a cache around.

I don't know. The loader would need to internally keep track of an Option<T> which should verify that T: ResourceCache and it'd make things more complex from the typing point of view. IMO it's not worth the cost.

I don't know. The loader would need to internally keep track of an Option<T> which should verify that T: ResourceCache and it'd make things more complex from the typing point of view. IMO it's not worth the cost.

No need for Option, because there would always be a resource cache. If somebody really wants to disable caching, a non-caching implementation could be used.

Plus, instead of juggling the cache around, you'd be passing the loader. Same story.

Not really the same, because the loader doesn't necessarily need to be passed around. You brought up this issue because of the ResourceCache verbosity in all our tests and examples, in none of which we'd need to pass this loader around.
I'm not really sure what the plan is, but I'm just weary of providing a convenient Map::parse_file that internally constructs a cache, because it would set a bad example. It also makes the approach we would want to encourage even more verbose.

No need for Option, because there would always be a resource cache.

I'm just weary of providing a convenient Map::parse_file that internally constructs a cache, because it would set a bad example.

Well, don't both approaches internally construct a cache?

One thing to mention: The cache doesn't necessarily have to pose overhead if we create a "NoopResourceCache" of sorts that just does nothing on insert and get. We'd have to mention in the ResourceCache docs that insert is not actually guaranteed to insert the object though.

Well, don't both approaches internally construct a cache?

Yes, but if Map::parse_file does it internally it's much more likely a user might end up reconstructing a cache every time, than when they need to instantiate a Loader each time. In second case reusing the loader is the more natural thing to do.

The cache doesn't necessarily have to pose overhead if we create a "NoopResourceCache" of sorts that just does nothing on insert and get. We'd have to mention in the ResourceCache docs that insert is not actually guaranteed to insert the object though.

I guess it's not a good idea, especially with support for object templates coming eventually.

Okay, I see your point now. Will consider it. There are both pros and cons to each approach. The main con of my approach is that it's not obvious that the _cached version should be used for extra performance. The con of the loader approach is that it is more verbose, requires an extra type and it is not straightforward that map and tileset construction is done in an external type rather than from the types themselves.

We could provide a convenient Map::parse_file_with_temp_cache instead. :-)
I'm also a little worried about the explosion of variations, once we'd add support for the JSON format (functions to load json with or without cache, for maps, tilesets, templates...), and then functions that don't take file names directly but some reader, and maybe async variations eventually. It quickly starts to add up.

We could provide a convenient Map::parse_file_with_temp_cache instead. :-)

That looks better, and will require less changes. But it is maybe a bit too verbose. How about parse_file_uncached along with parse_file_cached?

I'm also a little worried about the explosion of variations, once we'd add support for the JSON format (functions to load json with or without cache, for maps, tilesets, templates...), and then functions that don't take file names directly but some reader, and maybe async variations eventually. It quickly starts to add up.

Regardless of the approach that we take, this will be a problem in any of them. We can figure out a solution once we see that things are getting out of hand.

That looks better, and will require less changes. But it is maybe a bit too verbose. How about parse_file_uncached along with parse_file_cached?

I think uncached suggest there is no cache, even though there is a temporary one. And cached makes the desired approach needlessly more verbose (it's already clear that a cache is provided, since it goes in as a parameter), and Map::parse_file_cached suggests that the map file is somehow cached, even though that is not the case.

The Loader idea does look very good now that I've thought about it carefully. The main issue that I had with it is it seemed redundant being able to just place methods in Map/Tileset instead, but it makes much more sense once we insert JSON and other formats into the picture. A TMX/TSX/JSONLoader can offload all the parsing methods from the actual datatypes into a separate module and also fix the paths issue along with it. It looks great this way.
P.S. Sorry if i seem extremely dense at times, I tend to prioritize reply speed over thought :p

A TMX/TSX/JSONLoader can offload all the parsing methods from the actual datatypes into a separate module and also fix the paths issue along with it. It looks great this way.

I'm glad you're seeing the loader approach in a more positive light. I'm unsure however, whether it makes sense to have different loaders for different formats (or even different data types, as with TMX and TSX). If it comes to the cache, at least, it is format-agnostic so we don't need a separate cache for each format.

P.S. Sorry if i seem extremely dense at times, I tend to prioritize reply speed over thought :p

It's no problem. I just think sometimes a quick chat or even video call might be better than typing comments then. They have too much overhead for this. :-)


[Cleanliness] [Easy] Make TVM leak-sanitizer and Wnon-virtual-dtor clean.

This is a minor set of commits to make TVM leak-sanitizer and Wnon-virtual-dtor clean. These are:

Stop leaking the llvm::TargetMachine instance (Target::createTargetMachine returns a raw pointer with owning semantics, so the caller is responsible for free'ing it). Instead, it is now owned by the LLVMModule instance.
Leak the Manager::Global singleton, instead of deleting it at program exit. This stops LSAN complaining about the leaked Registry* instances in Manager::fmap.
Add virtual destructors to runtime::DSLAPI and codegen::CodeGenSourceBase, to avoid LLVM complaining when -Wnon-virtual-dtor is passed (I think this is a useful flag to enable in CI as well).

After these commits, TVM built with e.g. -fsanitize=leak raises no errors on ./tests/scripts/task_cpp_unittest.sh.

Thanks @ajtulloch ! This is now merged

Thanks @tqchen!


Release 0.2.0

PR-Codex overview
This PR focuses on restructuring the mail configuration and service classes, introducing MailTemplate and MailServiceProperties.
Detailed summary

Moved mail configuration classes to mail package
Introduced MailTemplate for email templates
Added MailServiceProperties for mail service configuration
Refactored MailParameters to use String type
Updated MailServiceImpl to use MailTemplate

The following files were skipped due to too many changes: src/main/java/io/github/ilyalisov/mail/service/MailServiceImpl.java, README.md

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@rultor release tag is 0.2.0

@rultor release tag is 0.2.0

@ilyalisov OK, I will release it now. Please check the progress here

@rultor release tag is 0.2.0

@ilyalisov Done! FYI, the full log is here (took me 11min)


Disable support self healing passive

Created by: MaxwellJung

mentioned in merge request ow1_emulator_backup!62

moved from ow1_emulator_backup#720


Replace the ID of the generated connection profile with the one through edit connection

Fixes #10405

Coverage increased (+0.04%) to 33.95% when pulling 7e6a31a9aa62f92cb2c15788d803a42a8fa6fb52 on amir/editConnection2/dontMakeNewConnectionProfile into abdd9af93130df71f2789d6793ed3f23700d0d45 on master.


Remove dependency management from blueprint and address other inconsistencies in package.json

https://github.com/ciena-frost/ember-frost-file-picker/issues/58 MUST be completed before this issue.
* remove from blueprints and make dependency
    * ember-frost-core

* remove from devDependency and make dependency
    * ember-prop-types
    * ember-spread

* update ember-prop-types to ^5.0.1
* update ember-spread to ^3.0.2

* check whether these are specifically needed or not and remove if not, otherwise move to dependencies
    * ember-computed-decorators
    * ember-concurrency
    * ember-elsewhere
    * ember-truth-helpers

JIRA: FROST-587

https://github.com/ciena-frost/ember-frost-object-browser/issues/149 MUST be resolved before this issue can be addressed.  Some of the individual tasks may be able to be worked on before the completion of the dependent issue.  If doing so indicate which tasks have been completed by checking them off in the list below, as well as adding a comment to this issue indicating the name of the branch you have pushed to this repo so that work can completed once the dependent task has been addressed.

Tasks that have the text "(verified)" after them are ones that have either already been tested or are known to work.  This does not mean that you should not still be cautious but you likely don't have to do as much research as you might initially be inclinded to.
None of the tasks make a determination of whether a dependency should be a dependency or devDependency UNLESS otherwise stated.  Even then it is prudent to confirm this indicator.
All dependencies should float to ^ unless the directions in the tasks indicate otherwise.

NPM

[ ] determine whether ember-browserify is needed.  if so ^1.2.0 is latest
[ ] remove ember-cli-chai (verified) (note that ember-frost-test is now providing it at 0.4.3 so may encounter issues)
[ ] remove ember-cli-mocha (verified)
[ ] remove ember-sinon (verified) (note that ember-frost-test is now providing it at ^0.7.0 so may encounter issues)
[ ] remove ember-test-utils (verified) (note that ember-frost-test is now providing it at ^7.0.2 so will encounter linting failures)
[ ] remove sinon-chai
[ ] remove chai-jquery
[ ] upgrade ember-frost-test to latest version (verified)
[ ] remove ember-cli-template-lint (verified)
[ ] pin ember-cli-code-coverage to 0.3.12
[ ] verify ember-cli-code-coverage is tied into "npm run test" script
[ ] verify "tests/config/coverage.js" and not "config/coverage.js"
[ ] downgrade and pin ember-code-snippet to 1.7.0
[ ] pin ember-computed-decorators to 0.3.0 (is an upgrade)
[ ] upgrade ember-elsewhere to pinned 1.0.1
[ ] upgrade ember-cli-sass to pinned 7.1.1 (verified)
[ ] pin ember-hook to 1.4.2
[ ] determine whether ember-hook needs to be a dependency
[ ] downgrade and pin liquid-fire to 0.27.2
[ ] remove redux
[ ] remove redux-thunk
[ ] update or install ember-cli-frost-blueprints to ^5.0.0 (or whatever the latest release is) as devDependency
[ ] update ember-prop-types to ^6.0.0 (or whatever the latest release is)
[ ] update ember-spread to ^4.0.0 (or whatever the latest release is)
[ ] update ember-frost-core to ^5.0.0 (or whatever the latest release is)
[ ] determine dependencies vs devDependencies
[ ] check whether these are specifically needed or not and remove if not, otherwise move to dependencies

[ ] ember-computed-decorators
[ ] ember-concurrency
[ ] ember-elsewhere
[ ] ember-truth-helpers

BOWER

[ ] remove es6-promise
[ ] remove resemblejs
[ ] move Faker to devDependencies of bower.json
[ ] move pretender to devDependencies of bower.json


DNS-SD browse from Thread device does not return the same IPv6 address as avahi-browse

Describe the bug
When browsing for a service from a Thread device, the resolved IPv6 address does not match the one returned by avahi-browse.
To Reproduce

Git commit id: 3e138d3f5
IEEE 802.15.4 hardware platform: Nordic nrf52840
Build steps: Zephyr based firmware
Network topology: laptop publishing a _lwm2m._udp service, Raspberry Pi acting as the OTBR, nrf52840 custom board acting as the client Thread device

Expected behavior
When publishing the service with avahi-publish from my laptop:
avahi-publish -s "LwM2M Server" _lwm2m._udp 5685

Then browsing from the Thread device:
uart:~$ ot dns browse _lwm2m._udp.default.service.arpa
DNS browse response for _lwm2m._udp.default.service.arpa.
LwM2M Server
    Port:5685, Priority:0, Weight:0, TTL:10
    Host:Latitude-E7470-341.default.service.arpa.
    HostAddress:fd11:1111:1122:2222:363:13df:6445:f299 TTL:10
    TXT:[] TTL:10
Done

I am not getting the same address as the one I get from avahi-browse:
➜  ~ avahi-browse -rt _lwm2m._udp
+ wlp1s0 IPv6 LwM2M Server                                  _lwm2m._udp          local
+ wlp1s0 IPv4 LwM2M Server                                  _lwm2m._udp          local
+     lo IPv4 LwM2M Server                                  _lwm2m._udp          local
= wlp1s0 IPv6 LwM2M Server                                  _lwm2m._udp          local
   hostname = [Latitude-E7470-341.local]
   address = [fd11:1111:1122:2222:be95:c327:f96c:1ba8]
   port = [5685]
   txt = []
= wlp1s0 IPv4 LwM2M Server                                  _lwm2m._udp          local
   hostname = [Latitude-E7470-341.local]
   address = [<IP_ADDRESS>]
   port = [5685]
   txt = []
=     lo IPv4 LwM2M Server                                  _lwm2m._udp          local
   hostname = [Latitude-E7470-341.local]
   address = [<IP_ADDRESS>]
   port = [5685]
   txt = []

This is problematic since it seems like fd11:1111:1122:2222:be95:c327:f96c:1ba8 is the one I need to use to talk to the LwM2M server running on my laptop. If I use fd11:1111:1122:2222:363:13df:6445:f299 to connect from the Thread device, the reply I get comes back from fd11:1111:1122:2222:be95:c327:f96c:1ba8 and is therefore dropped (I'm guessing it's because it's not coming back from the IP the request was sent to).
Additional context
For reference here is the IPv6 situation on the laptop running the LwM2M server:
➜  ~ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fd11:1111:1122:2222:c064:d962:133b:b863/64 scope global temporary dynamic
       valid_lft 1704sec preferred_lft 1704sec
    inet6 fd11:1111:1122:2222:363:13df:6445:f299/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 1704sec preferred_lft 1704sec
    inet6 fd11:1111:1122:2222:be95:c327:f96c:1ba8/64 scope global temporary dynamic
       valid_lft 203sec preferred_lft 203sec
    inet6 fe80::a707:e0d5:ef2a:660a/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

And the logs on the border router associated with browsing from the Thread device:
Apr 18 23:34:21 otbr otbr-agent[686]: 5d.05:52:48.531 [I] DnssdServer---: ANSWER: TRANSACTION=0x4b1a, QUESTION=[_lwm2m._udp.default.service.arpa. 1 12], RCODE=3
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-DPROXY--: Subscribe: _lwm2m._udp.default.service.arpa.
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-MDNS----: Subscribe service ._lwm2m._udp (total 1)
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-MDNS----: DNSServiceBrowse _lwm2m._udp
Apr 18 23:34:21 otbr otbr-agent[686]: 5d.05:52:48.808 [I] MeshForwarder-: Received IPv6 UDP msg, len:91, chksum:772b, ecn:no, from:fea6db13e75a3766, sec:no, prio:net, rss:-81.0
Apr 18 23:34:21 otbr otbr-agent[686]: 5d.05:52:48.808 [I] MeshForwarder-:     src:[fe80:0:0:0:fca6:db13:e75a:3766]:19788
Apr 18 23:34:21 otbr otbr-agent[686]: 5d.05:52:48.808 [I] MeshForwarder-:     dst:[ff02:0:0:0:0:0:0:1]:19788
Apr 18 23:34:21 otbr otbr-agent[686]: 5d.05:52:48.808 [I] Mle-----------: Receive Advertisement (fe80:0:0:0:fca6:db13:e75a:3766,0x0400)
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-MDNS----: DNSServiceBrowse reply: add LwM2M Server._lwm2m._udp. inf 2, flags=2, error=0
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-MDNS----: DNSServiceResolve LwM2M Server _lwm2m._udp. inf 2
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-MDNS----: DNSServiceResolve reply: LwM2M\032Server._lwm2m._udp.local. host Latitude-E7470-341.local.:13590, TXT=1B inf 2, flags=0
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-MDNS----: DNSServiceGetAddrInfo Latitude-E7470-341.local. inf 2
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-MDNS----: DNSServiceGetAddrInfo reply: flags=1073741827, host=Latitude-E7470-341.local., sa_family=10, error=0
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-MDNS----: DNSServiceGetAddrInfo reply: address=fd11:1111:1122:2222:363:13df:6445:f299, ttl=120
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-MDNS----: Service _lwm2m._udp is resolved successfully: add LwM2M\032Server host Latitude-E7470-341.local. addresses 1
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-DPROXY--: Service discovered: _lwm2m._udp, instance LwM2M\032Server hostname Latitude-E7470-341.local. addresses 1 port 5685 priority 0 weight 0
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-DPROXY--: Unsubscribe: _lwm2m._udp.default.service.arpa.
Apr 18 23:34:21 otbr otbr-agent[686]: [INFO]-MDNS----: Unsubscribe service ._lwm2m._udp (left 0)
Apr 18 23:34:21 otbr otbr-agent[686]: 5d.05:52:48.937 [I] DnssdServer---: send DNS-SD reply: OK, RCODE=0

It looks like the OTBR does not forward all the information that is sent back by the laptop (running the LwM2M server). See wireshark screenshot below:

I would appreciate any help or suggestions! This might not be the way to do things properly (ultimately what I want is not to hardcode IP addresses in the firmware and have Thread devices discover the IP of the LwM2M server).

Currently Discovery Proxy supports only a single address I believe.

If I use fd11:1111:1122:2222:363:13df:6445:f299 to connect from the Thread device, the reply I get comes back from fd11:1111:1122:2222:be95:c327:f96c:1ba8 and is therefore dropped (I'm guessing it's because it's not coming back from the IP the request was sent to).

I assume this is UDP transport, right? It should be a bug of your server program if it's not sending the reply with the client address received in the request (likely it will be using "sendto()" or "sendmsg()" to send the reply, so need to make sure the destination address is set to the source address of the request).

@etiennedm , couple comments:

The service should only publish the IPv6 addresses that can be used to reach the service. It does not make sense to publish multiple IPv6 addresses, some of which do not work since the client will then need to potentially try a number of different IPv6 addresses.
If the application-layer protocol relies on address/port matching to correlate request and response messages, then it should also make sure to copy the Request's Source Address/Port into the Response's Destination Address/Port.

I do realize that the OpenThread stack on the device as well as the BR are more than likely behaving as expected, so I very much appreciate your help!
The fd11:1111:1122:2222::/64 prefix is advertised by the Raspberry Pi running the OTBR: I checked with Wireshark who is sending the RAs and they come from the Raspberry Pi link local address. It's also sending a route information with prefix fd11:22::/64 which matches with the prefix advertised on the Thread network. I did follow the codelab you pointed to @wgtdkp although I built it with the following options: WEB_GUI=1 NAT64=1 INFRA_IF_NAME=eth0 ./script/setup.
I'm a little wary of sharing a pcap file with potentially private information (and I wouldn't know what to redact anyway!). I can maybe apply appropriate filters if you tell me what you're interested in.
@jwhui regarding your comments:

Both addresses are actually valid as far as I know. The packets from the Thread device are properly received and processed, but the reply is not sent from the same IP as the one the query was received on. And I am not aware of a way to force the mDNS responder to only pick one address to be advertised. This would actually go against section 6.2 of the RFC 6762: https://www.rfc-editor.org/rfc/rfc6762#section-6.2.
This is something I need to look into. It seems it's not so obvious that the server knows from what IP the UDP packets are coming from. My understanding is that this is somehow more of an OS decision when you bind your server socket to all interfaces? I'm going to try to have the server bind to a specific IP (the one reported by the service discovery from the perspective of the Thread device).

Finally I think I might be reasoning the wrong way: I am not at all used to administrating servers, and it looks like the "server" way of doing things is to have a static IP. Using my laptop, which is really configured in various ways as a client is probably not such a great idea.

@etiennedm , when using sockets API, you can use sendto/recvfrom to access the sockaddr struct. The server not using the appropriate IPv6 Source Address in its responses seems like a bug.

Hi, so I've finally had some time to finish testing on this issue.
After reading some more about server/client applications and networking APIs, I completely agree with you @jwhui.
Digging into the configuration of the service I'm using, I found a way to bind to a specific IP address instead of any (https://thingsboard.io/docs/user-guide/install/config/ if anyone stumbles upon this issue later on). This takes care of the problem. The other solution, since it is running in a Docker container, was to map the port to a specific host IP, as documented here https://docs.docker.com/config/containers/container-networking/.
Thanks for your help! I'm closing this issue.


Feature Req : Enable Group Form validation

I would like to group validate model based on section of my form. I would like to have a optional checkmark on sections where the user has entered data.

Resolved in Commit #da50f3c59174fefca9b6fd6b4d8fbb63f7d59be8