Fix #3440: Moving domain bug

Fix #3440

Follow the steps in the bug report, then disable the Volume and Image renderers. The Flow region is incorrect.

I get correct results when following your directions:

That's really strange.  When I load domain.vs3 in the zip file from the bug report, and disable all renderers but flow, something goes awry.  I'm definitely on issue3340.

That's really strange. When I load domain.vs3 in the zip file from the bug report, and disable all renderers but flow, something goes awry. I'm definitely on issue3340.

Loading domain.vs3 is not one of the steps in the bug report:

Follow the steps in the bug report, then disable...

That session file was generated using a bug. The bug was fixed, but it does not retroactively repair bad session files, especially since we never released a version containing this bug.

That's fair, however when not using the session file I see the following which is the incorrect behavior from my screenshot 3 days ago :(. The domain is too long on the Y axis and the northern region of the flow renderer is truncated.
I'm not sure how we're seeing two different things. Would it be useful to do a screen share?

Just a sanity check: Are you using the pre-release installer or building from this branch for your tests?

Just a sanity check: Are you using the pre-release installer or building from this branch for your tests?

I'm building on issue3440 in debug mode with all other defaults applied.  But I don't think there's urgency since we've agreed to postpone this edge case until after release.  I'd like to do a screen-share when we meet on Tuesday though, just for sanity.


thread 'main' panicked at 'Entity does not exist'

