Cargo new workspace error from toml edit

Error when creating new lib after editing Cargo.toml file. Small issue, mostly visual.
Problem
I used the $ cargo new df_st_db --lib where 'df_st_db' is the name of the workspace.
This gave me the following result:
$ cargo new df_st_db --lib
warning: compiling this new crate may not work due to invalid workspace configuration

current package believes it's in a workspace when it's not:
current:   /...redacted.../df_st_db/Cargo.toml
workspace: /...redacted.../Cargo.toml

this may be fixable by adding `df_st_db` to the `workspace.members` array of the manifest located at: /...redacted.../Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.

Stack backtrace:
   0: cargo::core::workspace::Workspace::new
   1: cargo::ops::cargo_new::mk
   2: cargo::ops::cargo_new::new
   3: cargo::commands::new::exec
   4: cargo::cli::main
   5: cargo::main
   6: std::rt::lang_start::{{closure}}
   7: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
      std::panicking::try::do_call
             at src/libstd/panicking.rs:305
   8: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:86
   9: std::panicking::try
             at src/libstd/panicking.rs:281
      std::panic::catch_unwind
             at src/libstd/panic.rs:394
      std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  10: main
  11: __libc_start_main
  12: <unknown>
     Created library `df_st_db` package

This gave the backtrace above, although I see no direct error.
I was adding a workspace to a project that already has 5 more workspaces.
These we created in the same way, but no error there.
There does NOT seem to be any issues with the creation of the package/workspace. All files are fine and exactly as expacted.
Steps

Create a package
Create a lib
Edit Cargo.toml (add workspace.members section)
Create a lib
Stack backtrace in output

Here is the output I could reproduce it with: (execute this in terminal, somewhere in an empty folder is best)
cargo new df_test
cd df_test/
cargo new df_core --lib
cat > Cargo.toml << EOF
[package]
name = "df_test"
version = "0.1.0"
authors = ["user <>"]
edition = "2018"

[workspace]
members = [
    "df_core",
]

[dependencies]
EOF
cargo new df_st_db --lib

Possible Solution(s)
The problem is with the workspace.members section in the toml file. Maybe it tries to edit this section?
If I do not edit the toml file (aka do not execute the cat lines above), I don't get any warnings.
Notes
Output of cargo version:
$ cargo version
cargo 1.42.0 (86334295e 2020-01-31)
$ uname -a
Linux Ralpha 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ rustc --version
rustc 1.42.0 (b8cedc004 2020-03-09)

First issue I had with Cargo and still ♥ Cargo, great job everyone!

Thanks for the report!  Looks like it was reporting the message using the debug display which if RUST_BACKTRACE is set also displays a backtrace.  Posted a small fix at #8119.

Perfect, if that solves the issue this can be closed.
And quick response time here :smile:


Generate configuration files at add framework support time

Fixes #1276
On New Project and Add Framework Support, a new Runtime option appears with the options "java" and "custom" for App Engine Flexible.

If files already exist at the default locations, the user is asked whether they want to keep them or generate new ones. If new ones are generated, the old ones are backed up (moved to filename.bak).

Went ahead and implemented the checkbox that generates app.yaml with runtime: java.
I left the support to generate both runtime java and custom app.yamls from the previous iteration, in case we want it in the future. But I can remove it if you guys think it clutters the PR.

@patflynn I know were opinionated about this change. I ended up going for the sole "generate app.yaml" checkbox, that generates runtime: java app.yaml.
Would be good to get a thumbs up from you before @etanshaul reviews.

that functionality sounds right to me. :+1
On Mon, Mar 6, 2017 at 10:41 AM, João Martins<EMAIL_ADDRESS>wrote:

@patflynn https://github.com/patflynn I know were opinionated about
this change. I ended up going for the sole "generate app.yaml" checkbox,
that generates runtime: java app.yaml.
Would be good to get a thumbs up from you before @etanshaul
https://github.com/etanshaul reviews.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1282#issuecomment-284433411,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5Hc4OeSuYyKIKdao47jQLtNAFFiLyks5rjCkqgaJpZM4MRpBd
.

I didn't get the warning when an app.yaml already existed on the filesystem. Instead, it just created the new one and backed up the old one.

I removed the warning so the process would be simpler.
Do we want to add it back?

Oh. I did like the idea of warning the user instead of overwritting their file immediately.

