build: Skip loading example data from configs in CI

SUMMARY
Don't load data for new example dashboards (via examples.load_from_configs) that are not required for e2e tests.
TEST PLAN
Cypress tests should pass.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

Codecov Report

Merging #12610 (4ec0810) into master (deebd6f) will decrease coverage by 3.31%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master   #12610      +/-   ##
==========================================
- Coverage   66.75%   63.43%   -3.32%
==========================================
  Files        1015      486     -529
  Lines       49633    29969   -19664
  Branches     4839        0    -4839
==========================================
- Hits        33133    19012   -14121
+ Misses      16377    10957    -5420
+ Partials      123        0     -123

Flag
Coverage Δ

cypress
?

javascript
?

python
63.43% <0.00%> (-0.53%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

superset/cli.py
33.58% <0.00%> (ø)

superset/db_engines/hive.py
0.00% <0.00%> (-85.72%)
:arrow_down:

superset/sql_validators/postgres.py
50.00% <0.00%> (-50.00%)
:arrow_down:

superset/db_engine_specs/hive.py
54.61% <0.00%> (-29.24%)
:arrow_down:

superset/db_engine_specs/presto.py
70.56% <0.00%> (-11.48%)
:arrow_down:

superset/db_engine_specs/postgres.py
93.42% <0.00%> (-2.64%)
:arrow_down:

superset/views/database/mixins.py
80.70% <0.00%> (-1.76%)
:arrow_down:

superset/models/core.py
88.04% <0.00%> (-0.82%)
:arrow_down:

superset/views/base_api.py
97.68% <0.00%> (-0.47%)
:arrow_down:

superset/reports/notifications/base.py
95.00% <0.00%> (-0.46%)
:arrow_down:

... and 543 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 deebd6f...4ec0810. Read the comment docs.

Codecov Report

Merging #12610 (4ec0810) into master (deebd6f) will decrease coverage by 3.31%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master   #12610      +/-   ##
==========================================
- Coverage   66.75%   63.43%   -3.32%
==========================================
  Files        1015      486     -529
  Lines       49633    29969   -19664
  Branches     4839        0    -4839
==========================================
- Hits        33133    19012   -14121
+ Misses      16377    10957    -5420
+ Partials      123        0     -123

Flag
Coverage Δ

cypress
?

javascript
?

python
63.43% <0.00%> (-0.53%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

superset/cli.py
33.58% <0.00%> (ø)

superset/db_engines/hive.py
0.00% <0.00%> (-85.72%)
:arrow_down:

superset/sql_validators/postgres.py
50.00% <0.00%> (-50.00%)
:arrow_down:

superset/db_engine_specs/hive.py
54.61% <0.00%> (-29.24%)
:arrow_down:

superset/db_engine_specs/presto.py
70.56% <0.00%> (-11.48%)
:arrow_down:

superset/db_engine_specs/postgres.py
93.42% <0.00%> (-2.64%)
:arrow_down:

superset/views/database/mixins.py
80.70% <0.00%> (-1.76%)
:arrow_down:

superset/models/core.py
88.04% <0.00%> (-0.82%)
:arrow_down:

superset/views/base_api.py
97.68% <0.00%> (-0.47%)
:arrow_down:

superset/reports/notifications/base.py
95.00% <0.00%> (-0.46%)
:arrow_down:

... and 543 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 deebd6f...4ec0810. Read the comment docs.

thank you so much for this PR, Rob! This is really helpful! 🙏

thank you so much for this PR, Rob! This is really helpful! 🙏

Shaves a minute or two off of the e2e test initialization.

Shaves a minute or two off of the e2e test initialization.


NovelCool not showing pages on some mangas

Source information
NovelCool 1.4.3
Source language
Spanish
Steps to reproduce
1: Search ongoing manga
2: Select a manga
3: open chapter
Expected behavior
Chapter is view as normal
Actual behavior
With some mangas (nothing in common that i can find between them) the next image is shown instead of each page:

Mihon/Tachiyomi version
TachiyomiJ2K 1.7.4
Android version
Android 12
Other details
This have happened for a while already, but as i said, it's hard to actually identify which mangas trigger this behavior.
The latest one that i've noticed is "La Presidenta Y La Chica M De Los Lirios." and checked with "La Historia Del Inesperado Encuentro Entre Una Chica Gal Y La Presidenta Del Consejo Estudiantil" but it happens with other titles as well
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 0.15.3.
[X] I have updated all installed extensions.
[X] I have tried the troubleshooting guide.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

all the ones you mentioned are working as expected. when this happens make sure to check the chapter in webview since they could have the images like that there


MacOS tests fail

When installed on a real MacOS environment the binary wheel works as expected.
The Github Actions however, fail.
See #13 and #12 for solutions attempts.

Problem disappeared using the current, not-deprecated-by-github, macOS 12 instead of macOS 10.15


Move utils module to a crate

Proposed changes
Move utils from tedge cli to separate crate to be usable by other tedge components.
Types of changes
What types of changes does your code introduce to thin-edge.io?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Improvement (general improvements like code refactorings that doesn't explicitly fix a bug or add any new functionality)
[ ] Documentation Update (if none of the other choices apply)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have read the CONTRIBUTING doc
[x] I have signed the CLA (in all commits with git commit -s)
[x] I ran cargo fmt as mentioned in CODING_GUIDELINES
[x] I used cargo clippy as mentioned in CODING_GUIDELINES
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

Codecov Report

Merging #358 (2aed523) into main (3262f02) will increase coverage by 0.06%.
The diff coverage is 45.45%.

@@            Coverage Diff             @@
##             main     #358      +/-   ##
==========================================
+ Coverage   68.64%   68.70%   +0.06%
==========================================
  Files          86       86
  Lines        4752     4749       -3
==========================================
+ Hits         3262     3263       +1
+ Misses       1490     1486       -4

Impacted Files
Coverage Δ

common/tedge_utils/src/paths.rs
64.00% <ø> (ø)

common/tedge_utils/src/signals.rs
0.00% <ø> (ø)

mapper/tedge_mapper/src/main.rs
0.00% <ø> (ø)

tedge/src/cli/certificate/error.rs
9.09% <ø> (ø)

tedge/src/cli/certificate/remove.rs
0.00% <ø> (ø)

tedge/src/cli/certificate/upload.rs
56.84% <0.00%> (ø)

tedge/src/cli/connect/command.rs
0.00% <0.00%> (ø)

tedge/src/cli/mqtt/subscribe.rs
0.00% <ø> (ø)

tedge/src/main.rs
0.00% <0.00%> (ø)

tedge/src/cli/certificate/create.rs
91.25% <100.00%> (ø)

... and 1 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 3262f02...2aed523. Read the comment docs.


update-scripts: move out of flake

update-scripts: move out of flake
ci/update: make steps optional

Closes #1827

Test are failing because we have an IFD still in test-modules-output.
When I get back to my laptop I'll drop disabling IFD from this PR and tackle it in another one unless the fix is simple and obvious.

I reviewed the changes and everything looks good to me.
Sure, we can leave the IFD part out for now and fix it in another PR.

@mergifyio queue


Shibboleth - Cancel is not getting the user out of the configuration when editing

What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):

Install Rancher 2.4 (commit id used: 83f9830a9)
Configure Shibboleth with OpenLDAP
Once Shibboleth is enabled click in Edit
Then Click Cancel

Result:

After clicking Cancel the user is not taken out of the Configuration page. I can still see the Edit configuration forms.

Other details that may be helpful:
Environment information

Rancher version: 2.4 master-head (02/19/2020) commit id: 83f9830a9
Installation option (single install/HA): single

Rancher version: 2.4 master-head (02/19/2020) commit id: e11d478
Validated this is now working

I can cancel during initial setup. Cancel redirects the user to the Auth providers page.
Cancel can also happen during Edit with and without OpenLDAP setting. During Edit there are two cancel buttons, both worked as expected redirecting the user to the Shibboleth Auth summary page.


fix: update security-services-proxy-certs test

This commit fixes two issues with the security-services-proxy-certs test:

The certificate and key were being written to the wrong directory. We now write them
to the SNAP_DATA directory of the snap creating them.
When we have the CA certs, we should not use the --insecure flag with cURL.

Signed-off-by: Siggi Skulason<EMAIL_ADDRESS>

Pushed a 2nd update which removes the unnecessary if statement
EDGECA_CERT=$(< $EDGECA_DIR/localhost.cert)

will exit (1) by itself if the file is not found, so we don't need to check first if the file exists.


[shims] Only define atomic shims in Swift's Clang Importer

Per #37, we currently happen to use some non-standard C atomics that only work in Clang; to prevent issues when this module gets compiled using other compilers, #ifdef out all the actual shims, leaving only the definitions for retain_n/release_n.
(For example, CMake builds the shims module using the system C compiler by default, which is usually GCC on Linux.)
Checklist

[X] I've read the Contribution Guidelines
[X] My contributions are licensed under the Swift license.
[X] I've followed the coding style of the rest of the project.
[ ] I've added tests covering all new code paths my change adds to the project (if appropriate).
[X] I've verified that my change does not break any existing tests.
[ ] I've updated the documentation if necessary.

@swift-ci test

@swift-ci test


🐛 : frame-processor/unavailable chrome debug.

What were you trying to do?

This code runs fine when Chrome debugging is Not enabled, but I'm encountering an error when attempting to Chrome debugging.

Reproduceable Code
"react-native-reanimated": "2.12.0",
"react-native-vision-camera": "2.15.4",
 "vision-camera-code-scanner": "0.2.0",

babel.config.js

module.exports = {
  presets: ['module:metro-react-native-babel-preset'],
  plugins: [
    [
      'react-native-reanimated/plugin',
      {
        globals: ['__scanCodes'],
      },
    ],
  ],
}

index.js

import 'react-native-reanimated'

 const [hasPermission, setHasPermission] = useState(false)
  const devices = useCameraDevices()
  const device = devices.back

  const [frameProcessor, barcodes] = useScanBarcodes([BarcodeFormat.ALL_FORMATS], {
    checkInverted: true,
  })

  const requestPermissions = async () => {
    const status = await Camera.requestCameraPermission()
    setHasPermission(status === 'authorized')
  }

  useEffect(() => {
    if (checkCameraPermission) requestPermissions()
  }, [])

    {device != null && hasPermission && isFocused && (
          <Camera
            device={device}
            isActive={true}
            frameProcessor={frameProcessor}
            frameProcessorFps={5}
            style={[styles.visionCamera, cameraStyle]}
            torch={torch ? 'on' : 'off'}
            {...cameraProps}
          />
      )}

What happened instead?

Relevant log output
No response
Device
Android/iOS
VisionCamera Version
2.15.4
Additional information

[ ] I am using Expo
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

You checked the "I have read the Troubleshooting Guide" box, but you did not read it.

come on man.


android: add a quick setting tile to enable / disable the VPN

One of these:

For example "quick connect" is the one from Proton VPN. Most importantly, I'd like to enable the VPN without having to sign in again. Once I am signed in, it would be nice to remember the token / credentials somewhere and just start / stop connlib.

Priority of this is low I guess, just recording it for completeness.

Closing as not needed. Firezone isn't a VPN that you need to turn on/off. Instead it offers an additional network interface and due to split tunneling, all other traffic goes through the other interfaces.


[BUG] IOS Build failing resolved.

Resolves #43
Solution:

To resolve this issue, I navigated to the directory ios/podfile.
In podfile, I uncommented the line ** platform :ios, '12.0'** to define a global platform for my project.
In podfile, I changed the platform version to 13.0 which supports the cloud_firestore_plugin.
After this I changed the directory to ios using cd ios command in terminal.
Finally, used pod install and pod repo update.
This resolved the issue.

@Jiggy9 Please review and merge under suitable labels.


Error: runuser: cannot set groups

Now this is a riddle. I know the issue is in my configuration. The error logs shows the Beeswax daemon attempting to start multiple times and then failing. I presume the call to start the Beeswax daemon calling on runuser. Is this correct?
When I run /etc/init.d/hue start from my user hduser I get the following:
/sbin/runuser: cannot set groups: Operation not permitted.
Starting hue: chown: changing ownership of /var/run/hue. Operation not permitted.

Assuming this was a problem with runuser wanting to set a user to hue and a group to hue I figured the right answer was the problem with runuser. So I set chmod u+s runuser.  Ah, this would solve the problem and away we would go. But at last here is the error

/sbin/runuser: runner may not be setuid: Operation not permitted.

So I changed runuser back and set every directory to chown -R hue:hue. But I am still failing on the runuser command? My reading of the man page suggest runuser is to be run by root. So I am looking for a life line. Have you seen this before? Can you give an explanation of what is happening and maybe I can figure out how to configure this correctly.

thanks

Also, let me add. I su - hue and ran /etc/init.d/hue start. I generated the same runuser error.

Feel free to ask on Hue user list http://groups.google.com/a/cloudera.org/group/hue-user for this type of question as this is not a bug and more people are on the mailing list
FYI you might need to update 'hue' to 'hduser':
https://github.com/cloudera/hue/blob/master/desktop/conf.dist/hue.ini#L46

Thanks, I will move the question over. Thanks.

Hey Thanks  Roman. This solves another problem. I will change this tomorrow. I posted my question about runuser to your group and to stack overflow. I am sure this will be a "duh!, when we figure it out."
Regards,
Will Dailey
"Seamen, with their inherent sense of honor, order, service, and discipline, should really be running the world."
-Anonymous

On Feb 18, 2015, at 6:44 PM, Romain Rigaux<EMAIL_ADDRESS>wrote:
Feel free to ask on Hue user list http://groups.google.com/a/cloudera.org/group/hue-user http://groups.google.com/a/cloudera.org/group/hue-user for this type of question as this is not a bug and more people are on the mailing list
FYI you might need to update 'hue' to 'hduser':
https://github.com/cloudera/hue/blob/master/desktop/conf.dist/hue.ini#L46 https://github.com/cloudera/hue/blob/master/desktop/conf.dist/hue.ini#L46
—
Reply to this email directly or view it on GitHub https://github.com/cloudera/hue/issues/152#issuecomment-74990740.


wordcount example throws an error

Participant reported this and I get the same error:
$ python source/plotcount.py data/isles.txt processed_data/isles.png

Traceback (most recent call last):
  File "/home/user/course/word-count/source/plotcount.py", line 31, in <module>
    counts = load_word_counts(input_file)
  File "/home/user/course/word-count/source/wordcount.py", line 37, in load_word_counts
    counts.append((fields[0], int(fields[1]), float(fields[2])))
ValueError: invalid literal for int() with base 10: 'JOURNEY'

I am not sure where in the lesson this was run but I think when we explored the word-count example.

Ah I see the mixup I think.


non-array @properties of a custom type do not get interpreted

If I declare a property like this:
@property [Array<FoobarClass>] foobars

The parsed response is correct, and includes an array of foobars. However...
@property [FoobarClass] just_one_foobar

is rendered as a string with the sample text "FoobarClass" and any attributes of FoobarClass, even those marked with @property attributes themselves are ignored.

From the looks of the specs/etc this just isn't supported yet. I'll add it post-spec2.

Should be resolved by #29.


Xtokens pallet didn't support the PriceForSiblingDelivery

Hi, when I try to induce the PriceForSiblingParachainDelivery into our parachain, the related extrinsic in xtoken's pallet cannot work because of NotHoldingFees. I guess the reason is the design of the Xtokens isn't compatible with the concept of PriceForSiblingDelivery. Do I understand right? If so, do you have any suggestions about that?
pub type PriceForSiblingParachainDelivery =
    ExponentialPrice<SelfReserveLocation, BaseDeliveryFee, TransactionByteFee, XcmpQueue>;

impl cumulus_pallet_xcmp_queue::Config for Runtime {
...
    type PriceForSiblingDelivery = PriceForSiblingParachainDelivery;
...
}

We kinda need XCM v5 with improved fee mechanism to make it work https://github.com/paritytech/polkadot-sdk/pull/5420
Also I would like to put xtokens on maintenance mode and people should migrate to xcm-pallet for the use cases that xtokens doesn't support.


Type error when attempting to use a Literal[True] with sa.and_()

Relevant block of code:
sa.and_(
    tb.c.VERSION == version,
    tb.c.ISIN.in_(isins) if isins is not None else True,
    tb.c.ISIN != None,  # pylint: disable=singleton-comparison
     b.c.DATE.in_(dates))
)

Error I get from pyright is:
error: Argument of type "ColumnElement[Boolean] | Literal[True]" cannot be assigned to parameter "clauses" of type "_CLE@BooleanClauseList" in function "and_"
    Type "ColumnElement[Boolean] | Literal[True]" cannot be assigned to type "ColumnElement[Boolean]"
      "Literal[True]" is incompatible with "ColumnElement[Boolean]" (reportGeneralTypeIssues)

Thanks for reporting,
You can use tb.c.ISIN.is_not(None) as an alternative.


Adopted Hyperparameter Tuning Process for WikiQA

Hi there,
The default configurations in examples/WikiQA/config have been optimized for the WikiQA dataset.
Now, I am however wondering which hyperparameters where included in the hyperparameter tuning so that eventually these parameter configurations were selected?

I am especially wondering why Duet uses the embed_glove_d50_norm embedding and why e.g. ANMM uses the embed.idf embedding and MatchPyramid uses the embed_glove_d300_norm embedding? Did you test every embedding for each model and selected the best-performing config?
Apart from that, I would also be curious to hear about the learning rate, optimizer and dropout rates that were considered in the hyperparameter tuning process?
Finally, there seem to be some differences between the architecture of Duet as specified in the original paper compared to your implementation (e.g. your implementation does not have a maxpool for the query, employs single instead of double hidden layers and seems to have smaller hidden layers (sized around 30 instead of 300)). Were these changes also part of the tuning process?

Looking forward to your reply, thanks in advance!

@avoidthevoid I was not able to answer questions related to the current version of Matchzoo, but I'd suggest you to take a look at matchzoo 2.0, it's under development, will be released in about 2 months.
Use matchzoo 2.0 api it's much easier for you to fine-tune the hyper-parameters, an example tutorial can be see at use matchzoo 2.0 to train a Deep Semantic Structured Model.

Hi @bwanglzu,
Thank you for your reply and great job on the work on MatchZoo 2.0! Due to time constraints, I will unfortunately have to stick to the 1.0 version for now. If any of your colleaugues would have the answer to the 3 questions, that would really be wonderful.
Anyhow, thanks for your time!

@avoidthevoid Thank you for your questions!
For Q1, it is not feasible to test the performance of every different embedding inputs. As you know, we have many different choices on the training algorithms (Skip-gram, CBOW or Glove), different embedding dimensions (100,200,300,...).  Thus it is not possible to try all combinations for this. But there are some common settings adopted by many previous IR/NLP papers, which also prove the effectiveness of these settings. For example, many papers use 300 as the embedding dimension and Glove_840_300d as the input pre-trained word embedding. You can refer to these settings when you run you own experiments to save some time/GPU costs.
For Q2, similar answers are also applicable for them. We tried to tune as many settings as possible when  we release the benchmark results on WikiQA. But there may still exist better hyper-parameters which are not covered by our experiments.  Feel free to explore more settings if you'd like and you have enough GPU resources/time. I suggest you to refer to some reported hyper-parameters in previous NLP/IR papers to save some time.
For Q3, it is possible. Maybe @faneshion @pl8787 can give you the answer for this question.
Thanks!

Hi @yangliuy,
Thank you for the elaborate answers, they are very helpful.
I will be on the outlook for the answer to Q3.
Thank you for your efforts!

Closed due to inactivity.


Removing Environment does not remove IP 10.42.X.X

Rancher Version: 1.1.4
Docker Version: 1.12.2 build bb80604
OS and where are the hosts located? Debian Jessie / bare metal
Setup Details: single node rancher
Environment Type: Cattle
Steps to Reproduce:

Add a service from catalog
Delete it
Delete environment

Results:
IP <IP_ADDRESS> still on docker0 interface
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
      link/ether 02:42:98:5f:a5:9f brd ff:ff:ff:ff:ff:ff
      inet <IP_ADDRESS>/16 scope global docker0
         valid_lft forever preferred_lft forever
      inet <IP_ADDRESS>/16 scope global docker0
         valid_lft forever preferred_lft forever
      inet6 fe80::42:98ff:fe5f:a59f/64 scope link
         valid_lft forever preferred_lft forever

Expected:
IP <IP_ADDRESS> removed from docker0 interface as it is not used anymore (and conflicts with my external network)

as a workaround you could remove the interface ip link del docker0 usually does the trick. Make sure to restart the docker daemon to recreate docker0.

As a workaround I removed only the IP <IP_ADDRESS> from the interface. Then you shouldn't restart anything :)
ip addr del <IP_ADDRESS> dev docker0

I don't really see a way to make this cleanup work, when we delete an environment (and the added hosts) they either get removed (cloud provided) or nothing is done. Best way to handle this is to mention it in the docs under "Removing hosts"? What do you think @aemneina ?

@superseb Sounds good, we can document this as a step under cleaning up hosts

https://github.com/rancher/rancher.github.io/pull/811


v2.1.0

[2.1.0] - 2024-05-13
Changed

Closed, unmerged PRs are now visually distinguished from merged PRs in the generated report.

Fixed

Updated the markdown parsing library which was causing the CLI to panic upon encountering malformed unordered lists.
Updated a number of dependencies to address vulnerabilities.

Much appreciated!


ERROR_DEVICE_LOST in vulkan backend (Windows Intel iGPU)

Short info header:

GFX version: wpgu rev = "012d08d" gfx-hal = "0.3.0", gfx-backend-vulkan = "0.3.0"
OS: Windows 10
GPU: Intel HD Graphics 2500

Here's a full trace log and backtrace for the error. Reproducing this is inconsistent, but it generally panics right at the start. So a few restarts usually triggers it.
The log says it's using the RTX 2080, but it shouldn't be. That GPU is completely dead right now, and I can't even boot Windows with a monitor plugged into it. I will remove the GPU and try it on the iGPU without any chance of conflict with the broken RTX... (This issue may be invalid.)

Well, it is running on RTX 2080 if it says so. Maybe that's part of the problem?
We need to see Vulkan validation output in case anything is screwed up by wgpu.

I removed the broken RTX and uninstalled the driver. My wgpu-based app no longer starts up:
thread 'main' panicked at 'Adapter does not support the requested max_bind_groups', C:\Users\jay\.cargo\git\checkouts\wgpu-53e70f8674b08dd4\78fbbba\wgpu-native\src\instance.rs:465:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: process didn't exit successfully: `target\release\examples\invaders.exe` (exit code: 101)

I am going to close this for now, since it seems invalid.

We are missing the max_bind_groups limit on some of the backends, including DX12...


Add disable write cache option to Surelog

Adds an option to Surelog that fixes the crash that Wenting reported.

@nmoroze do we need the cache? it seems like we should default to true?

If my reading of the docs is correct, then doing -nowritecache as the default is fine since we're supplying -nocache anyways. However, I think my understanding is pretty shaky and I was being wary of changing default behavior. I'm open to changing it and seeing what happens if you'd prefer that, though.


Composite Builds using Build Actions

This PR continues the work done by @Arthurm1 for composite-builds on #122, bringing in support for included builds, including dependency substitution using build actions.

@microsoft-github-policy-service agree

@Tanish-Ranjan Thanks for the PR.
I see you've used a Gradle BuildAction.  Was that so you don't have to query the source sets from GradleAPIConnector for each included build?
If that's the best route then you probably don't need the GradleIncludedBuild class as the model never returns any.
I think you'll still need to work out the project dependencies across included builds.  Maybe you can put that in the BuildAction as well.  I've slightly altered your new test to show what I mean.  This dependency check currently fails...
  @Test
  void testCompositeBuild2() {
    File projectDir = projectPath.resolve("composite-build-2").toFile();
    PreferenceManager preferenceManager = new PreferenceManager();
    preferenceManager.setPreferences(new Preferences());
    GradleApiConnector connector = new GradleApiConnector(preferenceManager);
    GradleSourceSets gradleSourceSets = connector.getGradleSourceSets(projectDir.toURI(), null);
    assertEquals(6, gradleSourceSets.getGradleSourceSets().size());
    GradleSourceSet mainApp = findSourceSet(gradleSourceSets, "app [main]");
    GradleSourceSet mainStringUtils = findSourceSet(gradleSourceSets, "string-utils [main]");
    GradleSourceSet mainNumberUtils = findSourceSet(gradleSourceSets, "number-utils [test]");
    assertHasBuildTargetDependency(mainApp, mainStringUtils);
    assertHasBuildTargetDependency(mainApp, mainNumberUtils);
  }

I see you've used a Gradle BuildAction. Was that so you don't have to query the source sets from GradleAPIConnector for each included build?

That's correct @Arthurm1. Gradle automatically manages substitution of dependencies. It didn't work previously in commit f2097d0 because Gradle was getting scoped to the project, loosing reference of the overall build and hence was not able to perform dependency substitutions from the included builds. With the help of Gradle TAPI's BuildAction we are maintaining the build scope while we fetch the GradleSourceSets.

I think you'll still need to work out the project dependencies across included builds.

Thanks for pointing it out. I'll look into it.

Big thanks to @Arthurm1 for the initial insights into the tooling API! Your guidance gave this PR a significant head start. Additionally, a huge thanks to all the gsoc mentors (@jdneo @donat @hegyibalint @reinsch82) who provided support throughout this process. Your help was invaluable in getting this completed so quickly.

Ok, so after some investigation, I found that the current solution has some problems:

See #169 and #170
For the sample project provided in https://github.com/microsoft/vscode-gradle/issues/1435, all the sourceset from two subproject will have the same project path :, this is actually not correct, we need to use the build tree path to differentiate them. Otherwise, the build target dependency resolution in BuildTargetManager might be wrong.


Add infallible integer conversions

Add From implementations that convert between the integer representation and the enum representation.

Hmm, whether an enum should implement From to and from its integer type is not something we should decide for everyone - after all, repr_visibility allows you to restrict access to the inner value. Instead, I think detecting a derive(FromPrimitive) and derive(ToPrimitive) would be best. Can you create FromPrimitive and ToPrimitive derive macros instead?


possible to support just ws instead wss

Regular ws:// support would be great e.g. in Intra-Net environments e.g. Electron apps etc can connect to NATS
via ws:// , for apps that are streaming lots of data it will be more performant than wss

This is a restriction put in the NATS Server, not the client library. The reason we force TLS is because WS clients are expected, or likely, to use bearer tokens, and without TLS is would be "easy" to steal them.

Agree, yes you have to configure with websocket block and provide TLS info , however in close corporate intranet e.g. in one of the use case i am trying out is publish real time market data to HTML5 apps running under Electron. e.g. volume is 1k msg size per record 1000 records and each record update 4 times per second.
WSS will spend considerable time in decrypting

Understood. My point is that the server is forcing use of TLS. Please create an issue against NATS Serve (https://github.com/nats-io/nats-server) asking to support non TLS websocket configuration, maybe with a flag such as "insecure: true" in the websocket config block to bypass the TLS requirement?

sounds good.
Thanks

I have updated the client to support WS connections. However, the support is in the current development version of the client, which means that it will affect any code you might have written.
To connect to ws://, the new client offers the ws option: {ws: true} will allow the client to connect to non-wss server..


EtherWeighted DLL doesn't download

Ether.WeightedSelector.dll doesn't download with PowerShell. Additional line needs to be added to script.

The PowerShell script updated.


Add Documentation how to manage antora specs

Background
We need a short documentation for other users how to manage antora specs.
Task
Add the following points to the README.MD (links to articles would also be ok):

[ ]  How to add New doc repos in aas-specs-antora Repo
[ ]  How doc repo must be structured for Antora
[ ]  How to manually trigger building of web docs in Github

Here is a draft:
Managing Antora Specs Documentation
This guide provides a brief overview of how to manage documentation repositories (Doku-Repos) for Antora specs, including adding new repositories, structuring them appropriately, and manually triggering web documentation updates on GitHub.
Adding New Documentation Repositories for Antora
To add new documentation repositories for use with Antora, follow these steps:

Create a New Repository: On GitHub, create a new repository to hold your AsciiDoc content. This repository will be integrated with Antora to generate your documentation site.

Configure Antora: In the antora-playbook.yml file of your documentation site generator, add the new repository under the content.sources section. Specify the url of your new repository and the branches to track.
content:
  sources:
    - url: https://github.com/<your-organization>/<new-repo-name>
      branches: [main]

Commit and Push: Save your changes to the antora-playbook.yml file, commit, and push them to your repository.

For detailed instructions, refer to Antora's official documentation on configuring content sources.
Structuring Documentation Repositories for Antora
An Antora documentation repository must be structured to include at least the following:

Modules Directory: Contains the documentation components, divided into multiple modules for organization.
Pages Directory: Within each module, a pages directory holds the AsciiDoc files (.adoc) containing your documentation content.
Nav.adoc File: A navigation file within each module directory to define the structure of your documentation in the generated site.

Example structure:
docs/
  modules/
    module-name/
      pages/
        index.adoc
      nav.adoc

For a comprehensive guide on structuring your documentation for Antora, see Antora's official documentation on directory structure.
Manually Triggering Web Documentation on GitHub
To manually trigger the generation and deployment of your web documentation on GitHub:

Navigate to Your Repository: Go to the GitHub repository where your documentation source or Antora playbook is hosted.

Access Actions Tab: Click on the "Actions" tab.

Run Workflow: Find the workflow responsible for generating and deploying your documentation (it may be named something like "Deploy Docs" or "Antora Publish"). Click on "Run workflow", select the branch you want to deploy from, and then click "Run workflow" again.

For more detailed steps or to set up a workflow if you haven't already, consult GitHub's documentation on manually triggering a workflow.

Addressed with https://github.com/rwth-iat/aas-specs-antora/commit/357b84b8b220589d32aa510da36b7197c32bb2b6.

When it comes to the document and folder structure etc., I think it would be easier to just continue using our orphan github branch, at least alongside with the upstream sources.
For example, there is a pull request to fix a problem in Part 5, where the cover page basically blocks navigation and breaks the website. So it takes some time until we push our fixes and changes upstream one by one.
Instead of that, I think we can fix everything in our orphan branch, and upstream can just copy from us the final result as a whole. They are e.g. interested in splitting the index files into several main segments. If they can just specify what to be split, we can easily implement everything as a whole in a more compact and integrated and a much quicker way in our orphan repository, and upstream can just have it from there, again as a complete whole.
Would this not be more desirable?
This may or may not be the right place to mention and disuss this topic. I chose here because we are doing the folder structure etc. documentation in this issue practically. So I think, if the aim is to help upstream with the folder structure, this might be a faster way than just providing them documentation, which we absolutely also do.

Since the download button is added, the superfluous links and text components are deleted from the readme file. Is there anything to imporve it further or should be close this issue?

The issue can be closed


fix(graphql): fix graphql.operation.name field

Which problem is this PR solving?

https://github.com/open-telemetry/opentelemetry-js-contrib/issues/705
https://github.com/open-telemetry/opentelemetry-js-contrib/issues/847

Short description of the changes

Change graphql.operation.name to send the GraphQL operation-name (a critical field for GraphQL o11y) instead of the GraphQL operation-type.
Continue to send the GraphQL operation-type as graphql.operation.type, since this is still useful for segmenting read queries from write mutations, etc.

Checklist

[x] Ran npm run test-all-versions for the edited package(s) on the latest commit if applicable.

@dyladan, might you be able to help move this PR out of its current state?

Hi @obecny 👋. You seem to be the last reviewer on the roster for this PR. Any chance you'd be able to take a look please?

Hi @obecny, it's been another week. Any chance you'd be able to look at this PR please?

@obecny is no longer a maintainer on the project. sorry for the confusion

he is still part of the approver group and the owner of the graphql instrumentation.

@obecny is no longer a maintainer on the project. sorry for the confusion

I see, thank you @dyladan. Do you know who would now be the right person to ping regarding getting this PR merged in that case?

he is still part of the approver group and the owner of the graphql instrumentation.

This makes sense too @Flarna 👍 , because he's showing as the last person I need an approval from before I can merge.

I am the right person :)

Thank you guys! 🙏


README installation instructions don't seem to work

I followed the installation instructions for creating a stand alone conda environment but was met with:
Traceback (most recent call last):
  File "/Users/dtmcdonald/miniconda3/envs/songbird_env/bin/songbird", line 8, in <module>
    from songbird.multinomial import MultRegression
  File "/Users/dtmcdonald/miniconda3/envs/songbird_env/lib/python3.7/site-packages/songbird/multinomial.py", line 3, in <module>
    from tensorflow.contrib.distributions import Multinomial, Normal
  File "/Users/dtmcdonald/miniconda3/envs/songbird_env/lib/python3.7/site-packages/tensorflow/__init__.py", line 50, in __getattr__
    module = self._load()
  File "/Users/dtmcdonald/miniconda3/envs/songbird_env/lib/python3.7/site-packages/tensorflow/__init__.py", line 44, in _load
    module = _importlib.import_module(self.__name__)
  File "/Users/dtmcdonald/miniconda3/envs/songbird_env/lib/python3.7/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "/Users/dtmcdonald/miniconda3/envs/songbird_env/lib/python3.7/site-packages/tensorflow_core/contrib/__init__.py", line 39, in <module>
    from tensorflow.contrib import compiler
  File "/Users/dtmcdonald/miniconda3/envs/songbird_env/lib/python3.7/site-packages/tensorflow_core/contrib/compiler/__init__.py", line 21, in <module>
    from tensorflow.contrib.compiler import jit
  File "/Users/dtmcdonald/miniconda3/envs/songbird_env/lib/python3.7/site-packages/tensorflow_core/contrib/compiler/__init__.py", line 22, in <module>
    from tensorflow.contrib.compiler import xla
  File "/Users/dtmcdonald/miniconda3/envs/songbird_env/lib/python3.7/site-packages/tensorflow_core/contrib/compiler/xla.py", line 22, in <module>
    from tensorflow.python.estimator import model_fn as model_fn_lib
  File "/Users/dtmcdonald/miniconda3/envs/songbird_env/lib/python3.7/site-packages/tensorflow_core/python/estimator/model_fn.py", line 26, in <module>
    from tensorflow_estimator.python.estimator import model_fn
  File "/Users/dtmcdonald/miniconda3/envs/songbird_env/lib/python3.7/site-packages/tensorflow_estimator/python/estimator/model_fn.py", line 29, in <module>
    from tensorflow.python.types import core
ModuleNotFoundError: No module named 'tensorflow.python.types'

I then tried to install tensorflow effectively as described in the CI configuration, (e.g. conda install "tensorflow >=1.15,<2") but the error did not change.

hmm, that is so weird.  I'm not able to reproduce this error with conda install songbird -c conda-forge.
What install command did you use?  And can you provide your tensorflow version (i.e. python -c 'import tensorflow; tensorflow.__version__')? And are you getting similar errors with pip install tensorflow<2; pip install songbird?

Thanks, @mortonjt! I ran the commands from the link below:
https://github.com/biocore/songbird#installation
...and then looked at .travis.yml to see how tensorflow was installed. Despite a successful execution of conda install "tensorflow >=1.15,<2", it seems that tensorflow was not installed. It looks like pip install "tensorflow<2 did work though

I still very confused why tensorflow<2 isn't conda installable ...
It is clearly hosted on conda : https://anaconda.org/anaconda/tensorflow
I wonder if there are some issues with the channels ...

Hi,
I was having the same problem. I followed the songbird installation instructions and kept getting the message:
"ImportError: cannot import name 'trace' from 'tensorflow.python.profiler"
When I tried pip install "tensorflow<2" (as suggested above), I got the following error message:
"ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
songbird 1.0.3 requires nose>=1.3.7, which is not installed."
I then tried "conda install nose" and now Songbird seems to be working
Hope this is useful


无法接收和发出图片

运行ding-dong-bot.py只是回复dong，并不会发出一张图片。试了很多种方法也无法获取到对方发来的图片。

Could you please share how can you solve your problem/issue because it might help others in the future?
Thanks.


🪲[Bug]: Website is not responsive

Describe the bug
The website is not responsive across all the devices. I would like to work on this. @Anishkagupta04 Please assign this to me under GSSoC'24.

Can you Please assign this to me?


Finalized files are not the right file

Finalized files default to MutualNDA.
May be a problem with the serviceurl or document.final ?

Nevermind. Resolved already.


[tde] Migrate IO plugin

This PR implements the IO plugin mechanism in dynamic embedding, where user can register her/his IO plugin by providing a dynamic library with symbol IO_type, IO_Initialize, IO_Finalize, IO_Push and IO_Pull included.
And the tests for the interfaces introduced in this PR will be added along with a example redis IO plugin in next PR. I split them so that the PR won't be too large.
Thank you for your time on reviewing this PR :)
cc @reyoung @colin2328