Thanks for your great work, very much appreciated. Glad to help if feasible.
I read the following: #1707,  #1743, #2219
Bevy version
a1b2ec8f1d1fc635fc752f4b07c25147dbe07d93 (bevy 0.5 from crates.io)
Operating system & version
NixOS Unstable
What you did
Created some plugins with systems running in parallel and/or serialized, only removing entites after they completed their work. Unfortunately, I'm not allowed to share the code itself. If it helps, I can try to create a MWE (if time permits).
What you expected to happen
Do not crash. Emit an error! if unavoidable.
What actually happened
thread 'main' panicked at 'Entity does not exist', ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/world/mod.rs:214:37
Additional information
thread 'main' panicked at 'Entity does not exist', ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/world/mod.rs:214:37
stack backtrace:
   0:     0x558f7b732af0 - std::backtrace_rs::backtrace::libunwind::trace::h34055254b57d8e79
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:     0x558f7b732af0 - std::backtrace_rs::backtrace::trace_unsynchronized::h8f1e3fbd9afff6ec
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x558f7b732af0 - std::sys_common::backtrace::_print_fmt::h3a99a796b770c360
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x558f7b732af0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h32d1f94a80615d18
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x558f7b755a5c - core::fmt::write::h306731c068f7162c
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/fmt/mod.rs:1110:17
   5:     0x558f7b72d1f5 - std::io::Write::write_fmt::hd2fa90334eee2a21
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/io/mod.rs:1588:15
   6:     0x558f7b73501b - std::sys_common::backtrace::_print::h5abaa2601a852287
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x558f7b73501b - std::sys_common::backtrace::print::h8d81445442bb638f
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x558f7b73501b - std::panicking::default_hook::{{closure}}::hcfe804496a9fa747
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:208:50
   9:     0x558f7b734af1 - std::panicking::default_hook::hbea8e3ccf2ba8901
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:225:9
  10:     0x558f7b7356e4 - std::panicking::rust_panic_with_hook::h7ee9e1a2d0f8975a
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:622:17
  11:     0x558f7b7351c7 - std::panicking::begin_panic_handler::{{closure}}::h8ab3b4491718b2c7
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:519:13
  12:     0x558f7b732fec - std::sys_common::backtrace::__rust_end_short_backtrace::hd489062ffa586a9f
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/sys_common/backtrace.rs:141:18
  13:     0x558f7b735129 - rust_begin_unwind
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:515:5
  14:     0x558f7a9669c1 - core::panicking::panic_fmt::hca6330e3e14086b4
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/panicking.rs:92:14
  15:     0x558f7a9668b3 - core::option::expect_failed::hb6407502861d5eec
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/option.rs:1243:5
  16:     0x558f7b074588 - core::option::Option<T>::expect::hb4e136231f9b0421
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/option.rs:351:21
  17:     0x558f7abec978 - bevy_ecs::world::World::entity_mut::h6ae88df730e85fe1
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/world/mod.rs:214:9
  18:     0x558f7abe650c - <bevy_ecs::system::commands::Insert<T> as bevy_ecs::system::commands::Command>::write::h9e7944a392e954b9
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/system/commands.rs:351:9
  19:     0x558f7b545ffd - bevy_ecs::system::commands::CommandQueue::apply::h35982dcacdc6f745
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/system/commands.rs:24:13
  20:     0x558f7b546174 - <bevy_ecs::system::commands::CommandQueue as bevy_ecs::system::system_param::SystemParamState>::apply::h8ebccab4f78e6fdf
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/system/system_param.rs:458:9
  21:     0x558f7aad9af4 - <(P0,P1,P2,P3) as bevy_ecs::system::system_param::SystemParamState>::apply::h2f67c391feaa9dd5
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/system/system_param.rs:1010:19
  22:     0x558f7ab0aafe - <bevy_ecs::system::into_system::FunctionSystem<In,Out,Param,Marker,F> as bevy_ecs::system::system::System>::apply_buffers::h64f439c764bf4211
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/system/into_system.rs:161:9
  23:     0x558f7b514b87 - <bevy_ecs::schedule::stage::SystemStage as bevy_ecs::schedule::stage::Stage>::run::hf5f93d4222fa3181
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/schedule/stage.rs:834:25
  24:     0x558f7b56a530 - bevy_ecs::schedule::Schedule::run_once::h2034ca144031b6fa
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/schedule/mod.rs:201:13
  25:     0x558f7b56a5a0 - <bevy_ecs::schedule::Schedule as bevy_ecs::schedule::stage::Stage>::run::h412a9d3982b9759e
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/schedule/mod.rs:219:21
  26:     0x558f7b4bdbd8 - bevy_app::app::App::update::h0328d53a82ecaab6
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_app-0.5.0/src/app.rs:58:9
  27:     0x558f7b4bc4e0 - <bevy_app::schedule_runner::ScheduleRunnerPlugin as bevy_app::plugin::Plugin>::build::{{closure}}::{{closure}}::hea28d49ac5a1a0c9
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_app-0.5.0/src/schedule_runner.rs:76:25
  28:     0x558f7b4bc8bd - <bevy_app::schedule_runner::ScheduleRunnerPlugin as bevy_app::plugin::Plugin>::build::{{closure}}::h789e0a7e190c45aa
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_app-0.5.0/src/schedule_runner.rs:101:47
  29:     0x558f7b4af048 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h4b7ce5908c896b6f
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/alloc/src/boxed.rs:1589:9
  30:     0x558f7b4bdcf1 - bevy_app::app::App::run::h116ccd77f6a71c7f
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_app-0.5.0/src/app.rs:68:9
  31:     0x558f7b4b633e - bevy_app::app_builder::AppBuilder::run::h27fd4f2a0189f1d7
                               at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_app-0.5.0/src/app_builder.rs:49:9
  32:     0x558f7a96d0ca - my_project_name::main::h94e52035496abc6a
                               at ~/repos/my_project_name/src/main.rs:12:3
  33:     0x558f7a96ac3b - core::ops::function::FnOnce::call_once::h4caae3afd86d231c
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/ops/function.rs:227:5
  34:     0x558f7a96b4de - std::sys_common::backtrace::__rust_begin_short_backtrace::hb9d1c99edf362ba7
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/sys_common/backtrace.rs:125:18
  35:     0x558f7a96b561 - std::rt::lang_start::{{closure}}::ha5bdfdc51a01a7b9
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/rt.rs:49:18
  36:     0x558f7b735be9 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h2aabc384aab89b7b
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/ops/function.rs:259:13
  37:     0x558f7b735be9 - std::panicking::try::do_call::hc5fcacb7a85fc7b1
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:401:40
  38:     0x558f7b735be9 - std::panicking::try::hb5d9603af3abbe3a
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:365:19
  39:     0x558f7b735be9 - std::panic::catch_unwind::h98fe6ac3925e64b4
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panic.rs:434:14
  40:     0x558f7b735be9 - std::rt::lang_start_internal::h22ac7383c516f93e
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/rt.rs:34:21
  41:     0x558f7a96b540 - std::rt::lang_start::ha3e6132f05793518
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/rt.rs:48:5
  42:     0x558f7a96d12c - main
  43:     0x7ff8afb2e780 - __libc_start_main
  44:     0x558f7a9671ba - _start
                               at /build/glibc-2.33/csu/../sysdeps/x86_64/start.S:120
  45:                0x0 - <unknown>