Also (and I don't know if theres a way around this), but when generating the configuration the IDE would pop up a message notifying about "external modifications" on the filesystem. I wonder if you integrated into the IDE's file mechanisms (PSI files etc) we can prevent this.

yea, I think I preferred your initial idea of prompting to overwrite in the
case the file already exists.
On Thu, Mar 9, 2017 at 4:21 PM, Etan Shaul<EMAIL_ADDRESS>wrote:

Also (and I don't know if theres a way around this), but when generating
the configuration the IDE would pop up a message notifying about "external
modifications" on the filesystem. I wonder if you integrated into the IDE's
file mechanisms (PSI files etc) we can prevent this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1282#issuecomment-285486877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HftIId-mD5XuxYZ_O9NI4kSxj_xeks5rkG1AgaJpZM4MRpBd
.

PTAL, if an app.yaml file exists at the suggested location, a popup asks if the user wants to override it.
If yes, a backup file is created and a new app.yaml is generated. If a backup file with the same name (e.g., app.yaml.bak) already exists, another backup won't be created.
If no, then the old file is reused and no file is generated.

Did you address the issue of the IDE warning the user of external file system modifications when the app.yaml is generated? I suspect this can be worked around.

I'm not sure how or if that would work. I think the user being notified that the file has changed is the correct behaviour. That improvement sounds like something that could be solved later in another PR.

I'm ok with doing it another PR. But I do think its the correct behavior: its the IDE thats guiding the creation of these new configuration file (after prompting the user). The experience, imo, should not be as if the file was created externally. You could check what other plugins do here, and how they achieve this (if they do it).

also, did you test it out on Win? I remember we've had some issues in the past with file manipulation not working there. I didn't check myself if the calls you are using are system independent.

I 'm thinking we shouldn't create a backup file. I've never seen intellj do
this. If they choose to overwrite and change their mind they can always
ctrl+z, or use IJ history to revert, or use their version control system.
On Tue, Mar 14, 2017 at 5:54 PM, Etan Shaul<EMAIL_ADDRESS>wrote:

@etanshaul commented on this pull request.
In google-cloud-tools-plugin/resources/generation/src/
appengine/flexible/java/app.yaml
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1282#discussion_r106037501
:

@@ -0,0 +1,4 @@
+runtime: java
+env: flex
+env_variables:

'DBG_ENABLE': 'true'

after offline discussion it seems that it should work without it, but
we'll leave it until we can verify.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1282#discussion_r106037501,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HWuuSzZobB92zAc3FED2iGQcbhXdks5rlwyZgaJpZM4MRpBd
.

Also ctrl+z is a good test scenario.  If it doesn't work you know you're
not creating the file correctly.
On Tue, Mar 14, 2017 at 6:19 PM, Patrick Flynn<EMAIL_ADDRESS>wrote:

I 'm thinking we shouldn't create a backup file. I've never seen intellj
do this. If they choose to overwrite and change their mind they can always
ctrl+z, or use IJ history to revert, or use their version control system.
On Tue, Mar 14, 2017 at 5:54 PM, Etan Shaul<EMAIL_ADDRESS>wrote:

@etanshaul commented on this pull request.
In google-cloud-tools-plugin/resources/generation/src/appengine
/flexible/java/app.yaml
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1282#discussion_r106037501
:

@@ -0,0 +1,4 @@
+runtime: java
+env: flex
+env_variables:

'DBG_ENABLE': 'true'

after offline discussion it seems that it should work without it, but
we'll leave it until we can verify.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1282#discussion_r106037501,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HWuuSzZobB92zAc3FED2iGQcbhXdks5rlwyZgaJpZM4MRpBd
.

The file is created by Add Framework Support, and I just tried to ctrl + z Add Framework Support and it doesn't work.
Unless you mean undoing only the file creation without undoing Add Framework Support?

I was just able to add framework support, overwrite app.yaml and not get the warning. But I got it when I tried before, so not sure what's triggering it.

OK, I changed it so a PsiFile is used inside a WriteCommandAction. I didn't get any more of those "file-system file changed" warnings and it is now ctrl + z-able.
Let me know if you have more feedback.

I defer to Etan, I haven't actually looked at this code, just lurking on
the comments.
On Wed, Mar 15, 2017 at 4:53 PM, João Martins<EMAIL_ADDRESS>wrote:

OK, I changed it so a PsiFile is used inside a WriteCommandAction. I
didn't get any more of those "file-system file changed" warnings and it is
now ctrl + z-able.
Let me know if you have more feedback.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1282#issuecomment-286875499,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HQcf1boLbZXDksUSa6Q6__Z_Vtl1ks5rmE-wgaJpZM4MRpBd
.

FYI there's an open issue re-writing files on Windows due to the separators I'm using, but creating works there.

The separators issue is solved, but afterwards I uncovered another weird IJ issue on Windows only -- adding Flexible support to a project that already contains an app.yaml, and then trying to manually edit the file, results in the following error:
Cannot Save Files
Cannot save file name
The file left unchanged.
Your changes were written to app.yaml__jb_tmp__.

In fact, this happens for every file which is generated by the IDE (or, in the case of add flexible support, modified by the IDE with Document.setText()), e.g., for files and directories created by the generate button.
There are a couple of available workarounds. Restarting the IDE makes the file editable again, and disabling Safe Write from Settings -> Appearance and Behaviour -> System Settings also works.
http://stackoverflow.com/questions/19513779/what-is-this-bug-in-intellij-idea
https://youtrack.jetbrains.com/issue/IDEA-78480
http://stackoverflow.com/questions/23864827/jb-bak-and-jb-old-files-in-pycharm
Since this problem doesn't appear to be specific to this PR, I suggest filing an issue about this and not consider it a blocker for this PR.

Maybe you misstated, but why would that bug happen to a project that already has an app.yaml? If the app.yaml already exists shouldn't the file just be left alone? Or do you mean when the user chooses to overwrite it?

Yeah, this happens when the file is overwritten or created by IJ.


Document "log-driven closed timestamps"

In order to enable non-blocking transactions (#9038), we will also be adding something called "log-driven closed timestamps".  AIUI these will update our existing closed timestamps to remove some current limitations.
There may not be docs work here, but we do mention closed timestamps in the Follower Reads docs, so we may need to at least update that.
See also:

#6793
https://github.com/cockroachdb/cockroach/pull/56675

Fixed in #11762


Typo in disclaimer

Describe the bug
Typo in the disclaimer.
Linguistic issues

Current text: Utlization of services located through the app is undertaken as the risk of the user.
Suggested text:  Utilization of services located through the app is undertaken as the risk of the user.
Reason: typo in English

The string in localized using lingui. Changing the English will cause ripple effects through the other localization files. When solving this issue, we need to (1) ensure that the translation of the affected string into other languages is not broken, and (2) carefully document the process, since this will not be the last time we need to make this change. This case is simpler than most, since the change in the English will not trigger the need to update the translation in other languages, so it makes for a nice test case for just the localized string management.

Fixed as part of a PR that also addressed #529


FSDP: Add mistral model type support

Adding support for mistral model type when using FSDP for training on Hyperpod. Before these changes, only mixtral was supported. This PR is part of other PRs that Nithin and I will incorporate as part of the mathstral sbatch job already tested on Hyperpod.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Approved, relates to #385


SAKIII-4988 enable mark as read button only if unread messages are selected

https://jira.sakaiproject.org/browse/SAKIII-4988

Squashed and merged


haskell.packages.ghc96: Build fixes

These are Haskell package overrides to make various things build under ghc962.
This branch is based on haskell-updates (#240387), cc: @maralorn @cdepillabout.
I am testing the build on x86_64-linux with this expression:
(import ./default.nix {}).haskell.packages.ghc96.ghcWithHoogle (hp: with hp; [
  turtle
  shake
  taffybar
  xmonad
  servant
  servant-lucid
  servant-swagger
])

Thanks @cdepillabout


task: add test for section 51 advice

Describe your changes
Add a happy path e2e test for section 51 advice

https://pins-ds.atlassian.net/browse/ASB-1927

Useful information to review or test

Type of change 🧩

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update
[ ] Other (please explain in the description section above)

Checklist before requesting a review

[ ] I have performed a self-review of my own code
[ ] I have double checked this work does not include any hardcoded secrets or passwords
[ ] I have made corresponding changes to the documentation
[ ] I have provided details on how I have tested my code
[ ] I have referenced the ticket number above
[ ] I have provided a description of the ticket
[ ] I have included unit tests to cover any testable code changes

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


Nexus 3 metadata, npm folder and checksum file issue solutions

our systems is a Nexus 3 instance initial migrated over from a nexus 2 instance. This resulted in us maintaining a system of storing md5 and sha1 files alongside our artifacts. When using this migrator it picked up these files and attempted to upload them to Artifactory, not only is this a fruitless task as artifactory manages that for us, when it attempts the checksum upload the checksum files contents is not included, and as Artifactory is a clever thing it knows its a checksum and looks inside the file, resulting in some empty string issues.
Not only this but we discovered intermittent issues with npm repos being uploaded, this oroginated from the folders metadata being uploaded as a file and thus blocking any further files in that directory structure.
We also have a reliance on timestamps in certain areas, and this migration process replaces them with the uploaded time, there is a change in here which alters this.
And these changes resulted in a successful migration

I've commented on the requests individually, the safe checksum and copy headers seem solid. after looking through the npm file and some more digging through our blob files, the case I'm trying to cover is when the blobs bytes file has its name as @scope/folder and the code attempts to compare it to simply folder. The small change i've made attempts to account for this.

Awesome, looks good to me. Merged.


Expose reply to header from mail implementations in MailSender

Fixes #12

Please remove the (WIP) // TODO later version code while you're at it


Un-string-ify micro-ROS diagnostics

I gave it a shot and refactored micro-ROS diagnostic status to work without arrays and without strings. I added a new package micro_ros_diagnostic_bridge, which provides a ROS 2 node to run on the micro processor and translate micro-ROS diagnostic messages to vanilla ROS 2 diagnostic messages based on a lookup table.
See micro_ros_diagnostic_updater/example for two example updaters and example_table.yaml for the corresponding lookup table.

I think the PR looks quite nice, I hope you don't mind, I left some comments :+1:

@mrbhjv on the contrary, your comments are very much appreciated. Regarding the hwmonitor in common diagnostics:
I suppose these could be standalone executables as it is currently done in vanilla ROS 2 common diagnostics (in python). If so, hardware ID, updater ID, and task ID could be command-line arguments to be set according to the use-case specific lookup table.´Does this sound reasonable to you?

Could you explain to me how am I intended to add this module to my project?
What I would do, when adding it to my own embedded project, is to link it this as a static library, then use it as I want internally. It's what I do already for micro-ros itself. In this way, I can actually be sure to add it following my structure. I'd use your implementations as examples for me to follow.
On the non-embedded side, it'd be nice to have the bridge (which you mention should run on the microprocessor, but I guess it should run on the high system). I'm okay with everything that follows up to simply be the default package with CMD line arguments (or a proper launch file). However, you mention using command-line arguments for the .c files, which I guess are intended to run on the embedded system (the ones I suggested using #define).
Maybe I'm not understanding the workflow?

I still think I don't quite understand how this works (mostly the part where I can pass static defines to the embedded system as command-line arguments), I'll be trying to test it soon to see if I can see more clearly the intended use. This sounds mostly like me not understanding the idea.
We are actually working with C++17 on our embedded systems, so we'll have to make some abstractions before we try to add it. So, apologies if it takes some time before I come back with some feedback. But while going through the PR, I noticed much use of types that are not very friendly for embedded systems. Thus being, double and int64_t.
We're trying to be very careful about how our memory gets mapped and what types we bring into our system.
Even for a Twist message, we need to create our custom non-double (floats with 32 bits are fine :)) equivalent. And, if this goes too off those data-types, we'll see it hard to simply include it.
Lastly, have you had some experience with this system running on embedded? The cross-compilation is similar to the one for creating the micro-ros static lib?
Thanks!

Thanks again for your comments, @bjv-capra. Very much appreciated!
We did not yet get down to trying it on a micro controller. We plan to do so within the next 2-3 weeks, maybe this will clear things up. If you manage to try it out until then, I am happy to hear about your experience.

What would be missing for this PR to be merged?

I wanted to test in a PC + microcontroller setup first, which I still didn't manage to do so far.

@bjv-capra I successfully tested the setup on a mciro-controller now and will merge soon.


How to derive typescript definitions directly from structs?

I'm trying to generate typescript definitions for parameters, which are directly derived from my actual structs.
struct Foo {
    pub my_id: String,
}

pub async fn foo(pars: Foo) -> Result<JsValue, JsValue> {
    todo!()
}

Expected generated code:
/**
* @param {Foo} pars
* @returns {Promise<any>}
*/
export function foo(pars: Foo): Promise<any>;

export interface Foo {
  my_id: string
}

So far I found typescript_custom_section, but I don't understand how to do this:

The proc_derive_macro "MyTypescriptExport" can export its own #[wasm_bindgen(typescript_custom_section)] section, which would then be picked up by wasm-bindgen-cli

Is there an example or crate somewhere?
There's the rust-typescript-type-def crate, which can be used to generate the typescript definitions. But it's unclear how to wire the wasm-bindgen declarations with these types. Everything I attempted ends generating and referencing a separate definition.
typescript_type generates code as above, But then I've to define an empty type in Rust and parse it manually to the actual struct. I attempted using it on the actual struct, marking the fields with skip(), but this generated separate definitions:
export interface Foo {
  my_id: string
}

export class Foo {
  free(): void;
}

I could export the struct only normally (which would generate the second definition, with all the fields), but then if I understand correctly, I've to manage memory manually, which is not wanted.

Ok, I went through a proc macro tutorial and put this together: https://github.com/ivanschuetz/export_ts_macro
Appreciate feedback - is that the right direction? if yes, how to improve it? if not, what to do instead?

Someone recommended tsify to me, which solves this - so I'm closing this.


Update the oauth2 password grant to support client_secret

Earlier version of ESA supported passing the client_id and the client_secret values in the header. More recently this feature was changed to pass client_id in the request body, but in the process support for passing in a client_secret was removed entirely.
The OAuth server I use does not support generating a client_id without a client_secret, so this breaks my login flow unless I implement a custom client parser.
The spec suggests that the recommended way to accomplish this would be to pass both in the Authorization header as it was done before, but in the absence of the header it would be great to have the ability to pass in a client_secret value directly.
Alternatively, the spec dictates that the server must accept the HTTP Basic authentication scheme, so it may be easier to simply add a clientHeader value instead.

Thanks for the effort but ESA is not going to support client secrets.
This has been discussed several times before and the point is: if you put a secret in your JS app it's no longer a secret. If your server demands a secret, you'll need to use a proxy server that adds it into requests coming in from the web app (even then the secret is pointless though since anyone could call the proxy of course).

@marcoow So in that case just call the key theSecondPartOfClientIdWhichIsNotReallyASecretEvenThoughSomeServersMightCallItThat to reflect what it actually does. Or perhaps update your documentation to mention that you explicitly disallow use cases mentioned in the spec, because they use a word you think some people might find confusing, ideally in a place that is not in a PR comment that arose after trying to fix an issue after hours of debugging.
Or perhaps don't call this module the oauth2-password-grant since you're literally ignoring parts of the spec, because you think a word might confuse the dozen or so people that still use Ember for some horrific legacy reason. That way people that use the spec to validate their code with the assumption of "of course that lib that says it's oauth2 follows the spec" don't need to dig into some deeper modules of that lib to figure out that the authors have their own take on things.
Anyway, since it's clear that anyone involved in this library would rather stick to excuses than make the environment usable... for anyone comes here stuck because you have the misfortune of still using Ember with rails doorkeeper and a desire to identify your clients, you can get around it as so in your doorkeeper config. That way you don't have to fork your own copy of this module. For other servers good luck on your own:
  client_credentials :from_basic, lambda { |request|
    # TODO: Remove this if https://github.com/simplabs/ember-simple-auth/pull/2429 is merged
    if request.params["client_id"].present? && request.params["client_secret"].present?
      next request.params["client_id"], request.params["client_secret"]
    elsif request.params["client_id"].present?
      potential_auth_payload = request.params["client_id"]
      potential_decoded_payload = Base64.decode64(potential_auth_payload)
      is_base64 = potential_auth_payload.is_a?(String) && Base64.strict_encode64(potential_decoded_payload) == potential_auth_payload

      if is_base64
        parsed_payload = potential_decoded_payload.split(":")
        next parsed_payload.first, parsed_payload.last
      else
        next potential_auth_payload, ""
      end
    end
  }

Needless to say, my real recommendation is to wipe all traces of Ember from your codebase. You'll be glad you did.


Error on runtime in iOS

Using cordova 10.0.0 with iOS, simulator iPhone X running 13.7
CDVPlugin class SOSPicker (pluginName: ImagePicker) does not exist.
2020-09-16 12:54:00.655146-0700 PixelArt - RetroGraphics Sim[30194:1699991] ERROR: Plugin 'ImagePicker' not found, or is not a CDVPlugin. Check your plugin mapping in config.xml.
2020-09-16 12:54:00.655277-0700 PixelArt - RetroGraphics Sim[30194:1699991] FAILED pluginJSON = ["ImagePicker1026851624","ImagePicker","getPictures",[{"height":0,"outputType":0,"disable_popover":false,"maximumImagesCount":1,"title":"Select an Album","message":null,"width":800,"allow_video":false,"quality":100}]]
plugin is defined in config.xml:
"cordova": {
"plugins": {
...
"cordova-plugin-telerik-imagepicker": {
"PHOTO_LIBRARY_USAGE_DESCRIPTION": "Accesses photos for uploading photos"
}
...
nothing was added to the config.xml on install.  Experimented on adding manually with no help.

any update on this ? Same problem here

Using cordova 10.0.0 with iOS, simulator iPhone X running 13.7
CDVPlugin class SOSPicker (pluginName: ImagePicker) does not exist. 2020-09-16 12:54:00.655146-0700 PixelArt - RetroGraphics Sim[30194:1699991] ERROR: Plugin 'ImagePicker' not found, or is not a CDVPlugin. Check your plugin mapping in config.xml. 2020-09-16 12:54:00.655277-0700 PixelArt - RetroGraphics Sim[30194:1699991] FAILED pluginJSON = ["ImagePicker1026851624","ImagePicker","getPictures",[{"height":0,"outputType":0,"disable_popover":false,"maximumImagesCount":1,"title":"Select an Album","message":null,"width":800,"allow_video":false,"quality":100}]]
plugin is defined in config.xml:
"cordova": { "plugins": { ... "cordova-plugin-telerik-imagepicker": { "PHOTO_LIBRARY_USAGE_DESCRIPTION": "Accesses photos for uploading photos" } ...
nothing was added to the config.xml on install. Experimented on adding manually with no help.

I have the some problem :(


Stop accepting DiagnosticsNode as input from DevTools.

The merge should wait for DevTools 2.25.0

Tested Devtools > Inspector with this version of flutter:
https://github.com/flutter/flutter/assets/12115586/f06cb5e0-b831-4146-b3d9-70de6b0a3c3b


A way to get the nodes within a community

After a couple of iterations the final graph to be saved is a compressed version of the original one. How can I assign communities to all the original nodes in my graph given some level.

Have you solved the problem？@mahdeto


Glint doesn't work with the noPropertyAccessFromIndexSignature TypeScript option

Setting noPropertyAccessFromIndexSignature to true in tsconfig.json leads to strange errors in hbs files.

@dfreeman - this hasn't been fixed for the user's case:
import Component from '@glint/environment-ember-loose/glimmer-component';

class Model {
  [key: string]: any;
}

export default class Foo extends Component {
  public get foo(): Model {
    return new Model();
  }
}

{{this.foo.bar}}

app/foo.hbs:1:12 - error TS4111: Property 'bar' comes from an index signature, so it must be accessed with ['bar'].

1 {{this.foo.bar}}
             ~~~

That example seems to be working as expected to me—isn't that error exactly what you're asking TypeScript to flag by setting noPropertyAccessFromIndexSignature? 🙂
Wouldn't writing this.foo.bar in the backing class somewhere would give you the same error? I would expect to have to write {{get this.foo 'bar'}} in the template to avoid that error, given your model type and having that flag enabled.

hm, hadn't thought about that. Perhaps you're right... although people would most-likely want that compiler flag for their TypeScript code and not for the HBS templates... not sure. I'll leave the decision to you.


[linux] Driver component no longer builds (IDFGH-9375)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v5.1-dev-3296-g76433e4cb2
Operating System used.
Linux
How did you build your project?
Command line with CMake
If you are using Windows, please specify command line type.
None
What is the expected behavior?
The driver component no longer builds when setting linux as target.
What is the actual behavior?
CMake produces an error when trying to build the project
CMake Error at /home/vinci/esp/esp-idf/tools/cmake/component.cmake:479 (add_library):
  Cannot find source file:

    /home/vinci/esp/esp-idf/components/bootloader_support/src/bootloader_random_linux.c

Steps to reproduce.

Copy hello_world_linux_compatible
Add driver to requirements in main/CMakeLists.txt
idf_component_register(SRCS "hello_world_main.c" INCLUDE_DIRS "" REQUIRES driver)
idf.py --preview set-target linux
idf.py build

Build or installation Logs.
No response
More Information.
No response

Hi @higaski
As mentioned here, driver is not supported for simulation. You could add the cmock driver mocks we have by adding
list(APPEND EXTRA_COMPONENT_DIRS "$ENV{IDF_PATH}/tools/mocks/driver/")
to you project CMake file, which would allow you to link the driver (mock) component.
If you describe what you are trying to achieve by linking the driver component then maybe I can suggest a better suited  approach for you.

I just need the driver headers to not brick a x86 build, that's all.
I've previously been using a combination of the following two lines:
list(APPEND EXTRA_COMPONENT_DIRS tests $ENV{IDF_PATH}/tools/mocks/driver)

and
idf_component_register(
  ...
  REQUIRES
  driver
  ...
)

But that stopped working during the last couple of weeks. It produces the following CMake error
[0/1] Re-running CMake...-- Project is not inside a git repository, or git repository has no commits; will not use 'git describe' to determine PROJECT_VER.
-- Building ESP-IDF components for target linux
-- building DRIVER MOCKS (only SPI, I2C and GPIO driver)
-- Project sdkconfig file /home/vinci/Develop/VSCode/hello_world_linux_compatible/sdkconfig
-- building DRIVER MOCKS (only SPI, I2C and GPIO driver)
CMake Error at /home/vinci/esp/esp-idf/tools/cmake/component.cmake:313 (message):
  Include directory
  '/home/vinci/esp/esp-idf/components/driver/include/driver' is not a
  directory.
Call Stack (most recent call first):
  /home/vinci/esp/esp-idf/tools/cmake/component.cmake:481 (__component_add_include_dirs)
  /home/vinci/esp/esp-idf/tools/cmake/component.cmake:558 (idf_component_register)
  /home/vinci/esp/esp-idf/tools/mocks/driver/CMakeLists.txt:15 (idf_component_mock)

-- Configuring incomplete, errors occurred!
See also "/home/vinci/Develop/VSCode/hello_world_linux_compatible/build/CMakeFiles/CMakeOutput.log".
FAILED: build.ninja

Probably the folder structure of the component has changed but no one thought to adjust the mock? The driver mock components CMake sets an include_dirs variable like this
set(include_dirs
    "${original_driver_dir}/include"
    "${original_driver_dir}/include/driver"
    "${CMAKE_CURRENT_SOURCE_DIR}/../hal/include"
    "${CMAKE_CURRENT_SOURCE_DIR}/../esp_hw_support/include")

But the "/include/driver" folder doesn't seem to exist at the current master?

You are right, someone recently reorganized the driver and broke this. We'll take a look at it.
Meanwhile, another option when building for the linux target is to make requirements dynamic depending on the target, e.g. something like:
idf_build_get_property(target IDF_TARGET)

if(${target} STREQUAL "linux")
    set(REQS "")
else()
    list(APPEND REQS driver)
endif()

idf_component_register(...
                  REQUIRES ${REQS})

Of course, this may require some changes to your component as well if you are including/calling any of the driver functions.

list(APPEND EXTRA_COMPONENT_DIRS $ENV{IDF_PATH}/tools/mocks/driver) still doesnt work on linux simulation even after  https://github.com/espressif/esp-idf/commit/b68b0ea714e664f39801121f2786f447e2252e9c
cloning a fresh copy and building the hello-world with the preview target results in the same error

Works for me with ESP-IDF v5.2-dev-1890-g28167ea5a3

idf.py --preview set-target linux
halts with:
Cannot find source file:

    <redacted>/esp-idf/components/esp_mm/port/linux/ext_mem_layout.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm
  .ccm .cxxm .c++m .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90
  .f95 .f03 .hip .ispc
Call Stack (most recent call first):

AFAIK there is no esp_mm mock?


1.6.0 TypeError, 1.5.3 works

Describe the bug
A clear and concise description of what the bug is.
After upgrading from 1.5.3 to 1.6.0, we get the following error:
│ ❱ 201 │   │   related_pods = [pod["metric"]["pod"] for pod in related_pods_result]
TypeError: string indices must be integers, not 'str'
After checking v1.5.3 again, it works as expected.
To Reproduce
Steps to reproduce the behavior:
Unfortunately, I'm not sure how to reproduce other than running python .\krr.py simple on a working prometheus setup.
Expected behavior
I would expect to have same behavior as 1.5.3
Screenshots
If applicable, add screenshots to help explain your problem.

i'm willing to provide further data, or test release candidate fixes if needed

Hey, @EvertonSA!
Your error is a bit odd - custom_query returns something unexpected
Can you add
raise Exception(related_pods_result)

before
related_pods = [pod["metric"]["pod"] for pod in related_pods_result]

in robusta_krr/core/integrations/prometheus/metrics_service/prometheus_metrics_service.py, run it and then show me the resulted exception, to help me to understand what's going on? Thank you in advance

Also this might be somehow related to #127

@EvertonSA Can you try #150 ?

I confirm #150 150 works !


Check so all Devices use the connection attribute in the config

I think a testcase is needed here.
Possibly this can be moved to the Device superclass.

Done, made some tests of all classes that are used by the IComFactory


Wrap text inscriptions

Depends on #1054.
Before

After

Closing, I think I accidentally included these changes in another PR.


fix: body_type NONE_VALUE checks

Codecov Report
Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 6.36%. Comparing base (e3753db) to head (fc5e83c).
Report is 16 commits behind head on main.

Files
Patch %
Lines

midealocal/message.py
0.00%
1 Missing :warning:

Additional details and impacted files
@@           Coverage Diff            @@
##            main     #84      +/-   ##
========================================
- Coverage   6.38%   6.36%   -0.03%
========================================
  Files         77      77
  Lines       6605    6626      +21
========================================
  Hits         422     422
- Misses      6183    6204      +21

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


python310Packages.reolink-aio: 0.5.7 -> 0.5.8

Diff: https://github.com/starkillerOG/reolink_aio/compare/refs/tags/0.5.7...0.5.8
Changelog: https://github.com/starkillerOG/reolink_aio/releases/tag/0.5.8
Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 223885 run on x86_64-linux 1

3 packages built:

home-assistant-component-tests.reolink
python310Packages.reolink-aio
python311Packages.reolink-aio


Introduce a perform_now to run the task right away (instead of going to sidekiq queue)

Based on the docs, we could maintenance_tasks perform MyTask and it adds the task to the queue to be executed by a running sidekiq.
My proposal is to implement a maintenance_tasks perform_now MyTask which will execute inline. This way we could execute some stuff synchronous that is required for building phase, for example.

Could you explain a little better why you need to run this outside of the job runner and why the test environment would not be sufficient for that?

We have as part of dev up the maintenance_tasks perform MyTask to ensure that all the development environments will have ran the necessary tasks (at least once).
But right now it enqueues it to sidekiq, which requires to start the sidekiq in order to process it

that is way I came with perform_now, since in sidekiq perform enqueues the job and perform_now run it right away.
WDYT?

Maintenance tasks should not be run in development. They are made to change production data, not development data. If development data should also be changed I recommend using the db seeds to do so.
If your application is needing to use maintenance tasks to changed development data there is a chance this application database needs some rethinking.

as production reasons, I could see it used on building pipeline, easily replacing some migrations for example. But then I believe that you will say "use migrations".
So I am fine to close the issue.

Can't that be done using db/seeds.rb?


Coverage: give the choice between c8 and nyc

Clear and concise description of the problem
I observed huge coverage gaps when transitioning from Jest to Vitest, the reason coming from C8 not ignoring a few things:

types.ts were ignored by default in Jest and not in Vitest
*.entity.ts were ignored by default in Jest and not in Vitest
*.test.ts were ignored by default in Jest and not in Vitest
For includes/excludes, Vitest takes absolute paths, Jest accepts relative paths (that may lead to include or exclude paths not working and giving erroneous results in your coverage)
Comments are ignored by default in Jest and not in Vitest
Import lines are ignored by default in Jest and not in Vitest
Objects spread in multiple lines are considered as one line in Jest, and as many lines as there is in Vitest

The "deep reason" seems that Jest uses nyc, and Vitest uses c8, and they don't have the same way of running through the code to make the coverage report.
Besides, the way c8 does it (not ignoring comments) seems objectively wrong, because adding comments in any covered branch in any file will actually increase the code coverage when it really shouldn't. Same for multiple line objects.
Suggested solution
Give the choice to use nyc instead of c8.
Alternative
Fix c8? There is actually an issue dating from 2019 talking about the comments counted as covered here: https://github.com/bcoe/c8/issues/182
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

+1 for this.
I really like the idea of using c8. Using native v8 coverage will definitely be fast since no code instrumentation is needed. But in practice it just doesn't work that well.
In addition to all issues mentioned by @tqn-treezor, I have problems when testing codebase with multiple testing tools. I have a component library which is tested by using vitest for small unit tests, and Cypress Component Test Runner for integration/behaviour testing. When merging the lcov reports generated by nyc and c8 the final coverage report is a complete mess. V8 coverage calculation is so much different. I had no other options than disabling whole vitest coverage of the project. :expressionless:
Having an option for choosing between c8 and nyc would be great.

+1

I think all described point are true only because Jest has configured nyc to run this way. I'm sure if we just swap them nothing will really change. The problem is with default configuration, and not with the coverage tool.

It does not happen in Jest because it is configured by Jest. What is the difference between us configuring v8 and nyc? One is already configured but not correctly, it seems. But at least it is already an integral part of Vitest, that we can improve.

It does not happen in Jest because it is configured by Jest. What is the difference between us configuring v8 and nyc? One is already configured but not correctly, it seems. But at least it is already an integral part of Vitest, that we can improve.

It does not happen in Jest because it is configured by Jest. What is the difference between us configuring v8 and nyc? One is already configured but not correctly, it seems. But at least it is already an integral part of Vitest, that we can improve.

I got same problem ，and in Vitest React Testing Lib Example  coverage is incorrect。

What is the difference between us configuring v8 and nyc? One is already configured but not correctly, it seems.

I'm not expert here so please correct me if there's something misunderstood. So, mostly thinking out loud:
Difference between v8 report and any other AST based instrumented code coverage (like nyc) is the ability to actually understand where we need to collect the coverage from. "Coverage counters" are not injected on unnecessary lines.
The v8 coverage report includes every single line. v8-to-istanbul (used by c8) does not remove empty lines, comments, import statements etc. It's a simple conversion. It does not implement such functionality and is not configurable in such way. This means that adding empty lines or more comments will increase code coverage.
I'm happy to help with this issue but quite unsure where to start from, if c8 is the way to go. My use case here is to be able to use vitest in addition to Cypress.

I guess the best solution might be we decouple the coverage logic, and make a provider interface for c8 and nyc to make them interchangeable. I currently don't have enough bandwidth to work on it, counting on someone interested in giving it a try.

I guess the best solution might be we decouple the coverage logic, and make a provider interface for c8 and nyc to make them interchangeable. I currently don't have enough bandwidth to work on it, counting on someone interested in giving it a try.

I am not sure its possible to run c8 with browser? I wouldn’t want people to have different coverage reports depending on the environment.

--browser would likely only support nyc on manual runs but if it's being run in a controlled env, like browser automation / CI, wouldn't it be exporting a c8 like format (at least for chromium-based browsers in puppeteer/playwright: https://playwright.dev/docs/api/class-coverage and https://github.com/bcoe/c8/issues/162#issuecomment-1047228152)?

[...] but I am not sure its possible to run c8 with browser?

Exactly as @bjarkihall mentioned here, c8 limits us to use Chromium/v8 based browsers. Chromium's Profiler is used to actual coverage collection, and c8 is used for coverage report creation. Some early thoughts from couple of months ago here https://github.com/vitest-dev/vitest/issues/586#issuecomment-1079891842.
Coverage logic decoupled, actions depending on which coverage tool is chosen by user:

Before starting vite server:

nyc: instrument code with istanbul
c8: no actions

Before tests are run:

nyc: no actions
c8: toggle require('v8').takeCoverage()

Run tests
Before closing up:

nyc: Collect the coverage from global __coverage__ variable and process it with istanbul. By default this seems to be added to window so there might be some work-arounds or configuration required.
c8: Generate report using c8/lib/report

I think the integration itself will be on istanbul rather than nyc, but naming the API could as well be called nyc I guess.
When c8 is chosen and browser tests are run, maybe log warning related to coverage not being collected.
I did some testing with vitest + vite-plugin-istanbul + istanbul-packages, https://stackblitz.com/edit/vitest-dev-vitest-3sysd2?file=vite.config.ts,README.md. Sourcemaps are still off but at least empty lines are not picked as covered.


How to use functions from ML?

Could you please provide an example (or even an implementation) of how to use functions from the ML package, e.g. the Microsoft.Spark.ML.Feature.Bucketizer class?

I was looking at how PySpark implements the ML functions, it seems that they use numpy and do some of the work on the client but I'm not 100% - will carry on trying to figure it out!

Typically, these functions run on worker nodes. However, it seems that Spark Connect currently supports SQL functions only. All supported functions contain a flag in their documentation that states 'Supports Spark Connect', e.g.

Functions from the MLLib do not contain this flag, e.g.

This seems to be a major limitation of Spark Connect as of today. The documentation says that more functions will be added in future versions of Spark.

i'll keep this open and add them in when they are available

There is an open pr for adding ml functions to spark connect, once this is merged in we should be able to implement the functions:
https://github.com/wbo4958/spark/pull/5


Value.matches() should evaluate to 0 and with Case(): should never be active

In commit ef2e9fa809fd8971820ac2ad8ad084ac9c8589d4, the behavior of Value.matches() was changed to be the same as with m.Case():, which is to return C(1) (viz. to always execute).
However, this is clearly wrong if you think about the expansion of e.g. v.matches(a, b, c) which is (v==a) | (v==b) | (v==c). To make the expansion meaningful when no arguments are provided, it should be C(0) | (v==a) | (v==b) | (v==c), meaning returning C(0) in the no-argument case. By the same logic, the case block should never execute.
The behavior of the two constructs should stay equivalent and the behavior of with m.Case(): should be changed alongside Value.matches(). It is unfortunate that this wasn't caught before the release. Both semantics precede the current RFC process, which would have likely prevented the mistake.

My proposal is to add a warning for both Value.matches() and with m.Case(): in the 0.4.1 patch release, and then fix it in the 0.5 release.

RFC #39 has been merged and this change is now tracked in #1021.


Keep getting "random user" notification

Actual Behavior
We keep getting
⚠ This pull request got rebased on behalf of a random user of the organization.
This behavior will change on the 1st February 2023, Mergify will pick the author of the pull request instead...

Expected Behavior
It's long past February 1st. Could we stop receiving this message? It's repetitive and became a bit annoying.
Specifications

Pull Request URL: many, but here's one example: https://github.com/haskell/cabal/pull/8720
Mergify Config URL: https://github.com/haskell/cabal/blob/ef1e12c9a3d423239644e58385aa25b56bc3bbb3/.github/mergify.yml

I'd like to bump this issue. Since reporting, I thought that a workaround is available, which in my mind was to explicitly set update_bot_account. Today I learned that it's a Premium feature. We're an open source project and don't have means to get Premium. Do we have to keep seeing the warning message forever?

Seems resolved now.


[FEAT]Specification for User Table Database Plan with Seeding and Migration Support using TypeORM

Description:
Design and implement a structured database schema for managing user data in a Nest.js application using TypeORM. Include functionality to seed initial user data and ensure the database setup supports easy configuration switching and migration management.
Acceptance Criteria

The User table is successfully created in PostgreSQL using Nest.js and TypeORM.
Initial user data is seeded into the database.
Migrations are written and successfully applied to update the database schema.
Comprehensive documentation is provided for setup, configuration, and maintenance of the database schema, migrations, and seeding process within a Nest.js application.

Requirements:
1.  Database Schema Design:

Create a User table schema with the following fields

id: Primary key, auto-incremented integer.
username: Unique username of the user.
email: Unique email address of the user.
password: Hashed password of the user.
createdAt: Timestamp indicating when the user record was created.
updatedAt: Timestamp indicating when the user record was last updated.

Column Name
Data Type
Constraints

id	UUID
Primary Key
Default: UUID Generate

username
VAR(50)
Unique, Not Null

email
VAR(20)
Unique, Not Null

password
VAR(50)
Not Null

firstName
VAR(50)
Not Null

lastName
VAR(50)
Not Null

createdAt
TIMESTAMP
Default: Current Timestamp

updatedAt
TIMESTAMP
Default: Current Timestamp, On Update

2. Nest.js and TypeORM Setup:

Integrate Nest.js with TypeORM for seamless database connectivity.
Configure Nest.js application to connect to PostgreSQL.
Utilize environment variables for flexible database configuration (e.g., host, port, username, password)

Database Configuration Data

  import { DataSource } from 'typeorm';
      import { User } from './entities/User';
const AppDataSource = new DataSource ({
type:  'postgres', // Change to your desired database type
host:  process.env.DB_HOST || 'localhost',
port:  Number(process.env.DB_PORT) || 5432,
username:  process.env.DB_USER || 'user',
password:  process.env.DB_PASSWORD || 'password',
database:  process.env.DB_NAME || 'mydatabase',
entities:  [User],
synchronize:  true, // Set to false in production
logging:  true,
});

3. Seeding Initial Data:

Implement a seeding mechanism to populate initial user data into the User table.
Seed at least one or two users for testing and development purposes.
Ensure the seeding process is automated and reproducible, leveraging Nest.js seeders or migrations.

Seeding Script

     import AppDataSource from './data-source'; // Adjust import as necessary
  import { User } from './entities/User';
const seedUsers = async () => {
const userRepository = AppDataSource.getRepository(User);
const users = [
{
username: 'poche',
email<EMAIL_ADDRESS>password: 'securepassword', // Use hashed password in production
firstName: 'paul',
lastName: 'Orife',
},
{
username: 'Fraciss',
email<EMAIL_ADDRESS>password: 'securepassword', // Use hashed password in production
firstName: 'Francis',
lastName: 'Smith',
},
];
await AppDataSource.initialize();
for (const user of users) {
await userRepository.save(user);
}
console.log('Seeded users successfully');
await AppDataSource.destroy();
};

4. Migration Strategy:

Utilize TypeORM migration capabilities for managing database schema changes.
Develop migrations to create the initial User table schema and handle future schema.
Ensure migrations are unchanged and can be executed sequentially to update the database schema from any previous state.

5. Environment Flexibility:

Design database setup to facilitate easy switching of default PostgreSQL configurations.
Document environment variables required for configuring different database environments (e.g., development, testing, production).
Provide scripts or instructions for initializing the database and running migrations in different environments.

6. Testing and Documentation:

[ ] Implement comprehensive unit tests for database operations (CRUD on User table, seeding process).
[ ] Include troubleshooting steps and best practices for maintaining the database schema and managing migrations within a Nest.js application context.

6. Additional Considerations:

Performance Optimization: Optimize database queries and indexing for efficient User table operations.
*** Security***: Implement secure password hashing and validation procedures.
*** Scalability***: Design the schema to accommodate future enhancements or additional user-related features.

7. Dependencies:

Nest.js (latest version)
TypeORM (latest version)
PostgreSQL (or compatible database)
Node.js environment

References:

Nest.js Documentation: [ https://docs.nestjs.com/ ]
TypeORM Documentation: [ https://orkhan.gitbook.io/typeorm/docs/entities ]
PostgreSQL Documentation: [ https://www.postgresql.org/docs/current/ ]

All db tasks are not testable


Device will not flash WS01

I'm trying to flash an Esicoo WS01 device which I was able to successfully flash 1 month ago on a raspberry pi. This time, I'm trying to use a laptop with new plugs that I just purchased. The FCC ID is the same as the last one so I can only assume that it still uses an ESP.
From the logs, it seems like the device will not connect at all to the ap. Not sure if it is because the firmware is patched or if its because my setup on my laptop isn't correct.
My phone connects just fine to the ap.
smarthack-mqtt.log
smarthack-wifi.log
smarthack-udp.log
smarthack-psk.log
smarthack-web.log

It appears that the device has been changed to no longer be Tuya, but instead uses the cloud intelligence app.

The FCC ID is the same as the last one so I can only assume that it still uses an ESP.

Unfortunately this is not a safe assumption. There have been many reported cases of willful FCC violations by these companies.

It appears that the device has been changed to no longer be Tuya, but instead uses the cloud intelligence app.

Too bad, hopefully you can still find ESP based devices in your area. Best of luck.


Add each interpolate as their own file in build

I think it would be great to not have to get all the interpolation methods when we just want one (it's linked to https://github.com/d3/d3-color/issues/15)
Lodash does it very well:
// load the modern build
var _ = require('lodash');
// or a method category
var array = require('lodash/array');
// or a method (great for smaller builds with browserify/webpack)
var chunk = require('lodash/array/chunk');

So it would mean that instead of:
var interpolateRound = require('d3-interpolate').interpolateRound

We could do:
var interpolateRound = require('d3-interpolate/interpolateRound')

Which, in this case, is 630 less loc to add to the final build.
I think it might be a problem with all the new d3 repos, I'm happy to add PRs this week if you're keen with the change.

Please do this by creating your own index.js file (or editing the existing one) and running d3-bundler (which is just a thin wrapper on Rollup). I have no plans to supports finer-grained modules using anything other than ES6 modules.


Remove fomantic grid module

Removed the grid module and moved the used parts it into our own CSS, eliminating around 75% unused CSS in turn.

Don't know how you managed to pick these styles out ..... Over all LGTM.

Through tedious searching the classes in the code :)

Draft until I add comments.

Comments added, only "grid" and "message" are currently pure copy-paste from fomantic, more likely to follow.


Sonarcube fixes

Codecov Report

Merging #426 into master will decrease coverage by 34.83%.
The diff coverage is 64%.

@@              Coverage Diff              @@
##             master     #426       +/-   ##
=============================================
- Coverage     85.21%   50.37%   -34.84%
+ Complexity     2278     1439      -839
=============================================
  Files           159      159
  Lines          6865     6858        -7
  Branches       1024     1022        -2
=============================================
- Hits           5850     3455     -2395
- Misses          694     3162     +2468
+ Partials        321      241       -80

Impacted Files
Coverage Δ
Complexity Δ

...cecenter/xenon/adaptors/webdav/WebdavLocation.java
57.14% <ø> (-17.86%)
3 <0> (-2)

...nter/xenon/adaptors/ssh/SshMultiplexedSession.java
5.55% <ø> (-68.75%)
1 <0> (-32)

...r/xenon/adaptors/gridengine/GridEngineAdaptor.java
100% <ø> (ø)
3 <0> (ø)
:arrow_down:

...ecenter/xenon/engine/files/PathImplementation.java
82.85% <ø> (ø)
16 <0> (ø)
:arrow_down:

...nter/xenon/adaptors/scripting/ScriptingParser.java
94.69% <ø> (ø)
50 <0> (ø)
:arrow_down:

...ncecenter/xenon/adaptors/torque/TorqueAdaptor.java
100% <ø> (ø)
3 <0> (ø)
:arrow_down:

...iencecenter/xenon/adaptors/local/LocalAdaptor.java
79.16% <ø> (-20.84%)
10 <0> (-3)

...xenon/adaptors/slurm/SlurmSchedulerConnection.java
26.59% <ø> (-51.32%)
32 <0> (-45)

.../nl/esciencecenter/xenon/adaptors/ssh/SshJobs.java
17.77% <ø> (-73.44%)
5 <0> (-23)

.../esciencecenter/xenon/adaptors/ftp/FtpAdaptor.java
80% <ø> (-10%)
4 <0> (-2)

... and 92 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 84a5ca3...738448a. Read the comment docs.


⚠ Secret Website 3 has degraded performance

In 07077ff, Secret Website 3 ($SECRET_WEBSITE_3) experienced degraded performance:

HTTP code: 200
Response time: 1961 ms

Resolved: Secret Website 3 performance has improved in e422df5.

Resolved: Secret Website 3 performance has improved in e422df5.


minify/cleanup source?

Is there a way to minify generated html source e.g. if you open below URL in chrome you'll notice a lot of whitespaces.
view-source:https://learn.netlify.app/en/

https://gohugo.io/hugo-pipes/minification/

@fritzmg Thanks! Using --minify flag did the trick.


some bugs

Hi,Professors.There some bugs when I run the code.Can you explain what they mean and how to solve the problems? Thank you very much!
Using gpu: 0
Files already downloaded and verified
Files already downloaded and verified
Order name:./logs/cifar100_nfg50_ncls10_nproto20_mnemonics/seed_1993_cifar100_order_run_0.pkl
Generating orders
pickle into ./logs/cifar100_nfg50_ncls10_nproto20_mnemonics/seed_1993_cifar100_order_run_0.pkl
[68, 56, 78, 8, 23, 84, 90, 65, 74, 76, 40, 89, 3, 92, 55, 9, 26, 80, 43, 38, 58, 70, 77, 1, 85, 19, 17, 50, 28, 53, 13, 81, 45, 82, 6, 59, 83, 16, 15, 44, 91, 41, 72, 60, 79, 52, 20, 10, 31, 54, 37, 95, 14, 71, 96, 98, 97, 2, 64, 66, 42, 22, 35, 86, 24, 34, 87, 21, 99, 0, 88, 27, 18, 94, 11, 12, 47, 25, 30, 46, 62, 69, 36, 61, 7, 63, 75, 5, 32, 4, 51, 48, 73, 93, 39, 67, 29, 49, 57, 33]
Out_features: 50
Batch of classes number 5 arrives
Max and min of train labels: 0, 49
Max and min of valid labels: 0, 49
Checkpoint name: ./logs/cifar100_nfg50_ncls10_nproto20_mnemonics/run_0_iteration_4_model.pth
Incremental train
Epoch: 0, LR: [0.1]
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [3,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [4,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [5,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [6,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [7,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [8,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [9,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [12,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [13,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [17,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [19,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [21,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [22,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [23,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [26,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [28,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [29,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [30,0,0] Assertion t >= 0 && t < n_classes failed.
/opt/conda/conda-bld/pytorch_1603729138878/work/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [31,0,0] Assertion t >= 0 && t < n_classes failed.
Traceback (most recent call last):
File "main.py", line 78, in
trainer.train()
File "/data1/22160073/project/incremental learning/class-incremental-learning-main/mnemonics-training/1_train/trainer/mnemonics.py", line 237, in train
tg_model = incremental_train_and_eval(self.args.epochs, tg_model, ref_model, free_model, ref_free_model, tg_optimizer, tg_lr_scheduler, trainloader, testloader, iteration, start_iter, cur_lamda, self.args.dist, self.args.K, self.args.lw_mr)
File "/data1/22160073/project/incremental learning/class-incremental-learning-main/mnemonics-training/1_train/trainer/incremental.py", line 44, in incremental_train_and_eval
loss.backward()
File "/data1/22160073/anaconda3/envs/xxz/lib/python3.7/site-packages/torch/tensor.py", line 221, in backward
torch.autograd.backward(self, gradient, retain_graph, create_graph)
File "/data1/22160073/anaconda3/envs/xxz/lib/python3.7/site-packages/torch/autograd/init.py", line 132, in backward
allow_unreachable=True)  # allow_unreachable flag
RuntimeError: CUDA error: device-side assert triggered

Thank you for your interest in our work.
Since this is an error caused by CUDA, I don't know how to fix it.
May I know if you are using the same version of python and pytorch as we are?

Thanks for your reply.I will try to use the same version of python and pytorch as yours.

I had the same problem with the new version of Pytorch. There are two solutions:

First, use the author's lower version of the pytorch environment (i.e. torch=0.4.0,python=3.6.8): same version of python and pytorch;
Second, modify the code to accommodate the higher version of the pytorch environment (torch=1.10.0+cu113 in my test environment).

Modify lines 62 to 65 in baseline.py:
`
  import torch
  torch_version = torch.__version__

  if '0.4.0' in str(torch_version):
        X_train_total = np.array(self.trainset.train_data)
        Y_train_total = np.array(self.trainset.train_labels)
        X_valid_total = np.array(self.testset.test_data)
        Y_valid_total = np.array(self.testset.test_labels)
  else:
        X_train_total = np.array(self.trainset.data)
        Y_train_total = np.array(self.trainset.targets)
        X_valid_total = np.array(self.testset.data)
        Y_valid_total = np.array(self.testset.targets)

`
Modify lines 188 to 189 in baseline.py:
`
 if '0.4.0' in str(torch_version):
            self.trainset.train_data = X_train.astype('uint8')
            self.trainset.train_labels = map_Y_train
else:
            self.trainset.data = X_train.astype('uint8')
            self.trainset.targets = map_Y_train

`

It is important to store the mapped label in self.trainset.targets, otherwise it will store the ID of the original Class, which will cause the label range to be out of line when calculating nn.CrossEntropyLoss in incremental.py, i.e., the above error.
Finally, you need to modify the code that corresponds to the set of tests and calculations in baseline.py. (Similar modification to mnemonics.py)


Feature request: linkedIn support

I see that you add a lot of new services in the upcoming beta release. Would it be possible to include also linkedin?

All PRs are welcome! 😉👍🏻


Trying second pull request, after first didn't pass tests

I'm merging this into a branch of the repo so I can fix the flake checks

@AndrewGibbs: As I guess we want this merged by tomorrow, I figured it was easier to fix it for you but for next time (see https://github.com/ca-knowledgebase/ca-knowledgebase.github.io/pull/119): the flake checks enforce common Python styling choices, in an aim to keep the code we have on the site consistent looking. The most common ones that fail are about how many spaces flake like before/after things.
To interpret the failures, you can click "Details" next to the failing test. Then you'll see lots of lines like:
tutorials/bem/quick_BEM3.ipynb#In[2]:2:20: E231 missing whitespace after ','
This line (for example) is saying that in cell [2] of the file tutorials/bem/quick_BEM3.ipynb, line 2 character 20 there is a missing whitespace after a comma.
I've opened an issue to remind myself to put something about flake in the contributing guide: https://github.com/ca-knowledgebase/ca-knowledgebase.github.io/issues/120

Ah I see! Thank you for fixing this @mscroggs. I am mostly self-taught in Python, so wasn't really aware of what the conventions are, but it certainly sounds like good practice to have all of our code following those.


Creator and publisher missing in generated docs

See here https://nfdi4cat.github.io/voc4cat/v2023-08-17/voc4cat/
The turtle representation has the data; they are just not added to the generated HTML.
Related: https://github.com/nfdi4cat/voc4cat-tool/issues/154

However, the data (url) for publisher and creator are incorrect. They still use example.com. But without showing them no one could notice...


Fix problems with COBC-EDU protocol

Fixes #242

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

Comparison is base (1f6186f) 87.35% compared to head (3d486b9) 87.35%.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #243   +/-   ##
=======================================
  Coverage   87.35%   87.35%
=======================================
  Files          18       18
  Lines         514      514
=======================================
  Hits          449      449
  Misses         65       65

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


[ci] Fix rebuild tagging error

There's some error causing an error on rebuild tagging for skipped l1-contracts runs. Seems related to tag_remote_image and calling out to AWS

appears this issue was caused by the ecr registry hitting the upper bound of 1000 tags for 1 image, as a temp fix ive just deleted the tags. More perm solution is probably to start automatic image pruning

I'll call this one done and open a new issue. Thanks!!


Censored RVs

This PR implements logprob for censored (clipped) RVs.
x_rv = at.random.normal(0, 1)
cens_x_rv = at.clip(x_rv, -1, 1)
cens_x = cens_x_rv.type()
logp = ppl.joint_logprob(cens_x_rv, {cens_x_rv: cens_x})

I placed the new methods and tests inside truncation.py, expecting this file wil also contain the methods for truncated RVs in the future.

Some things are still not working well / missing:

[ ] Issues with broadcasting / sizes (see xfailed tests)
[ ] Propagate names in logp graph
[ ] Canonicalize set_subtensors to clip x[x>ub] = ub -> clip(x, x, ub)
[ ] Add tests for logcdf methods

To make broadcasting work, you should be able to use something like at.broadcast_arrays(value, lower_bound, upper_bound) in the log-probability calculation.

Canonicalize set_subtensors to clip x[x>ub] = ub -> clip(x, x, ub)

That's a very interesting idea!  Can it be combined with other indices (e.g. x[idx_1, ..., x > ub, ..., idx_N] = ...)?
Regardless, don't make this PR conditional on such extensions.  Let's get at.clip working and merged first.

Tip: if you assign names to your test Variables, it can be much easier to read the aesara.dprint output when debugging.  Same with Variables created in the functions you're working on (e.g. in censor_logprob and/or censor_rvs).
Also, don't forget about test values!  They will cause errors to arise during graph construction (i.e. where the symbolic objects themselves are defined).  That combined with aesara.config.print_test_value = True can make things a lot easier.

To make broadcasting work, you should be able to use something like at.broadcast_arrays(value, lower_bound, upper_bound) in the log-probability calculation.

Still couldn't figure out my test_broadcasted_censoring failing test. These are the fgraphs printouts before and after the optimization phase in joint_logprob:
 |InplaceDimShuffle{x} [id B] ''   3
 | |normal_rv.1 [id C] 'x_rv'   2
 |   |RandomStateSharedVariable(<RandomState(MT19937) at 0x7F64081A3440>) [id D]
 |   |TensorConstant{[]} [id E]
 |   |TensorConstant{11} [id F]
 |   |TensorConstant{0} [id G]
 |   |TensorConstant{2} [id H]
 |InplaceDimShuffle{x} [id I] ''   1
 | |uniform_rv.1 [id J] 'lb_rv'   0
 |   |RandomStateSharedVariable(<RandomState(MT19937) at 0x7F642C9B3A40>) [id K]
 |   |TensorConstant{[]} [id L]
 |   |TensorConstant{11} [id M]
 |   |TensorConstant{0} [id N]
 |   |TensorConstant{1} [id O]
 |TensorConstant{(2,) of 1} [id P]

After:
censored_rv.1 [id A] 'cens_x_rv'   5
 |RandomStateSharedVariable(<RandomState(MT19937) at 0x7F64081A3440>) [id B]
 |TensorConstant{[]} [id C]
 |TensorConstant{11} [id D]
 |InplaceDimShuffle{x} [id E] ''   4
 | |TensorConstant{0} [id F]
 |InplaceDimShuffle{x} [id G] ''   3
 | |TensorConstant{2} [id H]
 |uniform_rv.1 [id I] ''   2
 | |RandomStateSharedVariable(<RandomState(MT19937) at 0x7F642C9B3A40>) [id J]
 | |TensorConstant{[]} [id K]
 | |TensorConstant{11} [id L]
 | |InplaceDimShuffle{x} [id M] ''   1
 | | |TensorConstant{0} [id N]
 | |InplaceDimShuffle{x} [id O] ''   0
 |   |TensorConstant{1} [id P]
 |TensorConstant{(2,) of 1} [id Q]

I seem to be loosing the reference to the lb_rv before I even get to my censor_rvs opt. This is caused by the local_dimshuffle_rv_lift. During interactive debugging:
lower_bound.owner.tag
# scratchpad{'imported_by': ['local_dimshuffle_rv_lift']}

Also that opt seems to not propagate the variable name
lower_bound.name
# None

Also, don't forget about test values! They will cause errors to arise during graph construction (i.e. where the symbolic objects themselves are defined). That combined with aesara.config.print_test_value = True can make things a lot easier.

If I set tthe flag to "warn", even a simple unform logp raises a lot of "Cannot compute test value..." for every node in the logp. Is this something we need to address?
@aesara.config.change_flags(compute_test_value='warn')
def test_compute_test_value():
    x_rv = at.random.uniform(-1, 1)
    x = x_rv.type()
    logp = joint_logprob(x_rv, {x_rv: x})

=============================== warnings summary ===============================
tests/test_truncation.py::test_compute_test_value
  /home/ricardo/Documents/Projects/aeppl/venv/lib/python3.8/site-packages/aesara/graph/op.py:272: UserWarning: Warning, Cannot compute test value: input 0 (<TensorType(float64, scalar)>) of Op Elemwise{ge,no_inplace}(<TensorType(float64, scalar)>, TensorConstant{-1}) missing default value
    compute_test_value(node)

tests/test_truncation.py::test_compute_test_value
  /home/ricardo/Documents/Projects/aeppl/venv/lib/python3.8/site-packages/aesara/graph/op.py:272: UserWarning: Warning, Cannot compute test value: input 0 (<TensorType(float64, scalar)>) of Op Elemwise{le,no_inplace}(<TensorType(float64, scalar)>, TensorConstant{1}) missing default value
    compute_test_value(node)

tests/test_truncation.py::test_compute_test_value
  /home/ricardo/Documents/Projects/aeppl/venv/lib/python3.8/site-packages/aesara/graph/op.py:272: UserWarning: Warning, Cannot compute test value: input 0 (Elemwise{ge,no_inplace}.0) of Op Elemwise{and_,no_inplace}(Elemwise{ge,no_inplace}.0, Elemwise{le,no_inplace}.0) missing default value
    compute_test_value(node)

tests/test_truncation.py::test_compute_test_value
  /home/ricardo/Documents/Projects/aeppl/venv/lib/python3.8/site-packages/aesara/graph/op.py:272: UserWarning: Warning, Cannot compute test value: input 0 (<TensorType(float64, scalar)>) of Op Elemwise{second,no_inplace}(<TensorType(float64, scalar)>, Elemwise{neg,no_inplace}.0) missing default value
    compute_test_value(node)

tests/test_truncation.py::test_compute_test_value
  /home/ricardo/Documents/Projects/aeppl/venv/lib/python3.8/site-packages/aesara/graph/op.py:272: UserWarning: Warning, Cannot compute test value: input 0 (Elemwise{and_,no_inplace}.0) of Op Elemwise{switch,no_inplace}(Elemwise{and_,no_inplace}.0, Elemwise{second,no_inplace}.0, TensorConstant{-inf}) missing default value
    compute_test_value(node)

tests/test_truncation.py::test_compute_test_value
  /home/ricardo/Documents/Projects/aeppl/aeppl/joint_logprob.py:170: UserWarning: Warning, Cannot compute test value: input 0 (<TensorType(float64, scalar)>) of Op Elemwise{second,no_inplace}(<TensorType(float64, scalar)>, Elemwise{neg,no_inplace}.0) missing default value
    compute_test_value(node)

tests/test_truncation.py::test_compute_test_value
  /home/ricardo/Documents/Projects/aeppl/aeppl/joint_logprob.py:170: UserWarning: Warning, Cannot compute test value: input 0 (<TensorType(float64, scalar)>) of Op Elemwise{le,no_inplace}(<TensorType(float64, scalar)>, TensorConstant{1}) missing default value
    compute_test_value(node)

tests/test_truncation.py::test_compute_test_value
  /home/ricardo/Documents/Projects/aeppl/aeppl/joint_logprob.py:170: UserWarning: Warning, Cannot compute test value: input 0 (<TensorType(float64, scalar)>) of Op Elemwise{ge,no_inplace}(<TensorType(float64, scalar)>, TensorConstant{-1}) missing default value
    compute_test_value(node)

tests/test_truncation.py::test_compute_test_value
  /home/ricardo/Documents/Projects/aeppl/aeppl/joint_logprob.py:170: UserWarning: Warning, Cannot compute test value: input 0 (Elemwise{ge,no_inplace}.0) of Op Elemwise{and_,no_inplace}(Elemwise{ge,no_inplace}.0, Elemwise{le,no_inplace}.0) missing default value
    compute_test_value(node)

tests/test_truncation.py::test_compute_test_value
  /home/ricardo/Documents/Projects/aeppl/aeppl/joint_logprob.py:170: UserWarning: Warning, Cannot compute test value: input 0 (Elemwise{and_,no_inplace}.0) of Op Elemwise{switch,no_inplace}(Elemwise{and_,no_inplace}.0, Elemwise{second,no_inplace}.0, TensorConstant{-inf}) missing default value
    compute_test_value(node)

-- Docs: https://docs.pytest.org/en/stable/warnings.html
======================== 1 passed, 10 warnings in 0.97s ========================

Process finished with exit code 0
PASSED                       [100%]

Is this something we need to address?

It looks like you need to set s test value for x, or use x_rv.clone().

I added tests for the logcdf methods and checked whether the new opts work with compute_test_value="raise.
The only thing missing are the broadcasting / local_dimshuffle_rv_lift related issues I described in https://github.com/aesara-devs/aeppl/pull/22#issuecomment-870377413

That uniform_rv.1 in the "After graph" is no longer related to the original one.
This is caused by the local_dimshuffle_rv_lift. During interactive debugging:
lower_bound
# uniform_rv.out

lower_bound in rv_map_feature.rv_values
# False

lower_bound.owner.tag
# scratchpad{'imported_by': ['local_dimshuffle_rv_lift']}

Also that opt seems to not propagate the variable name
lower_bound.name
# None

Ah, yeah, that would definitely cause such a problem; however, PreserveRVMappings is supposed to take care of that, so the question I would ask is "Why isn't PreserveRVMappings.on_change_input catching this case?".

Thinking a bit more about the generating models in the broadcasted test examples I wrote, I think it only makes sense to create a logprob graph when the base random variable has the same shape as the clipped output.
# Scalar base, vector random bound - SUCCEEDS
lb_rv = at.random.normal(0, 1, size=2)
x_rv = at.random.normal(0, 2)
cens_x_rv = at.clip(x_rv, lb_rv, [1, 1])

# Scalar base, vector bound - FAILS
lb_rv = at.random.uniform(0, 1, name="lb_rv")
x_rv = at.random.normal(0, 2, name="x_rv")
cens_x_rv = at.clip(x_rv, lb_rv, [1, 1])

# Vector base RV, vector bound - FAILS
lb_rv = at.random.normal(0, 1, name="lb_rv")
x_rv = at.random.normal(0, 2, size=2, name="x_rv")
cens_x_rv = at.clip(x_rv, lb_rv, [1, 1])

The logprob extraction for the first two graphs should fail because the two (generated) values in cens_x_rv are not independent (they are just broadcasted). In contrast, the logprob extraction for last graph should succeed, since each observation corresponds to a new independent factor.
Is there a way to distinguish between these during the rewrite phase?

Is there a way to distinguish between these during the rewrite phase?

Perhaps we could check the RandomVariable.ndim_supp and broadcasted shape/number of dimensions of the censored variable and compare that with the other clipped arguments.  We know that Clip will simply broadcast all its arguments, so, when the censored variable is a set of independent variates—e.g. when size is non-None or multiple independent distribution parameters are provided—that matches the broadcast dimensions of Clip's other arguments, we can probably say that the censoring itself is broadcasted (and not "correlated").


Data loading issue and width problem

I have an issue for data loading for this I directly pass the data in data property of kline chart but it unable to load graph it just showing Loading.... Should it required to fetch graph data from GET url? If I directly append data in kline so what was the issue for not viewing, reply. Data is showing I know its not complete but it unable to view anything in chart panel.

And for the width for stylying graph to 100% is not making change it does constant width and height that defines while initialization of graph properties, how am I fix this?.

How did you solve the problem？


Advance Search block should work, by redirecting the user to the page with the view if used on a page where the view is not present

This will only work with blocks that are associated with a 'page view' as it needs a page to redirect to.

I think I encounter this issue, just wondering if the URL gets changed with the query string when the Search button is pressed ? If not, it's either because of the "Use Ajax" under Advanced Tab in the view need to be set to "Yes" and the Facet blocks need to be placed in the page as well. Hope this can help.

Forgot to close this after it was fixed by this pull


Support for app router

I'm using the next.js app router and Nextra doesn't quite work with that yet.
next.config.mjs:
import nextra from 'nextra'

/**
 * @type {import('next').NextConfig}
 */
const nextConfig = {
  distDir: './.next', // Nextra supports custom `nextConfig.distDir`
  reactStrictMode: true,
  pageExtensions: ["js", "jsx", "ts", "tsx", "mdx"],
  experimental: {
    appDir: true,
    mdxRs: true,
    // once this makes it into a release: https://github.com/vercel/next.js/pull/51755
    //   serverActions: true,
    //   serverActionsBodySizeLimit: '5mb',
  },
}

const withNextra = nextra({
  theme: 'nextra-theme-docs',
  themeConfig: './theme.config.tsx'
})

export default withNextra(nextConfig)

when I run npm run dev:
- error Failed to load next.config.mjs, see more info here https://nextjs.org/docs/messages/next-config-error
Error: > The `app` directory is experimental. To enable, add `appDir: true` to your `next.config.js` configuration under `experimental`. See https://nextjs.org/docs/messages/experimental-app-dir-config
    at findPagesDir (~/project/node_modules/next/dist/lib/find-pages-dir.js:98:19)
    at findPagesDirectory (~/project/node_modules/nextra/dist/index.js:155:15)
    at Object.<anonymous> (~/project/node_modules/nextra/dist/index.js:159:53)
    at Module._compile (node:internal/modules/cjs/loader:1256:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1310:10)
    at Module.load (node:internal/modules/cjs/loader:1119:32)
    at Module._load (node:internal/modules/cjs/loader:960:12)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:169:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:194:25) {
  type: 'Error'
}

@jonnylangefeld Nextra only works with the ./pages directory at the moment. Support for the app router has not yet been implemented and might be a v3 feature.

Similar discussion at Nextra in my already existing NextJs 13 app.

Has there been any progress moving towards the App Router?

@jakeleboeuf there is no progress currently
A disadvantage of the App router for mdx docs is that each mdx page should be inside a folder for example
docs/
  introduction/
    page.mdx

Also, you can't share your layout (nextra-theme) from App router to the Pages router, so you can't have the layout defined in App router and mdx documents stored in /pages folder

A disadvantage of the App router for mdx docs is that each mdx page should be inside a folder

Just a note that we addressed this by using a catch-all segment ([...slug}) and dynamically importing and rendering the mdx file based on this slug (in combination with generateStaticParams).
If you do it this way, you don't need the pages directory at all, and so the theme can just use the app directory root layout.

A disadvantage of the App router for mdx docs is that each mdx page should be inside a folder

Just a note that we addressed this by using a catch-all segment ([...slug}) and dynamically importing and rendering the mdx file based on this slug (in combination with generateStaticParams).
If you do it this way, you don't need the pages directory at all, and so the theme can just use the app directory root layout.

Can you share the code or repo where you dynamically import mdx files?

If you do it this way, you don't need the pages directory at all, and so the theme can just use the app directory root layout.

@jthrilly how does that work? Did you setup your root Layout in the app dir to render the nextra theme? I'm looking for all the benefits of Nextra without losing all the benefits of the NextJS App Router world (ie RSC and friends).

@jthrilly how does that work? Did you setup your root Layout in the app dir to render the nextra theme? I'm looking for all the benefits of Nextra without losing all the benefits of the NextJS App Router world (ie RSC and friends).

We aren't using Nextra currently. We wanted to, but we want app dir support. We built our solution as an experiment in how hard it would be to set up manually.

Can you share the code or repo where you dynamically import mdx files?

Its a pretty simple process:

Use getStaticParams to build a flat map of your docs directory as it is on the filesystem. The result should basically be a collection in the format:

[
  { slug: '/path/to/file.mdx' }
]

Create a page.tsx under a catch-all route segment (for example app/[...slug]/page.tsx). In this page, get the slug from the page params object, and use the value to get the path to the appropriate mdx file.
Read the file from the path using fs and pass the content into your markdown processor (we are using matter: matter(fileContent).
Render the result inside of <MDXRemote> or whatever.

Render the result inside of  or whatever.

@erichosick In this case you’ll be unable to

use import statements in your mdx files
have ssg in mdx files
you couldn’t use new _meta.jsx/tsx since mdx files are loaded not with nextra/loader

We aren't using Nextra currently.

@erichosick gotcha, that setup makes sense if you're just looking to avoid the folder/page.tsx architecture. It's the Nextra + App Router part I'm looking for here, but tbh I'm not sure Nextra is the only thing holding me back at the moment. I need to better understand how mdx fits into the React Server Components world.
For my use case, I'm working on a design system that will ship Server Components, and it would be ideal to render all our components in our Docs along with usage examples without any extra work done on components purely for our docs. But again, I'm not 100% sure this is a Nextra problem or if I'll run into issues no matter where I try to render RSC in .mdx files.
*runs to the react repo 👀

@jakeleboeuf If you want to take a look at app router with MDX I will suggest source code of Rauch's blog

Can't we just write a codegen/script which converts pagesDir mdx files to page.tsx?

It seems like the only way to support App Router is to render mdx remotely (inspired by Lee blog https://github.com/leerob/leerob.io/blob/bb66498d9fc7dbfa28efcd1eaa475cb36d524efe/app/blog/[slug]/page.tsx#L127)
Example of file structure
|- docs
   |- my-page.mdx
   |- my-folder
      |- some-another-page.md
|- app
   |- docs
       |- [[...slug]]
          |- layout.tsx <-- nextra layout
          |- page.tsx <-- catch-all page that renders mdx with https://github.com/hashicorp/next-mdx-remote

That means the following
✅ no need to put each mdx page inside folder with page.mdx name as in https://github.com/rauchg/blog/blob/main/app/(post)/2021/making-the-web-faster/page.mdx
❌ all imports from mdx files will be stripped
⚠ figure out how to deal with _meta files

@dimaMachina can you explain a bit more about why app/ can't be supported? is there something fundamentally blocking you, or is it more about the level of effort? given how much stuff nextra provides that may not be possible (or may require a lot of extra configuration) with server-rendered components, i can totally understand that. moreso just curious as someone who's been following this thread for a while and anticipating a future nextra version that i could use with the app router..

@tubbo
putting each mdx page in the folder with page.mdx file fees weird UX for me https://github.com/shuding/nextra/issues/2023#issuecomment-1749804333
solution with next-mdx-remote https://github.com/shuding/nextra/issues/2023#issuecomment-1858999095 doesn't allow import statements and fast-refresh will not work too
both proposals for me are not good enough to replace pages router with

@dimaMachina could you elaborate on layout.tsx? What do you mean by "nextra layout", what are the contents of that file?

does it still now support app router?

Nextra v3 was finally released. And Nextra v4 prerelease just out! Currently without docs changes update or migration guide.
Nextra v4 will support a file-based router for your mdx files,
for anyone who wants to give it a try, feel free to take a look at nextra.site migration https://github.com/shuding/nextra/tree/v4-v2/docs
Nextra v4 will also support rendering your docs from a single catch-all route app/[[...slug]].jsx. Currently, as unstable and without hot reloading working, but I will fix it before stable releasing. Feel free to take a look at blog/docs and i18n docs examples that were migrated to it! https://github.com/shuding/nextra/tree/v4-v2/examples
Prerelease v4 last versions:
https://github.com/shuding/nextra/releases/tag/nextra%404.0.0-app-router.4
https://github.com/shuding/nextra/releases/tag/nextra-theme-docs%404.0.0-app-router.4
https://github.com/shuding/nextra/releases/tag/nextra-theme-blog%404.0.0-app-router.4
Feel free to share your feedback and create separated issues for problems you encountered
Have fun!
I will closing this PR to keep track of progress in https://github.com/shuding/nextra/issues/2600


Include also compressing option

It would be possible to include also a command to compress the XML/JSON to a minified version?
Currently , for JSON at least, this must be done with another plugin which also formats so you end with a duplicate feature...

Hi, thanks for your idea, but I don't have any plans to do it in nearest future


Is there any way to get node level in the tree ?

Hi @Zicrael, I am using this plugin in one of my app and I want to add a dropdown instead of input at a particular level. Is there any option, that I can get the selected node level in the event while adding or renaming node. So, that I can do my stuff based on node level.

@gauravaroraui I see. I think i update this tree in future and add this ability.


Array printing crashes during execution

Aim
Consider the following code:
  let bytes = [ "a", "b", "c" ];
  dep::std::println(bytes);  // prints ["", "", ""]
  // dep::std::println(bytes);  // prints ["I", "J", "K"]

  let bytes2 = [ "aa", "bb", "cc" ];
  dep::std::println(bytes2); // prints ["IK", "M", ""] or crashes if line 3 is active
  // dep::std::println(bytes2); // crash

  let bytes3 = [ "aaa", "bbb", "ccc" ];
  // dep::std::println(bytes3); // crash

Expected Behavior
should just work as is
Bug
see comments
To Reproduce
compile and run
Installation Method
Binary
Nargo Version
0.19.2+d7f919dcc001080ed24616ebbc37426ef7ac7638
Additional Context
No response
Would you like to submit a PR for this Issue?
No
Support Needs
No response

With everything uncommented, I get
% nargo execute                                                     ~/noir/temp master tom-box
[a, b, c]
[a, b, c]
[aa, bb, cc]
[aa, bb, cc]
[aaa, bbb, ccc]
[temp] Circuit witness successfully solved
%


Lack of Web Push API Support for Safari Hindering Adoption of Pusher Beams in PWAs

Hi there! We hope you're doing well. We wanted to bring up a concern regarding Pusher Beams and its support for W3C's Push API on Safari.
As you may know, since February of this year, iOS has introduced support for W3C's Push API. However, it seems that Pusher Beams currently offers only beta support for Safari Push Notifications, a separate api specific to Apple that requires a .p12 certificate.
We were wondering if there are any plans to add support for W3C's Push API on newer Safari versions in the future. To provide a seamless push notification experience for our users, it's essential for us to have Push API support on Safari. With other alternatives already offering support for it, we are facing a tough decision regarding the adoption of Pusher Beams.
Implementing support for W3C's Push API on Safari could make Pusher Beams a more attractive choice for developers looking for a comprehensive push notification solution. It would also save us from dealing with the complexities of the legacy .p12 certificate requirement for Safari Push Notifications.
We really value your attention to this matter and would appreciate any updates or insights you can share with us. Addressing this would undoubtedly benefit the product. Thank you!

As you have identified, Beams does not currently support web push notifications on Safari. While we do plan to add support for this to the product we don't currently have a timeframe for release. We'll update here as this changes.

In the same position here at my company. Have tested out Beams and it works well for push, but will have to move over to a different service as we require support for this.

Same here. It's a shame, that this essential feature is not a priority. Considering migrating to another service...

We would appreciate support for this as well.

Are there any news regarding this feature? What would it require to fast track this?

Have moved away from pusher for same reason. Luckily with web-push this should be easy enough to roll your own. Also not clear pusher is doing anymore much more than that anyway on lower tiers. I'm setting up mine with a nice interface that you can plug a lambda service into (feel free to ping if you want to follow along/reuse).

I was really bummed to find this! We're big fans of using Pusher for websockets and we were hoping to just setup Beams and get pushes to iOS PWAs. We're going to look elsewhere for push unfortunately.

Same situation here. I have also asked about this earlier this year through a support ticket and the answer was the same. Unfortunately I'll have do switch to something else.

Disappointed to hear that this isn't a priority considering the large number of iOS and iPad devices in the wild. Unfortunately, it'll also force me to move to an alternative.

why do the official docs say pusher supports safari? What are these docs talking about then?
I've managed to patch the push-notifications code to "make" it work on safari, and get all the way to the point where results are consistent with the docs (because the browser checks, which explicitly prevent safari usage, actually contradict the docs and are 5 years old...) and then get this error from the pusher backend service: presumably from another outdated user agent check.
Unhandled Promise Rejection: Error: Unexpected status code 400: Token error, Push service endpoint not supported. The push subscription might be from an unsupported browser
I'd be very grateful if someone could please clarify what Pusher beams supports, and what the docs are talking about if Safari and Safari on IoS are not supported.

Does anyone have a reliable provider alternative to pusher beams that supports Notifications via Web Push API no iOS?

Does anyone have a reliable provider alternative to pusher beams that supports Notifications via Web Push API on iOS?

I switched to Firebase Cloud Messaging (FCM). Does everything you need and has iOS Web Push Notifications API support as well

Does anyone have a reliable provider alternative to pusher beams that supports Notifications via Web Push API on iOS?

I switched to native Web Push API and storing subscriptions on my database. Pretty easy to implement!


Status computed variables & notification actions

Status computed variables: useful to verify result inside show() closure

#11

Just a couple fixes noted inline.

Since it's an optional it automatically receives a default value of nil

Oh, handy. I didn't know that.

Done :wink:

Merged this in with a couple small changes.
The compiler complained when I didn't have notificationCategories: when making a PermissionConfig without the = nil in the initializer. It looks like you must include it to get that bonus feature of being able to leave it off.
And one thing about the computed properties: stylistically, I leave the self. off unless it's being captured inside a closure for clarity. That being said, I don't do any [unowned self] yet in the closures.


Create an example using CPI with RandomForestModified and DnnLearner

See Figure E1: CPI-DNN’s constructions of Statistically Valid Variable Importance Assessment through Conditional Permutations

This example is for the usage of samples_in_leaf. For details, see #42.