@divchenko Sorry for this late reply, we were experimenting with our inner PS to make sure the current plugin design could work with it. I have updated the code upon your review, could you take another look? Thank you！


[Suggestion] Add type hints

I think adding type hinting can improve the overall quality of rlberry, but it will be a huge work. What do you think ?

I think this is a good idea and we don't have to do everything at once, we could do something gradual

Do a PR that add type hint to the principal algorithms of rlberry (AgentManager, plot and eval functions, Base classes like Model and AgentWithSimplePolicy...).
Use typing in the new PR

On the other hand, I think for now improving the documentation should come first (in particular issue #188 and add some tutorials to populate the user guide), but this is just my opinion.

Duplicated from #15


Use random integers suffix for temporary file names

Previously, we used the timestamp to create temporary file names and this could lead to non-unique file names. This commit improves the generation of temporary directory names and reduces the chances of conflicting directory names.

Addresses the failure here.


Add Lisk Mainnet to the Superchain Registry

Adding a New Chain
This PR adds Lisk Mainnet to the registry.
Checklist

[x] I have declared the chain at the appropriate Superchain Level.
[ ] I have run just validate 1135 locally to ensure all local validation checks pass.
[x] I have run just codegen to ensure that the chainlist and other generated files are up-to-date and include my chain.

Additional Information
To enable the just add-chain and just codegen commands to function correctly, I had to make a few changes:

op-geth (config.go)

Adding Lisk Mainnet chain ID into the constants:
LiskMainnetChainID      = 1135
The same will eventually apply to Lisk Sepolia.

op-geth (superchain.go):

The Lisk Mainnet network has custom values for the following variables, necessitating a new case statement:

case LiskMainnetChainID:
    out.Optimism.EIP1559Elasticity = 20
    out.Optimism.EIP1559Denominator = 1000
    out.Optimism.EIP1559DenominatorCanyon = newUint64(1000)

The same will eventually apply to Lisk Sepolia.

check-genesis.go:

Currently, EIP1559DenominatorCanyon is hardcoded to 250, which does not align with Lisk Mainnet (and Sepolia).
For now, I have commented out these two lines.

Additionally, the just validate command also fails for some of the unit tests.

With all recent updates, changes inside Additional Information are not needed anymore to successfully execute just add-chain command.

With all recent updates, changes inside Additional Information are not needed anymore to successfully execute just add-chain command.

Excellent!

Hey @matjazv, can you please rebase this branch and rerun just codegen ?

Hey @matjazv, can you please rebase this branch and rerun just codegen ?

I've rebased the branch and reran just codegen and now everything seems to be fine.


Github Actions for Build Infrastructure

GitHub actions needs to execute a set of predefined U-CS steps like build, test, and publish.
It will check for an existing script, and execute it, if present, otherwise it will move on to the next step.

The GH Actions yml already handles this by looking for smoketest script.
Currently test is in the deployment script.
The target repository location is stored in an env var.
For release 0.2, the above build, test, and publish flow will be properly tied together.  For now, the basics of this ticket are implemented, but not completely orchestrated together.


fix for kafka namespace flag

The topic command was broken (only the publish verb was working).
This fixes that.
Also, I've renamed the flag so it clearer now (it would be possible to have kafka running in a different k8s namespace than the kubeless controller).

This fixes #114

this fixes #112

Tested. Merging

I actually feel strongly that the kafka and controller should be in the same namespace. Why wanting to split them ?

I do agree. Actually the flag name is changed just for not to be confused with the controller. When running kubeless install both controller and kafka are always deployed in the same namespace.


Extend make prepare for standalone modes

Extend the make prepare target to support standalone of OCR-D Controller and Kitodo.Production.

In other words: if Controller and/or Production is not managed by docker-compose here, at least support managing the access credentials and user data for the independent modules via the makefile.

We've done that, haven't we?
Or is there any way to get make-data usable for external/remote Kitodo.Production instances?


VisUI: VisDialog does not close

Hello,
i found a bug: the VisDialog does not close when hitting the close button for the second time. The first time works.
I attached a little example (txt, because github doesn't let me post java files...)
Just open & close the dialog 2 times. The second time it can't be closed.
Seems to be introduced in VisUI 1.1.0, 1.0.0 worked.
I'm using libGDX 1.9.3, running on Linux Mint.
DialogTester.java.txt

Thanks for reporting and providing actually runnable example. I fixed it but since you are reusing dialog this would suggest that you are using it for something complex. It's better to use VisWindow directly for complex dialogs. VisDialog comes from scene2d.ui and in my opinion isn't useful for anything complicated and its API is kinda bad. I'm actually thinking about removing it in some major new version.

Yes, i'm using this for all kinds of complex dialogs. Alright, then i'm going to switch to VisWindow.
Thanks for the quick fix!

No problem. I won't remove it anytime soon though, it's more like VisUI 2.0 thing so there is no need to hurry.


Geometry utility to deal with offsets, widths and lane connections

The current geometry implementations have several issues:

Geometry logic is scattered over various classes, using various local thresholds and number of points for a line.
CrossSectionElement forces the first and last line segment in the direction of the node. This is done with a point at 1/3rd along the way to the next shape point, or at most at a distance equal to the element width. This creates very inconsistent shapes between elements on one link.
Offset artefacts (see issue #70).
When translating a network format to OTS that has lane geometry defined, this needs to be translated to widths and offsets as CrossSectionElement cannot be specified with geometry directly.
CrossSectionElement offsets are used to fix what is in essence a shift of the link design line, purely because it is then desired to let a link design line start at the from node and end in the end node. This occurs especially at merges/diverges where link design lines that are e.g. on the right-hand side of a cross-section will not meet up otherwise. This can create complicated and strange situations, e.g. an arc link where all lanes shift from from negative to positive offset. Aa a result, none of the lanes is an arc, and the lane contours will not connect neatly to the previous or next link.
The way in which links are defined (arc, straight, clothoid) is not consistent. Only for Bezier is the node direction actually used. Only for arcs is offset used.

To overcome these issues the following principles are designed:

Geometry utils (one in ots-core and one in ots-road) will be the central places that define geometry logic.
All CrossSectionElement will simply receive a design line and shape. No internal (and obscure logic) will change this.
Nodes have a direction, that links and lanes need to obey.
Node direction is not strict for the links and lanes; the first and last line segments may deviate in their direction within bounds. (E.g. a circle arc may divide a 90° corner in 90 segments, causing the first and last segments to deviate from the node direction by 1°.)
Both design lines and edge lines need to start/stop on the line through the node, perpendicular to the node direction.
These start and end points need to at their offset on the perpendicular line. Note that this may cause slight narrowing of the first or last line segment.
Link design lines are somewhere within the width of a road cross section, although this is not strict.
Offset at link level is used to connect lanes appropriately where links merge or diverge. (For macroscopic purposes, this offset may be ignored.)
Offset of the entire cross-section on a link is used to connect successive links using road layouts with different locations of the link design line.
Offset of individual lanes and lines is used if this changes over the length of the link.

Rule 4 allows that shapes can be true to their design, and no awkward and complicating additional segments are required at the start and end.
Rules 5 and 6 make sure that lanes from connected links connect neatly.
The bounds of angle deviation in rule 4 are such that when the first/last point is placed on the perpendicular line through the node, at the correct offset, a clean line still results. The angle deviation may not be such that the first point in the inside of the bend at the node is placed beyond the second point due to an offset, e.g. taper lanes.

Quite a lot of changes have been made in a first big iteration to tackle the above issues.

CrossSectionElement, and its subclasses Lane, Stripe and Shoulder, now gets a OtsLine3d and OtsShape as center line and contour. These are no longer determined internally.
Hence, no additional points are added to the center line regarding node direction.
Also methods fixLateralOffset() and fixTightInnerCurve() have been removed.
Many constructors, with different offset and width combinations, have been removed.
In ots-core class ContinuousLine, and its subclasses ContinuousArc, ContinuousBezierCubic, ContinuousClothoid, ContinuousStraight and ContinuousPolyLine have been added. These classes define a design line continuously, and can be used to return a flattened OtsLine3d of itself, or an offset line. All these lines obey the start and end directions.
Bezier now has a method cubicControlPoints() that returns 4 control points using the regular logic of a shape factor and whether to use weighted points. This is used in ContinuousBezierCubic. Method Bn has been made package-private for the same reason.
Logic to determine a clothoid based on two directed points has been moved from Clothoid to ContinuousClothoid.
All demos, unit tests and xml files have been updated accordingly.

Added class FractionalLengthData which stores 1-dimensional data along the length of a curve. This class is used for variable offsets, and also delivered by LaneGeometryUtil to deliver center/left/right offsets. The class can return interpolated values.

Methods offset and flatten with input 'number of segments' or 'max deviation and anglehave been removed fromContinuousLine` and all subclasses.
A new interface Flattener has been introduced. It is input in two new methods in ContinuousLine and all subclasses:

flatten(Flattener)
flattenOffset(FractionalLengthData, Flattener)

Subclasses of ContinuousLine can implement these methods either using, or ignoring, the flattener. For example, ContinuousStraight is flattened to just two points. ContinuousBezierCubic implements the offset procedure of before, splitting the Bezier in C-shaped Bezier segments. These segments are then used to provide information to the flattener.
A Flattener expects input in the form of a FlattableLine. This has methods Point2d get(double fraction) and double getDirection(double fraction), for use in the various flattening procedures. Each ContinuousLine subclass that uses the flattener, must present itself as a FlattableLine. This occurs using light-weight anonymous classes that can find points and directions, accounting for a possible variable offset. In most cases this is straightforward, especially if the relevant information has been pre-calculated (e.g. for a Clothoid). In a few, it is more complex (Bezier offset).
There are 4 standard implementations of Flattener, defined as classes as they require specification of input:

Flattener.NumSegments based on a number of segments.
Flattener.MaxDeviation based on a maximum spatial deviation. This implements the procedure in Bezier in djutils.
Flattener.MaxAngle based on a maximum angle between the continuous line, and a resulting polyline segment.
Flattener.MaxDeviationAndAngle which combines the two above in a single procedure.


[bug]: https://hub.helm.sh shows not existing chart from incubator

https://hub.helm.sh/charts/incubator/artifactory

I believe it comes from here: https://github.com/helm/charts/tree/cd5cfc462126d8d3ae27eea5f97f343d69d158bf/incubator/artifactory, before it was moved to stable in https://github.com/helm/charts/commit/689cc8b6d816e2dfe2f72c59f296a2013bb9247c. We didn't have a good process for deprecating charts back end, so the incubator chart was just deleted instead of deprecated. To properly deprecate it, a PR would need to re-add the chart as it was in https://github.com/helm/charts/tree/cd5cfc462126d8d3ae27eea5f97f343d69d158bf/incubator/artifactory and deprecate it according to the process described in https://github.com/helm/charts/blob/master/PROCESSES.md#deprecating-a-chart.

ok, will do that tomorrow

@prydonius - I have created https://github.com/helm/charts/pull/9767. Should I fix the linting errors?

sorted, closing

thanks a lot!


Add support for expressions within template literals

Fixes #25

@rauchg ran a benchmark on this branch and it is slightly slower.
97.36 ops/sec ±3.30% (567 runs sampled)

while without expressions:
104 ops/sec ±1.32% (562 runs sampled)

Master
155 ops/sec ±1.39% (573 runs sampled)

PR
Without expressions:
143 ops/sec ±1.27% (565 runs sampled)

With expressions:
140 ops/sec ±1.71% (570 runs sampled)

ran on a MacBook Pro 2 GHz Intel Core i7, 8 GB 1600 MHz DDR3

🎉

:clap:

@rauchg
Running 'styled-jsx Babel transform' from ~/code/styled-jsx/benchmark/babel.js ...
  basic x 123 ops/sec ±6.70% (61 runs sampled)
  with expressions x 93.34 ops/sec ±11.77% (52 runs sampled)

Passed:
  'basic' is etalon
  'with expressions' at 1.32x slower

Ran on a MacBook Pro (Mid 2014), 2.6 GHz Intel Core i5, 8 GB 1600 MHz DDR3

Anything we can do to help get this merged?

Waiting on this :cookie:

@TuckerWhitehouse @aga5tya I'd like to understand why it's 30% slower, seems a bit much?
Also, @giuseppeg, what's the impact on an example that doesn't use expressions, before and after this patch?

@rauchg what would be acceptable performance?
I ran the benchmarks locally, and these are my results:
master
Babel transform x 150 ops/sec ±3.40% (572 runs sampled)
'babel' from ~/Sites/styled-jsx/benchmark/babel.js (passed: 1, failed: 0)
  Passed:
    'Babel transform' is etalon

expressions
Running 'styled-jsx Babel transform' from ~/Sites/styled-jsx/benchmark/babel.js ...
  basic x 144 ops/sec ±4.52% (75 runs sampled)
  with expressions x 140 ops/sec ±3.97% (70 runs sampled)
'styled-jsx Babel transform' from ~/Sites/styled-jsx/benchmark/babel.js (passed: 2, failed: 0)
  Passed:
    'basic' is etalon
    'with expressions' at 1.03x slower

Re-ran the benchmarks, and updated expressions to use a minimum of 500 samples.
master
Babel transform x 170 ops/sec ±1.50% (573 runs sampled)

expressions
basic x 168 ops/sec ±1.51% (567 runs sampled)
with expressions x 151 ops/sec ±1.32% (563 runs sampled)
  'with expressions' at 1.11x slower

Thanks @rauchg, and nice work @giuseppeg!


Revert "[usbdev] Fixes for I/O modes and expand their tests"

This reverts commit 66c509296798cdd9dbeba4deeb381d0cecf3b429.
 We'll need to have a closer look
what's going on there, but revert the change first to get CI latencies
back to normal.

The job execution times are too noisy to be sure that this commit is actually at fault, let's see how the CI run looks.

This revert brings the FPGA build time down from roughly 60 minutes to 25 minutes. In both cases the design violates timing (and has actually been doing so for quite a while), but the USB commit made things significantly worse.
Let's get this one merged to bring down CI latencies for everyone, and then look at the FPGA timing more closely in a follow-up.

Even before this commit I found some versions of Vivado taking a lot of memory and my machine spending most of its time swapping. >16GB IIRC.

I can confirm @mdhayter 's comment. I was doing quite a few CI runs and local FPGA builds yesterday - both before and after merging this PR. The whole thing seems to be non-determinstic. I suspect that a different PR merged on Friday or over the weekend actually causes the troubles.

For completeness, Vivado 2020.1 on my laptop does not show the excessive memory use I saw from earlier versions.


[Don't Submit] Minimal test case for reproducing duplicate echo replies

In this scenario, every echo request sent from ROUTER to BR will get two echo responses.
./script/test build_otbr_docker && THREAD_VERSION=1.2 VIRTUAL_TIME=0 REFERENCE_DEVICE=1  ./script/test build
sudo PACKET_VERIFICATION=1 VERBOSE=1 THREAD_VERSION=1.2 VIRTUAL_TIME=0 ./script/test cert_suite tests/scripts/thread-cert/test_ping.py

This PR is not designed for merging. I'll close it and leave the branch here.


py.test starts running tests in the virtualenv

When I use py.test as in the README it starts running tests in lib/python2.7/site-packages. The readme should at least explain you should qualify the py.test command.

This is actually a bug. Are you sure you're running the py.test defined by the virtualenv (bin/py.test)?
It is meant to work without any arguments and ignore the lib directory (see setup.cfg for the list of excluded folders).

Weird. I am using bin/py.test. It is using the version of pytest stored under lib/site-packages too. I'm on Python 2, and I installed cookiecutter from another virtualenv.

It happens both when I invoke through bin/py.test or when I activitate the virtualenv and do py.test. The version of py.test that gets installed is 2.9.1.

Can you try to rename setup.cfg into a pytest.ini file in the generated package? Seems like py.test sometimes does not pick up setup.cfg:
http://stackoverflow.com/questions/11117062/how-to-tell-py-test-to-skip-certain-directories

Tried that, still the same behavior. I really don't get why this isn't working either...

By the way, I think I prefer pytest.ini for this instead of setup.cfg, but perhaps you have a good reason to use setup.cfg instead.

I just went ahead and reinstalled it all, still the same behavior. What am I doing differently?

Aaah, wait! I'm on 64 bit Linux, and I have a lib64 in my virtualenv!

Yeah, that fixes it. You need to add lib64 to setup.cfg (or pytest.ini).

Cool, thanks!


How to change max target version?

Discussed in https://github.com/microsoft/WindowsAppSDK/discussions/1084

Originally posted by Jaiganeshkumaran July 18, 2021
I'm trying to reference a C++ Runtime Component project from a C# WinUI 3 app which targets the latest Insider SDK however I get this error while building the C# app: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2526,6): warning MSB3851: This project targets "Windows, Version=10.0.19041.0", but it is attempting to reference "C:\Users\jaiga\Desktop\source\OneToolkit\x64\Debug\OneToolkit\OneToolkit.winmd" targeting "UAP,Version=10.0.22000.0", which is invalid.
I checked the packaging project and it is set to 10.0.22000.0 but I can't find anything like that for the app project.

Hitting the same issue as Jaiganesh. In my case, there is a bug in older SDKs that prevents me from using them (microsoft/microsoft-ui-xaml#5828). So I have to use the 22000 SDK. However, I can't reference the 22000 SDK from C#:
1>C:\Program Files\dotnet\sdk\5.0.400\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(213,5): error NETSDK1140: 10.0.22000.0 is not a valid TargetPlatformVersion for Windows.

Specifying an older SDK on the C# side, results in a warning that should actually be an error: microsoft/CsWinRT#892
Tracking for the "make this cswinrt warning an error" is microsoft/CsWinRT#906

@Scottj1s

My workaround for the time being, is to use the older SDK (the one that has the MIDL bug), but point the build to use the midl.exe from the new SDK. Obviously I can't merge this in as-is, so for the time being I'm able to locally validate my code, but I can't check it in.
<Project>
  <PropertyGroup Condition="'$(SolutionName)'=='Microsoft.ReactNative.WindowsAppSDK'">
    <UseWinUI3>true</UseWinUI3>
    <!-- <WindowsTargetPlatformVersion>10.0.22000.0</WindowsTargetPlatformVersion> -->
    <WindowsTargetPlatformVersion>10.0.18362.0</WindowsTargetPlatformVersion>
    <!--
      ******** TODO *********
      Temporary workaround until the 22000 SDK is shipped
      We use WinAppSDK 1.0-experimental - this means certain types like xaml's Application are marked experimental
      There is a bug in older versions of MIDL where it doesn't understand [experimental] correctly
      This was fixed in the 22000 SDK.

      However, we can't use the 22000 because we don't have a TargetFramework for it, like net5.0-windows10.0.22000.168
      So: use the 18362 SDK, but use the 22000 midl.exe
    -->
    <MIDLToolPath>C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x64</MIDLToolPath>
  </PropertyGroup>
</Project>

To target the insider SDK TFM in a .NET 5 app, you need to set the UseWindowsSdkPreview property added in the .NET SDK 5.0.8 update.
More details here under Install the SDK Insider Preview.

thanks @manodasanW , I can confirm that setting these properties lets me reference the preview sdk targetframework!


APP-285: Update photo frame for android

@kaa-leeroy test this fully please

@kaa-leeroy test this fully please


Custom port doesn't work

I use dotenv and set my env variables in .env, setting something like CHROMELESS_CHROME_PORT=9223 in .env causes a ECONNREFUSED bug, since Chrome opens up in port 9223, but chromeless is still trying to communicate with it on port 9222. I noticed chrome-remote-interface has a default port 9222, and I'm guessing chromeless is not passing on port 9223 to chrome-remote-interface properly in order to communicate with chrome.
Trying like this:
chromeless = new Chromeless({ cdp: { port: 9223} });

Still struggling with this issue.
I'm currently able to launch Chromeless only with port 9222. If I change it , I always get:
Error: connect ECONNREFUSED <IP_ADDRESS>:9222
at Object.exports._errnoException (util.js:1050:11)
at exports._exceptionWithHostPort (util.js:1073:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1097:14)"
Here is my code:
`         const chrome = await chromeLauncher.launch({
port: 9223,
chromeFlags: [
'--window-size=600,715',
'--remote-debugging-port=9223',
'--disable-gpu',
]
});
     chromeless[id] = new Chromeless({
         launchChrome: false,
         cdp: {
             port: 9223
         }
     });`

I guess this is still an issue.
Are you able to backport the fixes from my PR regarding this?
https://github.com/graphcool/chromeless/pull/268
Just make these same changes as this commit https://github.com/graphcool/chromeless/pull/268/commits/475dd3e9988ff23ca2705e1a45c17b7bac1521e4 and you should be good to go.

Works like a charm !


Added type validation + tests. This resolves issue #80.

Pretty basic types validator passthrough.

Coverage decreased (-0.7%) to 99.321% when pulling 0d857936946f9c515b7d7187846cd71084d41b2b on brownstein:type-validator into d4c70af28314f375f45689c7115376a55b71dd7f on ansman:master.

At this point, I've adopted a json-schema compliant validator to meet my project's needs and am ceasing development on this branch. If 100% test coverage is a requirement for merge, I can close the PR.

@ansman I will open a separate PR that addresses this since @brownstein decided to close it.


chore: bdd-spring-1575896851 to 0.0.1

chore: Promote bdd-spring-1575896851 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Fix bug where you can't select a map at end of round

Fedoraware Version Date:
Config used:

Description:

Steps to reproduce:

[ ] I am able to consistently reproduce this error

Steps to reproduce the behavior:

Enable X
Do Y
Notice Z

Additional context

[ ] I have included the steps to reproduce to the best I am able to share.

What

Is this caused by the cheat or are you asking us to find out a way to fix valve's bug

my dumbass pressed enter on the title and accidentally posted the post without actually typing anything

oh ok, didn't see the original part, i mean yeah i could do that i guess

i'd rather know why you can't click on it in the first place tbh but buttons work too

i'd rather know why you can't click on it in the first place tbh but buttons work too

No clue, but it's been a bug for years. https://github.com/ValveSoftware/Source-1-Games/issues/2417

you can not undo your sins (i don't think they care)

CNextMapVotingDashboardState seems to be what's in charge of this though

would be super cool if there was a way to patch this bug
but I'd settle for just something in the GUI
Maybe you can have a panel pop up with three buttons to pick the map, and the panel only shows during the map voting period? so like hidden panel that only shows when a map vote is in progress

CNextMapVotingDashboardState::ShouldBeActve
good old valve "Actve"

You wouldn't happen to know what causes this to happen in the first place right?

You wouldn't happen to know what causes this to happen in the first place right?

not one clue nope
just happens randomly
Valve claimed to fix it in recent patch but it still happens

Also, putting this on hold for now, i've just compared everything from CNextMapVotingDashboardState in the dylibs from like april 2021 and from latest update and don't see any difference so i might not be looking in the right place

there are keybinds for it yknow...

https://github.com/OthmanAba/TeamFortress2/blob/1b81dded673d49adebf4d0958e52236ecc28a956/tf2_src/game/client/tf/vgui/tf_matchmaking_dashboard_next_map_voting.cpp#L150
Patching this line to InvalidateLayout( true, true); might fix the bug, since it'll cause a scheme reload (which does fix the issue when done manually through hud_reloadscheme).

:true:

I think we should let Valve handle this one


Add support for verbs to create url.

Currently when creating URLs via the Url helper or UrlManager, the intended verb is not used.
It should be possible to add an optional parameter to the URL creation routines. This would then be passed on to CUrlRule::createUrl, which will return false if the rule does not apply to the passed VERB.
Suppose you have URL rules that do this:
put to /cars/18  ---> CarsController::actionUpdate(18);
get to /cars/18 ---> CarsController::actionRead(18)
Now for some page I need to make a put request to the read action; this is impossible using the url generator functions.
Url::to(['cars/read', 'id' => 18) will create /cars/18, which will resolve to update if i do a put request.

This does not seem logical.
String representation of the URL, which is created by UrlManager::createUrl(), can NOT contain verb specification. There is no way passed verb can affect the created URL.
It is also unlikely that, for example, PUT and GET request to the same route with the same parameters will use different URL. If you want to create 'put to /cars/18' or 'get to /cars/18', the same URL will be produced: '/cars/18'.

Can you provide the actual example, where verb specified to createUrl() can affect the result? Which URL rules configuration can provide this?

@klimov-paul  You are not understanding me.
The whole problem is that the string representation cannot represent it, that is why it needs to be a parameter passed in to url creation.
The parameter tells the url generator what the intended goal of the url is (for example posting, putting or deleting).

The exact example is:
  [
            'verb' => 'GET',
            'pattern' => '<controller>/<id:\d+>',
            'route' => '<controller>/read',
    ], [
            'verb' => 'PUT',
            'pattern' => '<controller>/<id:\d+>',
            'route' => '<controller>/update'
    ],

Now I need to create a PUT request to /cars/update?id=8. But I cannot use the Url helper since it would create a "pretty" URL using the GET rule:
/cars/8
Which, when I do a PUT request is parsed by the wrong rule. Instead if I tell the Url helper I'm generating a URL that will be used in a PUT request, it can see that the first rule does not apply and it will not create a pretty URL:
/cars/update?id=8

The parameter tells the url generator what the intended goal of the url is (for example posting, putting or deleting).

And what purpose it will serve?

You are not understanding me.

And in return.
So, once again. Assume we add such parameter, lets call it '_verb'.
Now I can NOT imagine the situation, when:
$urlManager->createUrl('controller/action', 'id' => 1, '_verb' => 'get');

and
$urlManager->createUrl('controller/action', 'id' => 1, '_verb' => 'put');

can produce different results.

The exact example is:

So, WHY do you need verb here???
While creating URL you will use:
$urlManager->createUrl('controller/read', 'id' => 1); // matcing GET

and
$urlManager->createUrl('controller/update', 'id' => 1); // matcing PUT

Of course there would be different result if we add a verb parameter (btw I'm not saying it has to be the syntax you propose since that would be breaking BC).
In my rules example, you can see that there woudl be a different result.
    $urlManager->createUrl('cars/read', 'id' => 1, '_verb' => 'get');

Would give "/cars/1".
    $urlManager->createUrl('cars/read', 'id' => 1, '_verb' => 'post');

Would give "/cars/read?id=1" since the first rule (previous comment) no longer matches.

I don't think it should be solved this way. It's better to add support for URL rule aliases so one could explicitly specify which rule to use.

Hmm, but should I care (or even "know") about URL rules in the view?
In the view I am merely saying get me a URL to this route, with these parameters.
I don't care how you generate the url.
@samdark I don't think aliases for URL rules are the answer here; it will create a strong cohesion between view code and configuration information.
In essence I should be able to implement other routing mechanisms without affecting the view code. For example I could create a URL manager that encrypts and base64_encodes each url; if i then drop that into any application it should work as long as the application uses the helpers properly.

In my rules example, you can see that there woudl be a different result.

For me such example does not make sense. It is example of the bad practice. Why the same controller/action responds to the different request types?
This produces inconsistent code inside the controller, where you should write an if statement to determine what should be done: read or write operation.

Overall I agree with @klimov-paul. In general, same endpoint should use same URL no matter what verb is.

To be more precise: I can not see any practical use case for such feature.
Separation for different request methods usually implemented to support REST architecture, which enforces using different request methods for the same URL. This means each combination of the URL and request method should be responded by different route, but not vice versa.
Although there is acombination of URL rules, which may require this feature, its usage produces inconsistent code. So I don't think such functionality should belong to the core.
I am closing this issue unless more coherit use case provided.

@klimov-paul I know this is your default way of responding to things, but a bit more patience and open-mindedness would be greatly appreciated!
Endpoints are mapped to URL during URL creation.
URLS are mapped to endpoints during URL parsing.
It seems natural to me that these functions are eachothers inverse.
Specifically, if I generate a URL to a specific endpoint, it should always be parsed to that specific endpoint.
Currently it is not:
    $url = Url::to(['projects/read', 'id' => 8]); // $url = '/projects/8';

   // Parse a PUT request:
   parseUrl("/projects/8") ==> ProjectsController::actionUpdate(8);
   // Parse a GET request:
   parseUrl("/projects/8") ==> ProjectsController::actionRead(8);

If we had the extra argument:
    $url = Url::to(['projects/read', 'id' => 8], null, 'PUT'); // $url = '/projects/read?id=8'; Since the GET rule no longer applies.

   // Parse a PUT request:
   parseUrl("'/projects/read?id=8") ==> ProjectsController::actionRead(8);
   // Parse a GET request:
   parseUrl("'/projects/read?id=8") ==> ProjectsController::actionRead(8);

Alternatively the argument could at least specify not to do any pretty url generation, which would at least allow this scenario without forcing me to:

Replicate Url helper functionality.
Hardcode URLs in my views.

Please explain why you need GET and POST to the same endpoint to have separate URLs.

It seems natural to me that these functions are eachothers inverse.

It whould be so, if there be a way to specify request method inside the URL, but such ability does not exist.

If we had the extra argument:

If you have an extra argument, you have an extra if inside your controller;
class ProjectsController extends Controller
{
    public function actionRead()
    {
        if (Yii::$app->request->method === 'PUT') {
            // do saving here
        }  else {
            // do read
        }
    }
}

And such action breaks 'single responsibility' pronciple.
While according to the OOP recomendations you should separate 'read' and 'write' actions.
So your controller looks like:
class ProjectsController extends Controller
{
    public function actionRead()
    {
        // responds to the 'GET'
        // do read
    }

    public function actionWrite()
    {
        // responds to the 'PUT'
        // do saving here
    }
}

Folloing simple OOP principle, you will never get yourselt inside the situation you may require specificartion of the verb for URL creation, as it is already specified via route!

I am doing PUT to update an entity: PUT /projects/8  will update project 8.
Sometimes I don't want to not update the entity, but rather it's view (for example pagination or something else).
So I need to create a request that does PUT /projects/read?id=8.
Which is impossible since a the url generator will always use the rule for the GET verb and create a URL like (/projects/8) that will be routed when PUTting to projects/update..
Note: In general should I not be able to create a URL that will be routed to a specific controller action without knowing about rules? I am in the view I don't care and don't know about URL rules.
So if we add an intended VERB this issue is 100% solved for those who need it and it does not bother anyone else..

@yiisoft/core-developers more opinions?

@SamMousa Why don't you add an additional PUT rule with the pattern /projects/read/<id> for the read action? Note that even if we add the verb parameter to the URL creation method, it will still fail to work if we turn on strict parsing.

@qiangxue, because that is the issue!
If I add another rule it will not be used since the pattern for the get verb is the same.
So I can have multiple rules with 1 pattern for parsing, but not URL creation!

Alternatively the argument could at least specify not to do any pretty url generation...

So I can have multiple rules with 1 pattern for parsing, but not URL creation!

There is yii\web\Rule::mode, which can be set to 'parsing only' or 'creation only', which allows you to skip unnecessary rules while parsing or creating URL.
You may achieve your goal creating a custom URL rule, which will accept verb as params and vary accordingly. I still think this feature does not belong to the core.

There are plenty ways to work around Yii, I'd rather just work with Yii.
There is simply no reason for this assymmetry between url parsing and url creation.

@SamMousa I understand your need now. I think your request makes sense. We probably can consider supporting the syntax:
Url::to(['PUT cars/read', 'id' => 18])

@qiangxue  Thanks for your patience. As to the syntax, I don't have a specific preference.
I've been reading up a bit on versioning and can see that adding an optional argument to these functions could break applications that extend things like UrlRule.
On the other hand, if an UrlRule implementation depends on the route parameter that could cause problems as well ^^.
Anyway, that part is more your job, I've done mine by explaining the problem. If I think of a good syntax, I'll let you know!

On the other hand, if an UrlRule implementation depends on the route parameter that could cause problems as well ^^.

What kind of problems do you have in mind?

@qiangxue if I subclass UrlRule::createUrl and you change the signature I get strict errors.
See: http://paul-m-jones.com/archives/6136
While you replied I was typing this:
After digging into the source some more, I think the best solution would be to:

Add optional argument to UrlRule::createUrl($manager, $route, $params, $verb = null)
This forces anyone who subclasses UrlRule to update their signature.

Add optional argument to UrlManager::createUrl($params, $verb = null)
This forces anyone who subclasses UrlManager to update their signature.

Add optional argument BaseUrl::toRoute($route, $scheme, $verb)
This forces anyone who subclasses BaseUrl to update their signature.

Alternatively a temporary fix could be implemented that reduces the BC break:

Create a subclass "NewUrlRule" of UrlRule that has the new parameter.
Set the default class for url rules to "NewUrlRule".

Repeat for UrlManager, implement createUrl to do an "instanceof" check and pass arguments appropriately. Also set default url manager class to "NewUrlManager"
Then update the Url helper, which will be the only location for BC breaks.

I didn't suggest changing the signature. I was suggesting ['PUT cars/read', 'id' => 18]

Oh yes, of course; too quick :p
Well if I implement custom logic that in UrlManager / UrlRule that depends on the route format, which is documented here: https://github.com/yiisoft/yii2/blob/master/framework/web/UrlManager.php#L272
It could break my application if people put stuff with spaces in there ^^.
(Playing devils' advocate here, I'd rather have this sooner than later but I know BC is important for Yii)

Well, the only bad result is that your custom UrlManager/UrlRule won't work with PUT cars/read. But this is already the case currently (i.e., the custom class has problem dealing with this issue you reported.)

One thing that would definitely not break BC is to add it in the same way as anchors, via a 'special' key in $params.
If you pick a name that is unlikely to be used by people normally, like _verb or _method.
@qiangxue  Fair enough, and obviously those people not using this will not have spaces in their routes so if they want the new functionality it is not that strange that they would have to make small changes to their code.

Can we get a conclusion on the desired direction?
We can use @qiangxue suggestion and add support for prefix the route with a verb.
(If the desired direction is to not support this, feel free to close this)

sounds like a good thing in general, will check it in more detail after 2.0.7 is out.

@cebe, great; if you decide on what kind of implementation you'd like I'm still up for implementing this.
Short list of options discussed above:

Put method before URL: createUrl(['PUT test/create'])

Use specific parameter: `createUrl(['test/create', '_verb' => 'PUT']); (we could use a single character key here forbidden list, this will make random collisions very unlikely: https://tools.ietf.org/html/rfc3986#page-13

Change all method signatures to have an extra parameter specifying the verb.

Okay, spent some more time on this. Currently I have a (partial) implementation:
Rules, strict parsing is enabled:
[
        'verb' => 'GET',
        'pattern' => '<controller:\w+>/<id:\d+>',
        'route' => '<controller>/read'
    ],
    [
        'verb' => 'PUT',
        'pattern' => '<controller>/<id:\d+>',
        'route' => '<controller>/update',
    ],
    [
        'verb' => 'POST',
        'pattern' => '<controller>',
        'route' => '<controller>/create',
    ],

    [
        'verb' => 'DELETE',
        'pattern' => '<controller>/<id:\d+>',
        'route' => '<controller>/delete'
    ],

This is the output, columns are (test case, route, params and result)
1  model/read          [id => 2]            --> /model/2
2  model/read          [id => 2][b => test] --> /model/2?b=test
3  model/update        [id => 2]            --> /model/2
4  POST model/read     [id => 2]            --> /model/read?id=2
5  PUT model/update    [id => 2]            --> /model/2
6  GET model/read      [id => 3]            --> /model/3
7  DELETE model/read   [id => 3]            --> /model/read?id=3
8  DELETE model/delete [id => 3]            --> /model/3
9  DELETE model        [id => 3]            --> /dev/model?id=3
10 DELETE /model       [id => 3]            --> /model?id=3
11 model/create        [test => 2]          --> /model?test=2
12 GET model/create    [test => 2]          --> /model/create?test=2
13 POST model/create   [test => 5]          --> /model?test=5
14 model/update        [test => 2]          --> /model/update?test=2

The only issue is the default configuration where there is no verb as part of the route.
This implementation does not "assume" anything, so in the case of 11 it will use the POST rule even though this might not be expected behavior.
Feed back please!

This implementation does not "assume" anything, so in the case of 11 it will use the POST rule even though this might not be expected behavior.

This behavior does not look valid to me. I suggest the following request routing logic order:

Find the rule that matches the request with appropriate verb. If not found - see step 2.
Find rules that match the request. Ensure, that all of them do not have declared verb.

true - use the first rule
false - throw an exception, that there are no rules for this verb

Silverfire, your proposal would break BC in a big way though; currently verb in the rule config is irrelevant; I used it only when a method is given to create URL. Your suggestion would require it to be present, right?

I don't want to make verb required, my example logic is malformed.
Try №2:

Find the rule that matches the request with appropriate verb. If not found - go to step 2.
Find the rule that matches the request but does not have verb. If not found - throw an exception, that there are no rules for this verb

See the example:
$rules = [
    [
        'verb' => 'POST',
        'pattern' => '<controller>',
        'route' => '<controller>/create',
    ],
    [
        'pattern' => '<controller>',
        'route' => '<controller>/index',
    ],
];

In this case you have a rule for POST request and a default one for any other request type.
BUT if I remove the second rule - there will be no way to resolve GET controller request. Is it clear enough?

Yes, that's clear. But in my example 11, there is no GET. It is fine to throw exceptions for code like this:
->createUrl('GET controller')
````
But how do you handle the case `->createUrl('controller')` (without explicit intended verb).

The problem is not there when an intended verb is present; since that is new behavior we are free to choose a default (and I like your suggestion of throwing an exception).
The problem is what do we do if we do not have an intended verb; do we assume the intended verb is `GET` or do we try `GET` and fallback to anything else as you suggest.

The current yii behavior currently is to not look at the verb in the route config when creating a url; so if we want least surprise one could argue that we don't change the case where no intended verb is given.

PS. I introduced the term `intended verb`: The verb given as part of the route in a call to `createUrl`; using this to clearly separate it from the verb in route config.

Ah, okay, now I see the problem. Need some time to think about it

Bump ^^

@SilverFire did you get a chance to think about this?

Won't be actual for 3.0.


No StreamField-love in the demo

I can't find a reference to the StreamField in the demo.
This is a seller-feature for wagtail, so I would have expected some reference to this.

Yes sorry about that @spoetnik, it's now a PR awaiting merge here, if you're interested: https://github.com/torchbox/wagtaildemo/pull/81
(requires a clean database first)

Fixed in #81.


Automated Package Upgrade

:tada: This PR is included in version 5.0.205 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Swiftlint is still checking unchanged files

SwiftLint is still checking unchanged files in my pull-requests even though I'm using the following swiftlint.yml config
name: SwiftLint

on:
  pull_request:
    paths:
      - '.github/workflows/swiftlint.yml'
      - '.swiftlint.yml'
      - '**/*.swift'
      - '!Pods/**'

jobs:
  SwiftLint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: GitHub Action for SwiftLint (Only files changed in the PR)
        uses<EMAIL_ADDRESS>        env:
          DIFF_BASE: ${{ github.base_ref }}

I have the same issue.
I get this error message

fatal: Not a valid object name dev

dev is the value in ${{ github.base_ref }}
Anyway to fix that?

Same issue here!

@samh-depop @kerrmarin I've solved this problem with following action configs:
      - name: Fetch base ref
        run: git fetch --no-tags --prune --depth=1 origin ${{ github.base_ref }}
      - name: Run SwiftLint
        uses<EMAIL_ADDRESS>        with:
          args: --force-exclude
        env:
          DIFF_BASE: origin/${{ github.base_ref }}

I get the same issue with fatal: Not a valid object name dev. Has anyone managed to find a fix for this? I've tried what @dlackty has suggested but it doesn't review any files. It's saying no files changed. :(

@stefangerard Do you add additional git fetch step to fetch base ref?
Could you share the whole workflow yml? I would like to help.

base_ref is only available for forked repo I think -
https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables

I too have noticed that github.base_ref isn't actually working like we'd expect.
Though I am getting a PR lint successfully when new commits are pushed, but when run locally linting fails. It seems that it is only linting against the changes that were pushed and not the entire PR? The pushed commits didn't have linting issues but also didn't fix the previous linting issues. Has anyone else experienced this issue while using github.base_ref? Should we be using github.ref instead? 🤔
@akashnimare it comes from the github context not env vars (look at github.base_ref docs)

I have tried out github_ref as well doesn't work as expected.

What's the best way to test out GitHub actions locally?

What's the best way to test out GitHub actions locally?

I haven't found a way. I just have a private repo that I do lots of commits on.

Internet says this tool could be used for testing actions locally.

Same issue here. Will opt-out changed file only till it works.

having the same issue. Any clue?

Facing same issue, any solution suggested?

The root cause is that the action cannot perform a diff against base branch, because the base branch has not been checked out by the workflow (hence fatal: Not a valid object: dev/main/master errors). If you fetch its most recent commit, then it's known to git locally and diff works.
- name: Fetch PR's target branch
  run: git fetch --no-tags --prune --depth=1 origin ${{ github.base_ref }}
- name: Run SwiftLint on files changed in the PR
  uses<EMAIL_ADDRESS>  with:
    args: --force-exclude
  env:
    DIFF_BASE: ${{ github.base_ref }}

It's similar to what @dlackty posted, although in my case origin/ doesn't seem to be needed (in fact it doesn't work that way). Works here, however is still prints that error 🤷


Spawners

Every spawner by default is a pig spawner

Please provide actually helpful information in issue reports. If this happened all the time we would have fixed it by now, so provide instructions to reproduce, tell us what platform you are on, provide logs, list of mods, etc. This issue report is the opposite of helpful.

(needs work is for when the code is in WIP)

oh, I'm sorry, this is my first time ever doing something like this so I apologize for the lack of helpful information.
In my experience this happened every single time there was a spawner (namely dungeons) except for in the nether.
The mod list is in Fabric, mod list goes:

fabric API 0.34.2
optifabric 1.9.6
optifine G7
replaymod 2.5.2
Terra-fabric-5.3.0-BETA+fd48f5f1-shaded-mapped
latest.log

Remove OptiFine.


Question: Allow arbitrary json object

This is a question!
I've had a lot of issues finding the solution and I'm probably not asking correctly what exactly I'm trying to solve but here is my question:
I've got a schema which serves as a wrapper to all my models.  It essentially adds a property to the responses of each model which provides some context for the client to make sense of the stored data.
Here is what the response looks like:
{
  "data": {
      id: 1,
      ...
  },
  "_app": {
    "type": "cart",
    "version": "v1"
  }
}

This works great when I'm defining my models very strictly.
But suppose I want to leverage this schema to a more loose model.  A model that is the output of a report that gets generated every hour for example.  Many different variations of the report results and thats ok.
{
  "data": {
      <arbitrary json>
  },
  "_app": {
    "type": "analysis",
    "version": "v1"
  }
}

I've defined the following as my schema and I can't figure out how to let the data "object" property just return the results.. it always just returns an empty JSON object or nothing at all if I don't return it before my API response.
fastify.addSchema({
  $id: "analysis",
  type: "object",
  properties: {
    data: {
      type: "object"
    },
    _app: {
      type: "object",
      properties: {
        type: {
          type: "string",
          default: "analysis"
        },
        version: {
          type: "string",
          default: "v1"
        }
      },
      default: {
        type: "analysis",
        version: "v1"
      },
      required: ["type", "version"]
    }
  },
  required: ["_app"]
});

Is the only way to force the data object to validate to just not use ajv?  I'm basically trying to have a loose validation.. like how Joi lets you say this is a JSON object, without needing to define the contents.
Appreciate the help and remember that other newbies may search for this use case in the issues section, so pointing me to the docs and saying "go figure it out it says it here in the spec blah blah" doesn't really help :(

I am sorry, not sure I understand...
The issue MAY be with fastify modifying the schema in some way - you don’t use Ajv directly.
If you validate the sample above against the schema above it should pass - please try without fastify.
If it fails please post a full code sample you use.

Thanks, taking it up on fastify repo, though I tried to change the param: removeAdditional: false directly in their source and it still doesn't work when applying the schema against the serializer they are doing in the reply (response handler). 🤔

@bneigher closing it here - please resubmit with simple code sample if it is not resolved


[RFC] Accessing all annotations on an ivar/type/def

I been thinking about https://github.com/crystal-lang/crystal/issues/6984 and thought of another use case that it would be better suited for.
For the serializer shard I been working on, I have a concept of PropertyMetadata.  An array of these types is built out via a macro as a way to generically describe a property; such as its type, name, owning class, etc.
I also have a concept of ExclusionStrategies, which allow applying custom runtime logic to determine if a given property should be skipped.  A common implementation I could see for this is defining some custom annotation, applying it to a property/class, and then using the presence of the annotation, or values within the annotation, as part of the exclusion strategy logic.
annotation SomeAnn; end

class User
  include ASR::Serializable

  @[SomeAnn(priority: 1, privilege: :private)]
  property manager_id : Int32
end

However, given Crystal doesn't have a way to access annotations at runtime, nor is there a clean way to generically do it at compile time, I thought of a pretty decent solution.  If there is a method to return all annotations applied to a given ivar/type/method, then I could include this information as part of the PropertyMetadata.  For example, manager_id could be represented like:
<PropertyMetadata(Int32, user)
@name="manager_id",
@annotations={
  "SomeAnn" => {
    priority: 1,
    privilege: :private
  }
}>

Then the logic within the strategy could check for a specific annotation:
return false unless ann = metadata.annotations["SomeAnn"]?

return true if ann[:privilege] == :private

...

I think it also would play well for future annotation enhancements, such as being able to do ivar.annotations.select(ValidationAnnotation) or something along those lines.
WDYT?

A concern with Defs is that it should be possible to reconstruct every annotatable node from its parts (https://github.com/crystal-lang/crystal/issues/3274#issuecomment-859553972), so if any annotations are attached to a Def, there needs a way to iterate through all of them.
One problem is, the following:
@[Bar]
def foo
end

is parsed as:
Expressions.new([
  Annotation.new(Path.new(["Bar"])),
  Def.new("foo", [] of Arg),
] of ASTNode)

and not as a single Def node that contains the annotation. So perhaps such a macro method is not very useful in this scenario, because to reconstruct the Expressions we would have encountered the Annotation node itself anyway, and if we interpolate #annotations for the Def we would doubly apply every annotation. That said, it's not like such a macro method would do any harm as long as the parsing behaviour is documented properly.
For MetaVar and TypeNode I'm less sure because they are fictitious nodes.
The extension is simple; if we add Annotation#name : Path then it will be possible to do ivar.annotations.select &.name.resolve.== SomeAnnotation. (This macro method is also needed to reconstruct the Annotation node itself.)

Can we change the AST so that annotations belong to the node they annotate? It seems weird to have them just as previous expressions. I suppose this could be a breaking change, but perhaps we can keep the backwards-compatible API until 2.0.