This looks the bug documented in https://github.com/bevyengine/bevy/pull/2581. Basically, the order that commands are applied in mirrors system order: your system order is likely ambiguous in critical ways and entities are being despawned before they exist.
That said, a more general solution is given by #2241, which pushes towards a safer, more customizable set of behaviours for Commands error handling. If you have the bandwidth, feedback (and perhaps contributions) on that thread would be valuable: I'd like to get the ball rolling on that again.

Closing as duplicate of #1743. Still important and useful to solve; it's just nice to try and keep the conversations centralized.


Add Picoscope scope driver(s)

Does it is too early to start working on adding Picoscope ?

After checking quickly the code it seems a good start will be to use class example like LeCroyOscilloscope.cpp/.h
Does the Interface/Class with members... is frozen ? (maybe it is too early to work on Picosope driver ?)

As discussed on IRC: I started hacking up a prototype SCPI bridge for my 3000-series Picoscope, with data going over a separate socket as in AntikernelLabsOscilloscope.

@noopwafel Do you have any news about your prototype SCPI bridge for my 3000-series Picoscope ?
I have a PicoScope 3406DMSO so I'm very interested by this driver as it shall be very fast in theory over USB 3.0

I got (very very) swamped by work, but getting back to this is now nearer the top of my todo (likely next week?). Feel free to ping me about it. I don't have (access to) an MSO, so would be nice to hack that in too.

Yes everyone is very busy with tons of things to do and we do that on our spare time so there is no hurry
I'm very interested if you have something usable to test to help and even improve it for PicoScope 3000-series (especially I have the full version) and I could test also on Windows.

I also have a PicoScope 3406DMSO and be willing to test...

@sbabic44 Unfortunately Pico's driver model uses a separate SDK for each one of their families. In order to clean this up a bit and provide network transparency (a key feature for me since my main desk is about 20 meters from the lab bench), I'm using a bridge server (https://github.com/azonenberg/scopehal-pico-bridge) as the point of abstraction which currently only supports the 6000 series.
Once I've finished 6000 series support I'm definitely interested in supporting lower end models. Some refactoring will be needed though, as right now the ps6000d application contains a bunch of SCPI parsing code etc that should probably be shared across the different server binaries.

Closed this ticket as 6000 series support is at "minimum viable" level.
Feel free to file additional tickets for specific features. Requests for new instrument support should be filed against scopehal-pico-bridge instead, as the network protocol used by the PicoOscilloscope class is intended to be the same for all instruments.


fix typo 全县->权限 in doc/Compile_CN.md

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

why?


Implement replace on the Database Column

This task is automatically imported from the old Task Issue Board and it was originally created by James Dunkerley.
Original issue is here.

    replace : Text | Column -> Text | Column -> Case_Sensitivity -> Boolean -> Boolean -> Column
    replace self term="" new_text="" case_sensitivity=Case_Sensitivity.Sensitive only_first=False use_regex=False =

Surfaces the same options as Text.replace.
Should follow the same API as the in-memory version.
Case Insensitive in non-default locale should be an error.
What modes are available will depend on what is supported by the dialect.

This should be done by mapping the modes to specific dialect operators:

case_sensitive
use_regex
only_first
operation

True
False
True
Replace_First

True
False
All
Replace_All

False
False
True
IReplace_First

False
False
All
IReplace_All

etc.

Looking through the Postgres and SQLite docs, it looks like

case_sensitive
use_regex
only_first
postgres
sqlite

True
False
True
via regex(1)
via instr(2)

True
False
False
supported
supported

False
False
True
via regex(1)
via instr(2)

False
False
False
via regex(1)
unsupported

(1) Postgres regex supports only_first and case insensitivity; this would require escaping the search string so it would not act as a regex.
(2) Use INSTR() to find the lowercased string, then replace it via concatenation


UI : Add support for Avro editor

Add support for Avro editor

As discussed, For 0.13.1 we are going with the nested structure as we have for the table columns.
For Example :

Completed with #9224


etcd-tester: add retry logic on retriving lease info

getting lease and keys info through raw rpcs rarely experience error such as EOF. This is considered as a failure and causes tester to clean up.
however, they are just transient problem with temporary connection issue which should not br considered as a testing failure. so we add retry logic in case of transient failure.
FIX #6754

I suspect the EOF issue has nothing to do with our internal server code but it is a issue with the http library in which we are using. I think the simplest way to get around it is through retrying on client side. since connection errors are expected and client should take care of those.
cc @xiang90 @gyuho @heyitsanthony

If it's errors from a disrupted connection, why not issue the RPC calls with FailFast=false?

@heyitsanthony
getting lease info is using failfast=false. we are still experiencing EOF.
func (ls *leaseStresser) getLeaseByID(ctx context.Context, leaseID int64) (*pb.LeaseTimeToLiveResponse, error) {
	ltl := &pb.LeaseTimeToLiveRequest{ID: leaseID, Keys: true}
	return ls.lc.LeaseTimeToLive(ctx, ltl, grpc.FailFast(false))
}

@fanminshi ok, that's a server-side issue.  There needs to be an actual error code returned by the server that can be detected here instead of dropping the error on the floor.

@heyitsanthony I dig into the lease code a bit. I think error is thrown from this line.
https://github.com/coreos/etcd/blob/master/lease/leasehttp/http.go#L187
I suspect that the http req failed due to EOF, and then that error is escalated to the client side.
I wonder how would the server side handles this kind of connection related error?

The syndrome is similar to that of http://stackoverflow.com/questions/17714494/golang-http-request-results-in-eof-errors-when-making-multiple-requests-successi.
However, according to the post, that issue is patched in the go version 1.6. So we might experiencing something a bit different.

Let's clean this up. Then lgtm

All fixed. PTAL @xiang90

@fanminshi LGTM. Thanks a lot!


feat: Validate operation now has glob support

Very helpful when working with multiple APIs in subfolders.

Thanks for your contribution. It looks like this functionality has made it into the main branch already. I'm going to close this PR.


String obfuscation

Can you add option to obfuscate strings too?

https://github.com/MegatronKing/StringFog


Generated file is .bin while GNSS-SDR demands .dat

GNSS-SDR demands .dat file (raw GPS signals). GPS-SDR-SIM creates .bin file and I am not sure if it is same as .dat format. I couldn't find any example of it. Probably I am missing something obvious.

I have the same question. Could some please clarify?

Update: I am able to run the .bin file obtained from the gps-sdr-sim by setting the sampling frequency  = 4000000Hz instead of 2.6MHz. With the default configuration file mentioned at https://gnss-sdr.org/my-first-fix/, the simulation was successful as multiple output files got generated.


Completed test coverage for contrib.auth.forms.

Add tests and small readability improvement to complete contrib.auth.forms coverage.

Thank you @felixxm !


Add DataWarehouseRole in template

See cross-account permissions and using IAM roles: https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html#access-policies-walkthrough-example4-overview
Data warehouse account must provide external ID to assume role, the primary function of the external ID is to address the confused deputy problem (from https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)

/NVA/IAM/DataWarehouse/DataBricksArn and ExternalId should be defined in nva-infrastructure?


Posting message without any event

Issue Type

[x] Bug Report

Description
Hey ! i'm trying to send a message but without any event; with jda instance & 2 different class;
But i got a problem; when i'm calling getJda to get simple jda; Ok it connect 1 time; But when i'm getting guild & channel & trying to post message;
It reconnect 9 times ... Anyone got the solution ?

I thinks its an issue of your internet and not an JDA issue

Its not my connection; Just i'm calling multiple time jda build blocking... and if i try to use buildblocking out of void; it just say u must throws; but u can't cause you're not in a void

and i can't just retrieve jda without reconnect

Reuse 1 JDA instance and dont spam JDABuilder#buildBlocking()

How ?  can you provide example please ?

This is not the place to learn java.

Oh my god; I tried all things but don't work

OMG! thanks for help


Tray action interface

Changes

extracted Launcher from AvalonModule
implemented ITrayAction which simplifies few modules that they don't have to be in folder

converted to actions: Standalone publisher, Settings and Launcher

Looking ok. but a bit fo API docs would be nice, so it doesn't get lost.

Looking ok. but a bit fo API docs would be nice, so it doesn't get lost.

Added README.md to modules directory with basic concepts.

Looking ok. but a bit fo API docs would be nice, so it doesn't get lost.

Added README.md to modules directory with basic concepts.

than you. now conflicts and we're done


Export drawElementOnCanvas() renderer method

Hi, I would like to thank you for this amazing tool ! ❤
As mentionned in https://github.com/excalidraw/excalidraw/issues/1261, I'm looking for some not-exported-yet Excalidraw renderer methods and constants for an experimental Excalidraw CLI project.
At first glance, drawElementOnCanvas() may be the only method I need because it handles most of the element shape generation / stroke styling / drawing on canvas at once, and I would just need to pass the element and the canvas context, if I'm correct.
This method also uses some not exported useful constants :
https://github.com/excalidraw/excalidraw/blob/046c0818c5b39b78c70646b5f9a1c28f31787694/src/renderer/renderElement.ts#L29-L30
Is it possible to export drawElementOnCanvas() method ?

Can be done.
Is there a pattern for exposing private stuff in a way that in our own codebase it's clear it shouldn't be used directly? Another concern is it'll pollute intellisense.
Maybe export under a namespace?
export const public = { renderElement, DASHARRAY_DASHED, DASHARRAY_DOTTED }

Another concern is, drawElementOnCanvas is very low level. It doesn't take into account element position etc., so you'll need to take care of it yourself. It can also change at moment's notice, can be renamed, etc. Not sure it's wise to depend on it.

FWIW, I used the exported renderElement.
https://github.com/dai-shi/excalidraw-layers/blob/b3adeb24a31d87f2ab59544e8bb30bd762737606/src/viewer.worker.ts#L38

I believe that for the CLI, we would want to export higher level primitives: export to svg, export to png instead of the raw canvas methods.

@vjeux I'm still keeping an eye on excalidraw-embed project, even if it seems to prioritize integrations in React apps right now.
That said I would be looking forward for exposed higher-level primitives, this would be so helpful for third-party integration projects so we don't have to copy-paste most of the excalidraw codebase like I'm doing right now in the experimental project @tommywalkie/excalidraw-cli, and @dai-shi in his projects like excalidraw-animate, it works fine for both of us but it could be improved.
Keep the good work ! 👍


update to 0.9.0 fails for debug dependency, bower

At the last update of leaflet (to 0.8), we've had problems since the new simple-logger dependency wasn't available in bower. We're going through the same thing for 0.9 because apparently simple-logger now depends on debug which isn't available for bower.

Which js file are you pointing to for the logger? You should be using angular-simple-logger.js or angular-simple-logger.light.js as they don't require debug as it is wrapped or not included. Otherwise use npm and use browserify/webpack.

We're just using the leaflet directive which depends on logger which now depends on debug. We're managing all of that through bower/browserify, but like I said, it's become somewhat painful to maintain the dependencies.

So if your using browserify, don't use bower for this library. Use the npm version. The visionmedia debug, part is what makes this an issue as its browser version will break browserify. Just as the bower version of  angular-simple-logger.js is made with browserify already and will break commonjs if used. So use the commonJS version of index.js. The dependencies are propagated correctly on npm.
Visionmedia's debug has issues in bower where only using the browser version or browserifying it for bower (angular-simple-logger) will work. This is becuase they decided to not include any of their dependencies which are on npm. https://github.com/visionmedia/debug/blob/2.2.0/bower.json
From their point of view using the https://github.com/visionmedia/debug/blob/2.2.0/browser.js is sufficient. Which I am essentially doing the same by browserifying angular-simple-logger.js for bower.
I don't really know any other way around this sorry. But npm is your better choice or use the light version with no debug.

To discuss this more please file an issue on angular-simple-logger.

The other problem is I don't have perms yet to push angular-leaflet-directive to npm. If I did then you could get this project from there and avoid this problem.
I am adding some comments about this to the Readme.md on angular-simple-logger.

#989  @tombatossals :boom:

https://github.com/nmccready/angular-simple-logger/blob/master/README.md

One possible improvement to avoid your personal h3ll, is to make the *light.js version the bower default. But be aware you will not have debug capabilities.

@nschloe does any of this make sense?

@nmccready , thanks for sharing your insight.

So if your using browserify, don't use bower for this library. Use the npm version.

The existence of a bower.json for the leaflet directive had lured us into thinking that this use case was actually supported. Since we're not using npm for frontend shipping dependencies and manually maintaining all dependencies of leaflet is no acceptable for us, we'll just remove the leaflet dependency altogether from our app.
As a developer, I don't understand why a directive has to ship it's own logging library, especially since, eventually, this is the reason why we can't use the directive. Having a logging tool on the dev box for debugging purposes: alright. But baked into the product? The way it got into leaflet without any review also strikes me as somewhat dubious and raises concerns on how much headache continuing to use this directive would cause us in the future.
Well, anyhow, he who codes is right, so I won't suggest to change anything.

So you can use bower, but if your dead set in browserifying every library under the sun from bower say for angular-leaflet-directive.  So what I am saying to do is split your bower up. Use some as browserify and some as a seperate vendor.js file.
So again if you must browserify all your dependencies (AND want the full logger version) then I suggest using npm. This project plans to support both bower and npm. npm being a little rusty right now (delayed releases).
Again if your deadset on browserifying and expect it to not have errors then direct your logger dependency to the light version.
Ultimately I think the less headache solution will be pointing bower to use the light version. That way it will not error out on ng-leaflet. Then a user can decide if they want the advanced debugging features and use bower, browserify, npm to do its magic.

I made a ticket; I'll try to get to it by Monday and make this for 0.9.1 here. https://github.com/nmccready/angular-simple-logger/issues/12

Re-opening for 0.9.1 so we point to angular-simple-logger#>=0.1.5

As a developer, I don't understand why a directive has to ship it's own logging library, especially since, eventually, this is the reason why we can't use the directive

THIS IS WHY #829  .. I was doing this same code in several projects. Why copy and paste the code?

This issue was moved to angular-ui/ui-leaflet#133

I'm going to rework&redesign angular-leaflet-directive to be compatible with Leaflet v1.0. It will mantain almost all its functionality, and will be compatible with the current features of the directive, but I must start from a fresh point, so I'm going to close this issue. If you think it must be worked with the new version, please reopen it.


Misssing Chinese translation docs: https://kubernetes.io/blog/2022/05/05/volume-expansion-ga/

This is a Feature Report
Problem:
misssing Chinese translation docs:  https://kubernetes.io/blog/2022/05/05/volume-expansion-ga/
Proposed Solution:
add Chinese translation docs in website Kubernetes Blog
Comments
/language zh
/assign

/triage accepted

已经翻译完成 https://kubernetes.io/zh-cn/blog/2022/05/05/volume-expansion-ga/


Query error when trying to insert in partitioned table

Using following code to write in an existing daily partitioned table:
bigquery_client = bigquery.Client(project=self.project_id)
dataset = bigquery_client.dataset(self.destination_dataset)
destination_table_with_day = "table$20170927"
sql = """
        #standardSQL
        ...
       """

table = dataset.table(destination_table_with_day)
table.partitioning_type = "DAY"
query = client.run_async_query(str(uuid.uuid4()), sql)
query.destination = table
query.write_disposition = 'WRITE_TRUNCATE'
query.begin()
query.result()

I expected similar result as the CLI with
bq query --use_legacy_sql=false --replace --destination_table 'dataset.table$20170927' "..." which works flawlessly
But it returned ERROR - 400 Partitioning specification must be provided in order to create partitioned table
I suspect that some parameters are missing that would result in this error such as https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs#configuration.query.timePartitioning.type
I'm not really that fluent in Python so I couldn't find out that it's the problem is the way I use the SDK or in the SDK.
I didn't find any sample related on that case inside https://github.com/GoogleCloudPlatform/python-docs-samples but I saw https://github.com/GoogleCloudPlatform/google-cloud-python/issues/2729 that could be related somehow.

I found out switching to the CLI implementation that the issue was that the table didn't existed (I was passing another dataset, not the one where I created the partitioned table).
I guess the server error is pretty misleading as partitioned tables can't be created out of the format of the table name (ie table$YYYYMMdd or table$YYYYMMdd for upcoming hour level support) and therefore requires a prior bq mk --time_partitioning_type=DAY dataset.table command to be run.
After fixing my code, it looks like everything is working as intended.
Sorry for the noise.


Fix the problem of live resize cpus for SLES VM

Sometimes live resize (increase) cpus on SLES VM can't bring the new added offline cpu online, but can make it present then the next resize can bring it online.
Hence, always call 'chcpu -e' to enable the new added cpus.

A temp fix, need to remove all ubuntu related fix if this is ok.

/lgtm

Removed the ubuntu handling logic as now we always run 'chcpu -e' when live resize cpus.
A full regression test is needed on rhel/sles/ubuntu.
UT fix is ongoing.

Local test on rhel/sles/ubuntu passed.


PVOnline search broken

Describe the bug
PVOnline search never gives back any results
To Reproduce
Steps to reproduce the behavior:

Go to ingredients inventory
switch search to PVOnline
do any search

Screenshot

Expected behavior
some results
Desktop (please complete the following information):
Any
Smartphone (please complete the following information):
Any

I am unable to replicate the issue.
Can you please make sure you always provide the PV version when you raising a bug?

Forgot it, anyway is the latest 8.9.
Just tried it now and it works, 2 hours ago was still broken


Split packages

Sometimes several packages can be generated from a single source. For example, harmony, nao, mines, remux and simple all come from the rmkit Git repo. It would make packaging simpler if we could combine the four recipes into a single one, à la Arch split packages.

This would be good for Oxide as well. I'd like to split out the bundled applications.


API Key and Secret

Where do i find the API Key and Secret??
I have installed the Module and restarted ignition but I cannot find it.

Once the module is installed, you have to login to the Ignition Gateway configuration page and select the Node-RED section from the left. There you can add an API key and secret.
Regards,
Travis Cox
Co-Director of Sales Engineering
Inductive Automation
800.266.7798 [ callto:800.266.7798 ] | ext. 229
[<EMAIL_ADDRESS>|<EMAIL_ADDRESS>]
[ https://icc.inductiveautomation.com/ ]
From: "chrisegge"<EMAIL_ADDRESS>To: "IgnitionModuleDevelopmentCommunity/IgnitionNode-RED"<EMAIL_ADDRESS>Cc: "Subscribed"<EMAIL_ADDRESS>Sent: Thursday, August 9, 2018 7:50:31 PM
Subject: [IgnitionModuleDevelopmentCommunity/IgnitionNode-RED] API Key and Secret (#1)
Where do i find the API Key and Secret??
I have installed the Module and restarted ignition but I cannot find it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, [ https://github.com/IgnitionModuleDevelopmentCommunity/IgnitionNode-RED/issues/1 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/APjg82ZjQceMvueLYAViGV8RN9heVjtyks5uPPT3gaJpZM4V3gXb | mute the thread ] .

I am finding the same issue, but here is a bit more information about my case:
My machine is running an Edge Ignition software and I installed the 'Ignition-Node-RED-Module-signed.modl' module. Once installed, I cannot find any Node-RED section on the left. However, in the modules section I can see that the module is Quarantined:
Quarantine Reason: "This module will not run on edge without a license."
Whats is the issue? How doe I/we solve the problem?
Thanks in advance for any support.

Once added a license in the module.xml within the .modl file, the rising comment is:
Quarantine Reason: "This module is unsigned and developer mode is disabled. This module will not run on edge without a license."

Unfortunately, you need Ignition 7.9.9 to load that module. You also need to get the signed module from the GitHub page. Try that out and let me know if you have any problems.
Regards,
Travis Cox
Co-Director of Sales Engineering
Inductive Automation
800.266.7798 [ callto:800.266.7798 ] | ext. 229
[<EMAIL_ADDRESS>|<EMAIL_ADDRESS>]
[ https://icc.inductiveautomation.com/ ]
From: "gabrielfpvh"<EMAIL_ADDRESS>To: "IgnitionModuleDevelopmentCommunity"<EMAIL_ADDRESS>Cc: "Travis Cox"<EMAIL_ADDRESS>"Comment"<EMAIL_ADDRESS>Sent: Tuesday, August 14, 2018 5:08:08 AM
Subject: Re: [IgnitionModuleDevelopmentCommunity/IgnitionNode-RED] API Key and Secret (#1)
Once added a license in the module.xml within the .modl file, the rising comment is:
Quarantine Reason: " This module is unsigned and developer mode is disabled. This module will not run on edge without a license. "
—
You are receiving this because you commented.
Reply to this email directly, [ https://github.com/IgnitionModuleDevelopmentCommunity/IgnitionNode-RED/issues/1#issuecomment-412850004 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/APjg86Pq5j3Lwx7TeW8z6GfrIGzvNtveks5uQr2ogaJpZM4V3gXb | mute the thread ] .

I just installed on 7.9.9 Ignition Edge, and still getting the quarantined will not run without a license issue.  I have the signed module.  I have had no issue installing on Ignition Edge 7.9.4.  The 7.9.9 device is our EPIC-PR1, and the 7.9.4 is our GROOV-AR1 for reference.

Hi Garrick,
Yes sorry about that. We were supposed to fix that in 7.9.9 but that got moved to 7.9.10 which should be in beta within a week. Somehow we missed that.
Regards,
Travis Cox
Co-Director of Sales Engineering
Inductive Automation
800.266.7798 [ callto:800.266.7798 ] | ext. 229
[<EMAIL_ADDRESS>|<EMAIL_ADDRESS>]
[ https://icc.inductiveautomation.com/ ]
From: "GarrickR"<EMAIL_ADDRESS>To: "IgnitionModuleDevelopmentCommunity"<EMAIL_ADDRESS>Cc: "Travis Cox"<EMAIL_ADDRESS>"Comment"<EMAIL_ADDRESS>Sent: Friday, October 19, 2018 7:42:11 AM
Subject: Re: [IgnitionModuleDevelopmentCommunity/IgnitionNode-RED] API Key and Secret (#1)
I just installed on 7.9.9 Ignition Edge, and still getting the quarantined will not run without a license issue. I have the signed module. I have had no issue installing on Ignition Edge 7.9.4. The 7.9.9 device is our EPIC-PR1, and the 7.9.4 is our GROOV-AR1 for reference.
—
You are receiving this because you commented.
Reply to this email directly, [ https://github.com/IgnitionModuleDevelopmentCommunity/IgnitionNode-RED/issues/1#issuecomment-431386596 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/APjg86yqK5YUgEASNF-bZBVWcFIRlh3cks5umeTCgaJpZM4V3gXb | mute the thread ] .

I'm going to close this issue, my original problem has been resolved. Thank you