Backtrace esp-idf 4.3.1+

Hi,
So I've noticed that the std example states here, it is no longer possible to generate backtraces for xtensa.
And I'm really wondering why that is the case.
If someone could deliver technical details about the problems with that topic, I'd gladly try to help fix it.
Might this be a problem in the esp std lib?

Actually the above comment - last time we checked - is incorrect. Have you teried uncommenting it?

I've tried to get backtraces working for a while now. Didn't succeed so far, but I'll take a closer look at it again

Okay so apparantly it is working better than I thought it was.
I created a panic right after the env::set_var("RUST_BACKTRACE", "1");
The result seems to be promising, but well that's the output.
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/main.rs:135:28
stack backtrace:

abort() was called at PC 0x4010b0ee [abort_return<int>:/home/jan/CLionProjects/rust-esp32-std-demo/.embuild/espressif/esp-idf/release-v4.4/components/cxx/cxx_exception_stubs.cpp:33] on core 0
Backtrace:0x4008251a [panic_abort:/home/jan/CLionProjects/rust-esp32-std-demo/.embuild/espressif/esp-idf/release-v4.4/components/esp_system/panic.c:402]:0x3ffb60100x40084d09 [esp_system_abort:/home/jan/CLionProjects/rust-esp32-std-demo/.embuild/espressif/esp-idf/release-v4.4/components/esp_system/esp_system.c:128]:0x3ffb6030 0x400898e2 [abort:/home/jan/CLionProjects/rust-esp32-std-demo/.embuild/espressif/esp-idf/release-v4.4/components/newlib/abort.c:46]:0x3ffb6050 0x4010b0ee [abort_return<int>:/home/jan/CLionProjects/rust-esp32-std-demo/.embuild/espressif/esp-idf/release-v4.4/components/cxx/cxx_exception_stubs.cpp:33]:0x3ffb60c0 0x400f23cf [std::backtrace_rs::backtrace::libunwind::trace:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93]:0x3ffb60e0 0x400dc3fb [std::sys_common::backtrace::_print_fmt:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:67]:0x3ffb6110 0x40104e9d [core::fmt::write:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:1168]:0x3ffb6180 0x400de782 [std::io::Write::write_fmt:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/io/mod.rs:1660]:0x3ffb61d0 0x400dc329 [std::sys_common::backtrace::_print:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:49]:0x3ffb6220 0x400e66d6 [std::panicking::default_hook::{{closure}}:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/panicking.rs:211]:0x3ffb6270 0x400e658f [std::panicking::default_hook:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/panicking.rs:228]:0x3ffb62e0 0x400e6884 [std::panicking::rust_panic_with_hook:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/panicking.rs:606]:0x3ffb6350 0x400dc82f [std::panicking::begin_panic_handler::{{closure}}:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/panicking.rs:??]:0x3ffb63b0 0x400dc489 [std::sys_common::backtrace::__rust_end_short_backtrace:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:139]:0x3ffb63e0 0x400e6768 [rust_begin_unwind:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/panicking.rs:498]:0x3ffb6410 0x40105993 [core::panicking::panic_fmt:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/core/src/panicking.rs:116]:0x3ffb6440 0x40105937 [core::panicking::panic:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/core/src/panicking.rs:48]:0x3ffb6470 0x400d5075 [rust_esp32_std_demo::main:/home/jan/CLionProjects/rust-esp32-std-demo/src/main.rs:??]:0x3ffb64b0 0x4011a1e7 [core::ops::function::FnOnce::call_once:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/core/src/ops/function.rs:227]:0x3ffb6560 0x400d5454 [std::rt::lang_start::{{closure}}:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/rt.rs:145]:0x3ffb6580 0x400f52e1 [core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/core/src/ops/function.rs:259]:0x3ffb65a0 0x400d5442 [std::rt::lang_start:/home/jan/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/rt.rs:144]:0x3ffb65c0 0x400d52c5 [main:??:??]:0x3ffb65f0 0x400d61a7 [app_main:/home/jan/.cargo/registry/src/github.com-1ecc6299db9ec823/esp-idf-sys-0.31.5/src/start.rs:46]:0x3ffb6610 0x4011b5c4 [main_task:/home/jan/CLionProjects/rust-esp32-std-demo/.embuild/espressif/esp-idf/release-v4.4/components/freertos/port/port_common.c:129]:0x3ffb6630
ELF file SHA256:<PHONE_NUMBER>000000

while I would expect a normal full backtrace to be beautifully formatted like this:
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/main.rs:13:28
stack backtrace:
   0:     0x55af53f8358d - std::backtrace_rs::backtrace::libunwind::trace::h7c06355936cefbfa
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x55af53f8358d - std::backtrace_rs::backtrace::trace_unsynchronized::h0d29350836df727e
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55af53f8358d - std::sys_common::backtrace::_print_fmt::h7cc76caea8ef80df
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/sys_common/backtrace.rs:66:5
   3:     0x55af53f8358d - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h41dad21719ef8ab8
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/sys_common/backtrace.rs:45:22
   4:     0x55af53f9ef6c - core::fmt::write::h6c4cfebe9aad777b
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/core/src/fmt/mod.rs:1190:17
   5:     0x55af53f81241 - std::io::Write::write_fmt::h01de082d65b0a1fb
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/io/mod.rs:1655:15
   6:     0x55af53f84f65 - std::sys_common::backtrace::_print::hcd7176b4e129c3a4
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/sys_common/backtrace.rs:48:5
   7:     0x55af53f84f65 - std::sys_common::backtrace::print::h710200ae52dbc495
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/sys_common/backtrace.rs:35:9
   8:     0x55af53f84f65 - std::panicking::default_hook::{{closure}}::ha61678fe9bc854f8
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/panicking.rs:295:22
   9:     0x55af53f84c19 - std::panicking::default_hook::h583260a485b0ad61
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/panicking.rs:314:9
  10:     0x55af53f854b2 - std::panicking::rust_panic_with_hook::h1d1648214bd2ee6f
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/panicking.rs:698:17
  11:     0x55af53f85359 - std::panicking::begin_panic_handler::{{closure}}::h17c86375419bb484
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/panicking.rs:586:13
  12:     0x55af53f83a44 - std::sys_common::backtrace::__rust_end_short_backtrace::h1ab814c3b9abd6c1
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/sys_common/backtrace.rs:138:18
  13:     0x55af53f850c9 - rust_begin_unwind
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/panicking.rs:584:5
  14:     0x55af53e87513 - core::panicking::panic_fmt::hc535849e7e17b12d
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/core/src/panicking.rs:143:14
  15:     0x55af53e873dd - core::panicking::panic::h43f3075350720b17
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/core/src/panicking.rs:48:5
  16:     0x55af53e89056 - core::option::Option<T>::unwrap::h582945c3a106845c
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/core/src/option.rs:752:21
  17:     0x55af53e8926f - rpkitest::main::{{closure}}::hf88416cb053e8479
                               at /home/jan/projects/rpkitest/src/main.rs:13:5
  18:     0x55af53e8974b - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::haba7bbb87a04b6cf
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/core/src/future/mod.rs:91:19
  19:     0x55af53e88460 - tokio::park::thread::CachedParkThread::block_on::{{closure}}::h9403d5b1d0c9add3
                               at /home/jan/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.17.0/src/park/thread.rs:263:54
  20:     0x55af53e886d0 - tokio::coop::with_budget::{{closure}}::h2b4b4341c09e9181
                               at /home/jan/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.17.0/src/coop.rs:102:9
  21:     0x55af53e8a756 - std::thread::local::LocalKey<T>::try_with::hf71f9a9d4fbba9b2
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/thread/local.rs:442:16
  22:     0x55af53e8a0cd - std::thread::local::LocalKey<T>::with::hb176ca5d15ddc55e
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/thread/local.rs:418:9
  23:     0x55af53e87ece - tokio::coop::with_budget::h76b43e47ef3195b4
                               at /home/jan/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.17.0/src/coop.rs:95:5
  24:     0x55af53e87ece - tokio::coop::budget::ha8ca6e62a680b2c0
                               at /home/jan/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.17.0/src/coop.rs:72:5
  25:     0x55af53e87ece - tokio::park::thread::CachedParkThread::block_on::h77f40580983bedb0
                               at /home/jan/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.17.0/src/park/thread.rs:263:31
  26:     0x55af53e87b62 - tokio::runtime::enter::Enter::block_on::h4591f03e8505dcec
                               at /home/jan/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.17.0/src/runtime/enter.rs:151:13
  27:     0x55af53e8ca9e - tokio::runtime::thread_pool::ThreadPool::block_on::h20e9ec7d78d25981
                               at /home/jan/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.17.0/src/runtime/thread_pool/mod.rs:73:9
  28:     0x55af53e8c76c - tokio::runtime::Runtime::block_on::h60d8779f4662e81e
                               at /home/jan/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.17.0/src/runtime/mod.rs:477:43
  29:     0x55af53e89c8d - rpkitest::main::h9a806fdfc217855b
                               at /home/jan/projects/rpkitest/src/main.rs:15:5
  30:     0x55af53e88d0b - core::ops::function::FnOnce::call_once::hb82e4110293ba926
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/core/src/ops/function.rs:227:5
  31:     0x55af53e88fde - std::sys_common::backtrace::__rust_begin_short_backtrace::h7e7ad00ab4a9fb1f
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/sys_common/backtrace.rs:122:18
  32:     0x55af53e8c9b1 - std::rt::lang_start::{{closure}}::hb3727b258710bf6b
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/rt.rs:145:18
  33:     0x55af53f7d75b - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h6808b3981fffb3a5
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/core/src/ops/function.rs:259:13
  34:     0x55af53f7d75b - std::panicking::try::do_call::ha9d4f416232aed9b
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/panicking.rs:492:40
  35:     0x55af53f7d75b - std::panicking::try::h99d1fbbf9049df71
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/panicking.rs:456:19
  36:     0x55af53f7d75b - std::panic::catch_unwind::h35989a664757b51f
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/panic.rs:137:14
  37:     0x55af53f7d75b - std::rt::lang_start_internal::{{closure}}::h3c08fcfe13523756
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/rt.rs:128:48
  38:     0x55af53f7d75b - std::panicking::try::do_call::h3c6c9fbdfee00b5d
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/panicking.rs:492:40
  39:     0x55af53f7d75b - std::panicking::try::h9a6eac7d21d4fd96
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/panicking.rs:456:19
  40:     0x55af53f7d75b - std::panic::catch_unwind::h4c952cfb908502a3
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/panic.rs:137:14
  41:     0x55af53f7d75b - std::rt::lang_start_internal::h005ac2c1d40564a7
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/rt.rs:128:20
  42:     0x55af53e8c980 - std::rt::lang_start::h48e03617adc8bba4
                               at /rustc/f103b2969b0088953873dc1ac92eb3387c753596/library/std/src/rt.rs:144:17
  43:     0x55af53e89d1c - main
  44:     0x7f90c0eaf310 - __libc_start_call_main
  45:     0x7f90c0eaf3c1 -<EMAIL_ADDRESS>  46:     0x55af53e877a5 - _start
  47:                0x0 - <unknown>

Process finished with exit code 101

Not sure what you are trying to achieve:

if you just want decoded (as in containing file names, line numbers and function names) backtraces from panics, you don't need to enable the RUST_BACKTRACE flag at all. You just need a monitor, which is capable of mapping program counters output from the panic backtrace into filename+line number+function name triples. On embedded firmware, this decoding is not available out of the box, because it needs the original ELF binary and its debugging symbols, and these things are not burned onto the chip flash as they take too much space. Instead, you have to use a monitor which is capable of doing this decoding. For example, both espflash and espmonitor (the latter - with the --bin option pointing to the ELF file). Just mind this bug, which is opened since forever and which results in a bit unreadable output from espmonitor specifically

If you want to capture and print backtraces with normal Rust errors (as in anyhow errors; NOT panics), then and only then you need the discussed flag.

Ah thats interesting, so the formatting of the backtrace is handled by the monitor and not by the process itself? Didn't know that.
Doesn't seem very intuitive for me.
But if I understand you correctly, it also means the formatting should work out of the box if debug symbols are available in the binary. And they should be available in my case, at least I am testing with debug=true in my profile flags.
I got an esp32 with 16MB flash, so I got some headroom

I am actually trying to catch panics and format them like a default rust program without any configuration would do it, not just some results. I think the proper rust term for this process is unwinding.

Forget about panic-unwind on embedded. It will never, ever work for esp32 with its limited flash size. Treat panics as hard failures that restart the whole firmware. Embedded uses panic-abort, not panic-unwind. Why do you need panic-unwind on embedded anyway, where restarting the whole firmware takes a second?

Ah thats interesting, so the formatting of the backtrace is handled by the monitor and not by the process itself? Didn't know that. Doesn't seem very intuitive for me. Or do you mean the monitor can optionally do that, when the process doesn't out of the box? Since I've seen normally printed rust panics in normal terminals without any smart monitor features.

Again: there is just no place for the symbol tables with the debug info in the actual firmware. Even with 16 MB you are pushing it. Just no way. So it is always the monitor which decodes it, as the monitor which runs on your PC has access to the original elf binary that contrains the debug info. What is flashed on  the actual embedded firmware is only a portion of the elf -the one that contains the code and only the code basically. And the firmware outputs a panic backtrace that contains program counters. The monitor then greps them and decodes based on lookups inside the elf which stays on your PC and it has access to.

But if I understand you correctly, it also means the formatting should work out of the box if debug symbols are available in the binary. And they should be available in my case, at least I am testing with debug=true in my profile flags. I got an esp32 with 16MB flash, so I got some headroom

No you do t have a headroom, even with 16 mb. :)


travis ci testing: migrate from 3.5 and 3.6 to 3.6 and 3.7

Travis CI testing is passing on my fork

@weikang9009 once this passes shall I merge and check off the box in #59 or would you like to wait for other's reviews?

I am fine either way!


Review Chapter 01

This PR essentially introduces two changes in the code:

Add the installation of Git, which the previous version assumes that it was installed;
Introduces a new bash script that is non-based on Debian (Ubuntu) and can be used by machines with RHEL, Fedora, CentOS and hopefully MacOS.

-- Ricardo

Thanks for the PR!
A couple thoughts:

All the work for the 2nd edition is in the 2nd edition branch: https://github.com/brikis98/terraform-up-and-running-code/tree/2nd-edition. It doesn't make much sense to merge anything new into master right now.
This repo only contains code used directly in the book, and these scripts in particular aren't meant to be used directly; they are just there to illustrate a point about various tools for configuration management. Therefore, the scripts need to be analogous to the other options (e.g., the Ansible examples and the Terraform User Data example) and I'm not sure a RHEL version is necessary.


Postgres port conflict when postgres is running on host

It’s not unusual that a web devoloper runs an own postgres instance on the host, which also uses port 5432. In this case django-cms-quickstart fails to launch as it also wants to expose port 5432 on the host.
  database_default:
  # …
    ports:
      - "5432:5432/tcp"  # allow your local dev env to connect to the db

Possible solutions:

Don’t expose the port on the host:

-  ":5432/tcp"  # Don’t allow your local dev env to connect to the db

Expose a non-standard port:

- "5433:5432/tcp"  # allow your local dev env to connect to the db on a non-standard port

Use an environment variable and let the user decide.

that's done via
ports:
      - "${DB_PORT-}:5432/tcp"


Requests that exceed 2048 characters

From the readme file I can see that "These proxy files support: Requests that exceed 2048 characters"
How is this supported? Is there something I need to do in the configuration file? Or am I missing something else?
If I submit a long url (> 2048 chars) to the proxy using GET my arcgis server will return a 404.15 (Not found - long url). I was hoping that the proxy would somehow change my (too long) GET request to a POST request with a proper formatted body and the forward this request to the gis server.
PS. I am not using an esri javascript client but I am using viewers and workflows from latitude geographic as my client.

Jesper

Okay - thanks for quick reply.
I think someone should update the documentation that redirects people to this github project, eg. the javascript api documentation (https://developers.arcgis.com/javascript/3/jshelp/ags_proxy.html) because it states:
You may need to use a proxy in the following situations:
Requests exceed the limit on the length of the uniform resource locators (URLs) imposed by the browser. Common scenarios where you may run into URL length issues are when you use the buffer from a complex polygon as the input to a query task or if you specify a spatial reference using well-known text (WKT).
Note: Using a proxy works around this issue by performing a POST request rather than a GET request. POST requests are not limited by the 2048 character maximum because the information is transferred in the header instead of the URL.

Jesper

I think someone should update the documentation that redirects people to this github project

updated how exactly?
The ArcGIS API for JavaScript ensures internally that a POST will be used if the parameters being passed in a request would exceed the limit and that a valid proxy will be utilized if a cross domain request needs to be made to a server that isn't known to support CORS.

I think this section is misleading:
Requests exceed the limit on the length of the uniform resource locators (URLs) imposed by the browser. Common scenarios where you may run into URL length issues are when you use the buffer from a complex polygon as the input to a query task or if you specify a spatial reference using well-known text (WKT).
Note: Using a proxy works around this issue by performing a POST request rather than a GET request. POST requests are not limited by the 2048 character maximum because the information is transferred in the header instead of the URL.
English is not my native language, but when I read the documentation I thought that the proxy did the conversion from GET to POST. Keep in mind I am not necessarily using the other functionalities of the proxy (token, cross domain etc.). So if the JS API does the conversion from GET to POST I do not really need the proxy for the long requests right?

Jesper

So if the JS API does the conversion from GET to POST I do not really need the proxy for the long requests right?

since all modern browsers now support CORS, you only need a proxy if they web server you're making the request to does not.


SKPath iteration

It would be nice to wrap the SKPath::Iter class for iterating over paths.

Can you point us to a sample that you would like to replicate so we can study the approach to take?

@migueldeicaza I don't have a sample written, but the motivating use case (for me) is to traverse SKPaths in order to compute bounding boxes. I know there exist other Skia methods for computing rough bounding boxes, but I need tight boxes including path effects like stroking, and I haven't found methods that do that yet. Currently I'm accomplishing it by maintaining "shadow" paths in my C# code, e.g. just lists of the SKPoints, which allows me to traverse the points to compute the bounding boxes. It's fine with me if you'd like to close this issue, as perhaps it's outside of the scope of what SkiaSharp should worry about.

Would the skia PathMeasure class help with this?

This has been implemented.


Error due to missing createdAt in type Link of hn-starter.graphql schema

The React + Apollo Tutorial: https://www.howtographql.com/react-apollo/2-queries-loading-links/ Errors due to https://graphqlbin.com/hn-starter.graphql missing field createdAt in Link @nikolasburk
Not sure how you want to deal with this.
It is a really great tutorial so far and I enjoyed finding why the code kept throwing an error!
p.s. The graphcool instance of graphiql helped me find the error
query AllLinksQuery {
  allLinks {
    id
    createdAt
    url
    description
  }
}

{
  "data": null,
  "errors": [
    {
      "message": "Cannot query field 'createdAt' on type 'Link'. (line 21, column 5):\n    createdAt\n    ^",
      "locations": [
        {
          "line": 21,
          "column": 5
        }
      ]
    }
  ]
}

Hey @gyaresu! Sorry, we just made a change to our system yesterday and didn't update the tutorial accordingly yet.
The problem is that the original schema (stored here) you used to create the Graphcool project looked like this:
type Link {
  id: ID! @isUnique
  url: String!
  description: String!
}

Before the change in our system, createdAt and updatedAt always were required fields. So despite the fact that they were not explicitly added to the Link type, our system would still and and manage them for you. This is not the case any more. If you now want to use these fields, you need to explicitly add them to your types!
I just updated the starter schema to include these fields on the Link type:
type Link {
  id: ID! @isUnique
  createdAt: DateTime!
  updatedAt: DateTime!
  url: String!
  description: String!
}

There are two ways for you to fix the issue now:

Recreate the whole project with graphcool init --schema https://graphqlbin.com/hn-starter.graphql (which now includes these fields)
Update the Link type in your current project by adding the createdAt and updatedAt to your project.graphcool and run graphcool push in the terminal

Just a note. I'm going through this tutorial now. The step: Writing the GraphQL query on part Queries: Loading Links on tutorial Fetching Data using GraphQL Queries does not run. It is required to add a createdAt: String! element to the type Link in .../src/schema.graphql


InputChip incompatible with sveltekit superforms constraints

Current Behavior
When spreading the {...$constraints} on a InputChip there are issues (see screenshot).

Expected Behavior
Spreading {...$constraints} should work like how it works on a select element
Steps To Reproduce

Using InputChip
Create a zod schema
Create a superValidate form
Spread the constraints from the superForm function onto a Inputchip component
See typing errors

Link to Reproduction / Stackblitz
No response
More Information
No response

@Hugos68 was this one you were working to resolve? I'll assign the ticket to you if so. Just want to prevent duplicate effort.

@Hugos68 was this one you were working to resolve? I'll assign the ticket to you if so. Just want to prevent duplicate effort.

I am not currently working on it no, I won't have time to work on it either so it's up for grabs, I think it only affects typescript users since it was a type error.

Ok cool, thanks for clarifying!

So I've been looking into this issue and I noticed a couple of important errors:

$$restProps isn't being spread onto the input element like we say it does here (click on the Props tab).
There's an export called max that's used for the "Maximum number of chips". This export needs to have a different name as there is an existing native attribute for input that's also called max that users should be able to pass through with the extras of $$restProps.
We also have other exports like minlength and maxlength that should be applied as attributes to the input element.
We should probably provide a way for users to add attributes to the select element as well.

Unfortunately, I don't see a path in resolving point 2 in in a non-breaking way. I would suggest that we add that onto our v2 task list.

In an effort to prepare for Skeleton v3, we're consolidate some related issues down to a single ticket. This will ensure that we can see the full context of requests when the time comes to refactor and update this feature going forward. If you wish to add additional feedback or suggestions, please so here:

https://github.com/skeletonlabs/skeleton/issues/2364


Could not find package pkpass/pkpass

Hello, I am trying to install it and i get this message:
 [InvalidArgumentException]
  Could not find package pkpass/pkpass at any version for your minimum-stabil
  ity (stable). Check the package spelling or your minimum-stability

I on laravel 5.2.41

try composer require pkpass/pkpass@dev-master

hi, yes that worked, now im having this error.
filesize(): stat failed for /tmp/PKPass579fd76f631658.54142659/pass.pkpass

i think the problem is here:
PKPass.php
        // Get contents of generated file
        $file = file_get_contents($paths['pkpass']);
262- $this->clean();  <-- you remove the files here

        // Output pass
        if ($output == true) {
            $fileName = ($this->getName()) ? $this->getName() : basename($paths['pkpass']);
            header('Pragma: no-cache');
            header('Content-type: application/vnd.apple.pkpass');
269-   header('Content-length: ' . filesize($paths['pkpass'])); <--- you has for the file previously removed here

did this instead:

        // Get contents of generated file
        $file = file_get_contents($paths['pkpass']);
        $size = filesize($paths['pkpass']);
        $this->clean();

        // Output pass
        if ($output == true) {
            $fileName = ($this->getName()) ? $this->getName() : basename($paths['pkpass']);
            header('Pragma: no-cache');
            header('Content-type: application/vnd.apple.pkpass');
            header('Content-length: ' . $size);
            header('Content-Disposition: attachment; filename="' . $fileName . '"');

Let me know if thats ok and to check if you do an update to update the package on my project.
Thanks!

Yes, that seems to work perfectly! Would you mind doing a pull request with that change?


fix(docs): correct boolean input default value in workflow_dispatch

Description
When using the example workflow, linting raised an error. Specifically, the problem arises with the boolean default in the workflow_dispatch event.
Context
The error message is as follows:
Unexpected type 'StringToken' encountered while reading 'input default'. The type 'BooleanToken' was expected.

This is the section of code impacted:
https://github.com/Juulsn/todo-issue/blob/8c097a4b0b3f72dcda9591c96bf116a8b3e0928c/README.md?plain=1#L47-L56
This is because the default value for the importAll input was set to 'false', which is a string rather than a boolean. Removing the single quotes sets the default variable as a boolean.

#2 is a report of the issue initially. Since this has been changed to a boolean, this needs to be updated in the docs, and in the GitHub Actions of this repo.

Great, thanks!


Merchant Plant negative cleared capacities?

What should the merchant plant do with negative cleared capacity? It could:
a) not allow negative cleared capacity and throw an error
b) assume that negative cleared capacity means you're charging storage- in which case it could assume that 1) you're buying power at the current cleared price, or 2) you're buying power at a retail rate.
This needs some further investigation.

It looks like (b) is what's assumed currently - this is with cleared capacity = 100% of generation:

However, this is not correct, at I had selected "use retail electricity rates" for this model, so the merchant plant needs to do some of the same massaging of gen that single owner does currently.
Additionally, the line item for "electricity purchases" runs to be nearly the same as revenue when "use ppa or market prices" is chosen:

This is for a case where the battery only charges from PV, so I'm concerned a $/MWh is being interpreted as a $/kWh somewhere in this configuration.

Decision at SAM meeting is to ensure that option b) 2) is what the behavior is. The assumption is that your "negative cleared capacity" is actually electricity that needs to be purchased for your system.

Testing so far has identified the following problems:

If using market rates for electricity purchases, $/MWh needs to be converted to $/kWh (a fix for this is up on branch ssc_599_negative_cleared_capacity, but the additional issues should be resolved before a PR)
If using market rates for electricity purchases, cleared capacity is not accounted for, the full grid usage is multiplied by the price
"Energy market revenue" still includes the negative values of gen, so regardless of the purchase source the negative values are double counted in revenue and operating expenses right now.

The first and third have obvious fixes. For the second, if a project draws energy from the grid do we:
(a) Throw an error if the draw does not match the cleared capacity? OR
(b) Charge the project for everything it draws regardless of the cleared capacity? OR
(c) Charge the project for the cleared capacity regardless of what it draws?
Additionally, does cleared capacity matter if the project is purchasing at a retail rate?
Note that the oft-delayed https://github.com/NREL/SAM/issues/181 means it might be a while before batteries could account for charging limits if we choose (a).

Hmm. Thanks for the detailed investigation. For the second bullet, it does seem that "cleared capacity" should match the actual draw from the grid. I'd be tempted to go with (a)... or possibly (b), but throwing warnings for each timestep to indicate that it's happening. Thoughts from @cpaulgilman ?

One clarifying question with (b) - should any "extra" energy be purchased from the energy market by default, or whichever market has the largest cleared capacity? I'm a fan of the warnings at each timestep idea.
Also, for the third bullet point above, I was planning on splitting the positive and negative values of gen (/cleared capacities) so that the grid draw shows up as an operating expense. This should help make the LCOE consistent with single owner.

I associate "capacity" with generation, so I'm not sure what it means in the context of consumption. The purpose of the cleared capacity requirement is to guarantee that the system generates a minimum amount of power. I don't think it would apply to consumption, but that's just my intuitive sense. For a project that uses market prices for electricity purchases, I think it would be reasonable to go with (b) and use the energy market price as the purchase price along with the time step warnings.


Pagination

This PR connects to #46
Pagination component is based on ng-bootstrap pagination and it can be used with ng2-pagination pipe
To configure the pager you have to use pagination-options.model that extends NgbPaginationConfig, so options that are available are the same of NgbPagination documentation.
According to bootstrap responsive breakpoints, I've introduced new selector in hostWindowReducer that stores size of device window. By using new selector Pagination component is responsive and automatically resizes itself.
This is a component and its template that show how to use it.
I've to update ng-bootstrap and bootstrap packages so I've changed header component to make it work.

Looks good, a few comments:

I wouldn't add the bootstrap breakpoint to the state, as you can deduce it from the width, and we should avoid duplicating data in the state if possible. What I meant when I said on slack to "add a selector" was something like this
I can't get the links in a pagination component to work when javascript is disabled. Ideally this should also be supported server-side.
There are new dependencies, but yarn.lock isn't updated. It should contain the version numbers of all dependencies. You can fix this by runnning yarn in the root of the project. In the future, you're better off not touching package.json manually when you want to add dependencies, but running yarn add ${depname}. See README.md for more info.
When building I got a warning that ng2-pagination has been renamed to ngx-pagination. If it's compatible with angular 2 we might as well update immediately

Hi @artlowel

I wouldn't add the bootstrap breakpoint to the state, as you can deduce it from the width, and we should avoid duplicating data in the state if possible. What I meant when I said on slack to "add a selector" was something like this

Thanks for the suggestion, I'm going to implement it.

There are new dependencies, but yarn.lock isn't updated. It should contain the version numbers of all dependencies. You can fix this by runnning yarn in the root of the project. In the future, you're better off not touching package.json manually when you want to add dependencies, but running yarn add ${depname}. See README.md for more info.

I'll pay more attention in the future.

When building I got a warning that ng2-pagination has been renamed to ngx-pagination. If it's compatible with angular 2 we might as well update immediately

I get this error with ngx-pagination
Unexpected value 'NgxPaginationModule' imported by the module 'SharedModule'
Do you have any suggestion?

I can't get the links in a pagination component to work when javascript is disabled. Ideally this should also be supported server-side.

Without javascript It does not work completely, I didn't know it was a requirement to work without javascript, if so I need to get better in depth. Meanwhile, to accelerate merging, could we create a separate issue for this?

I get this error with ngx-pagination
Unexpected value 'NgxPaginationModule' imported by the module 'SharedModule'
Do you have any suggestion?

Yeah I had a similar issue with the upgrade to ngx-translate. The solution was to add the prefix of its package name to webpack.config.ts. See this commit
I added |@ngx-, in this case you'll probably have to add |ngx- since ngx-pagination's package name doesn't start with an @

Without javascript It does not work completely, I didn't know it was a requirement to work without javascript, if so I need to get better in depth. Meanwhile, to accelerate merging, could we create a separate issue for this?

A separate issue is fine.

@artlowel
I review PR based on your comments.

I've deleted breakpoint data from the state and added a service instead;
I've added an OpaqueToken to inject 'window' object in AppComponent to allow initialization of the state (I've missed this part in the first PR commit);
I've tried to update ngx-pagination, following your hint I don't get the error but unfortunately package works only with Angular >= 2.3.1 and I get mismatch versione error on AoT compilation;
Adding new host-window.service I've tried to import variables from sass unsuccessful. I've tried this  and this and in both cases I can't load the scss file because Angular didn't find loader module, Have you ever had any experience on this, or do you have another way to import sass variables?

Adding new host-window.service I've tried to import variables from sass unsuccessful. I've tried this and this and in both cases I can't load the scss file because Angular didn't find loader module, Have you ever had any experience on this, or do you have another way to import sass variables?

No I also didn't know how to do that, I just added the TODO comment as a reminder that we should fix it some day.
The yarn.lock update had as a side-effect that @ngrx/effects was updated to 2.0.3, and that depends on a version of rxjs that's too new, and conflicts with the version in our project. So please run yarn add<EMAIL_ADDRESS>to fix that problem
I also get a peer-dependencies warning about<EMAIL_ADDRESS>It probably also needs to be rolled back a few versions

@artlowel
done!


Add Events tab into UI

Ok, a first Events tab to complete the details of what we show.
Mostly reused the Alerts tab and linked from Dashboard.
Ah, also put in order Dashboard, Alerts, Events as it is close and leave to the end the definitions/actions.
I'm going to optimize some missing formats on Events but in a following PR.

@jshaughn or @jmazzitelli please take a look. Thx.

LGTM for initial event support.

looks good. FYI: Jay has new date-time picker - he should add it to this new events page to replace the date picker here.

Yeah, I release the PR with minimal changes as I was aware Jay could be working on similar area.
So, to minimize conflicts you can rebase on this and add changes you need.

Yes, my goal is to have a global datetime range applied to the relevant pages by the end of today.


Web Interface returns 404

The web interface returns a 404 on all http requests. This was tested with a local installation and the one at https://repo.panda-lang.org. This causes some web browsers to sometimes act strangely.

It's known issue. The 404 status is served, because Maven uses the same address to search for an artifact and it is required to declare that the requested file does not exist. In the future I'll discover the possibility to trick it.


fix ci

Related Issues
fixes #your-issue-number

Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).

[ ] I have updated the CHANGELOG.md of the relevant packages.
Changelog files must be edited under the form:
## Unreleased fix/major/minor

- Description of your change. (thanks to @yourGithubId)

[ ] If this contains new features or behavior changes,
I have updated the documentation to match those changes.

I made a PR by mistake. Never mind.


Add container build with docker

build with Go1.11
run docker in alpine

Note: This image does not contains config toml file and certification.
I'm happy if you host on https://hub.docker.com/r/mercari/gaurun/

[x] https://www.mercari.com/cla/

IMO, Dockerfile should be prepared indivisually when it is required.


sparse visualize command

Use an existing topology visualization tool like:

storm-spirit
StormSankey

or some mix of these, add a visualization command for topologies:
sparse visualize [(--name | -n) <topology>] (--format | -f (png|jpg|gif)) output_filename

I'm actually thinking I may be able to implement sparse visualize on the Python side if #84 gets implemented, since in that case I'll have a DAG that I can actually visualize available to me in-memory in Python. (The Clojure dependency situation is a bit intractable if I want streamparse-jvm to maintain compatibility with Storm 0.8.2 through 0.9.3.) Linking here so I don't forget about it.

I think we might also be able to come up with a way to do this on the Python side just using the REST API.  Won't work <0.9.2, but I think that's probably okay, since #52 won't either.

Hmm, I think I like the idea of being able to visualize your topology before submitting it to Storm. I don't think it'd be too bad given that we already have a simple DAG model and plan to render to Clojure, so adding a renderer for Graphviz's digraph format would probably a piece of cake.

I like the idea of being able to visualize your topology before submitting it to Storm

That's true; that would be nice.

adding a renderer for Graphviz's digraph format...

:+1: I like that idea.

The current sparse visualize does not work.

@rduplain I wanted to mention that now that Topology DSL is coming, we can write this in pure Python. And further, that we have some prior art for this that may be easy to adapt, which is the dask visualizer. It's described briefly here:
http://dask.pydata.org/en/latest/inspect.html

+1


Bot Bug and map view

Bot Stop Movement, And soon, Bot have Teleport.
This is the Problem video.
Desktop 2016.06.11 - <IP_ADDRESS>.zip
And you can see Map view is so far.
And I can see dead cells.
Please Fix it. :)

What game mode did you used? Note that experimental game mode currently has a broken code, so it has a bugs.
At a glance bots stops because there is too small amount of food. So, they don't see food

@Barbosik I used Gamemode 0.
No, I use Food amount 1800.
I think It's dead cells.
When i go to the dead cells,
I can through the cells.
And I can see dead foods.

it looks like it's because you're using client with protocol 5. It's related to clear message.
I will fix it.

@Barbosik Thank you,
I always Think, You are a Good Delveloper. :)

fixed, test it please

@Barbosik OK

@Barbosik Yes, it fixed


Allow DopplerSecret to be deployed to other namespaces

@nmanoogian I saw:

#21
#22

and would have preferred having the option to limit DopplerSecret to a specific namespace or even only reading tokens from the same namespace
it seems counter intuitive to the namespacing of kubernetes. The DopplerSecret should be able to reconcile be deployed to other namespaces. its the cross namespace access that was problematic allowing non operators to enumerate or access secrets that they did not have access to
I have a Doppler Token and own it and I am an application owner, I have to coordinate with the team that deploys the Doppler Operator to deploy my DopplerSecret just so that my namespace can have a secret. It seems we are artificially limiting who can manage DopplerSecret
External Secrets Operator would also allow also me to do it this way using SecretStore and Secret in the same namespace so I would suggest having Doppler Operator mimic that ability.
Thank you for your time :)

Hi @kzap, thanks for your feedback on this! We had some similar discussions about multi-tenancy over in #28.
We're still working internally to identify the best access control pattern for the operator. I'll follow up here with any details.


Add testimonials to the README

Pinging @dkorolev @iamleot @mcguiresm for approval.
Quotes from Slack, slightly modified to provide context.

Thanks fellas! Much appreciated 👍


'npm' is not recognized as an internal or external command, operable program or batch file.

Current Behavior:
$ create-react-app my-app

Creating a new React app in C:\Users\SwoleDaddyBuffNeck\my-app.

'npm' is not recognized as an internal or external command,
operable program or batch file.
Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...

'npm' is not recognized as an internal or external command,
operable program or batch file.

Aborting installation.
  npm install --save --save-exact --loglevel error react react-dom<EMAIL_ADDRESS>has failed.

I have tried everything under the sun, including uninstalling and reinstalling node, npm, and the create-react-app package, switching to a different version, and every variation of how to add npm to my PATH I could find on the internet. I dont usually have issues with npm, and I use it for several other projects, and it seems to work fine, I cannot figure out why it's only happening here. I could actually install react and react-dom manually, but when I tried installing react-scripts, it didnt output anything and I had to ctrl+c to get my console back.
I understand this is not a forum for npm, but as I described, I dont have this issue in other projects, and it works fine doing literally anything else. Any help would be greatly appreciated.

@ehsankhfr thanks for this! This worked like a charm for me. I was really struggling to sort out the same issue.
While OP didn't mention the environment they were using, just for reference I am using a portable dev setup - I have VS Code running an instance of git-bash as its terminal on Windows.
I know using a portable isn't ideal, but for my purposes it's the only practical solution aside from using remote virtual machines across the internet.
And using Windows complicates the npm/node/npx/git dynamic since I have to update npm & node manually.
So installing yarn was the perfect solution. Even the npm v < 5.1 instructions didn't help, as it ran into the same error message.
I hope others with this issue find this question. Thanks again!


Do not generate inactive instances

Before this change, the code was looking for an attribute named
active, but this is not what Glyphs.app stores in its files when an
instance gets marked as inactive in the Glyphs user interface. Instead,
Glyphs calls this attribute exports in its files.
Fixes https://github.com/googlei18n/glyphsLib/issues/129.

@schriftgestalt, did early versions of Glyphs use active instead of exports as attribute for flagging instances as (in)active?

I just tried to manually replace exports = 0 with active = 0 in a .glyphs source file, and Glyphs.app still recongizes the instance as inactive.
If I set active = 1 or if I remove the attribute, the instance becomes active again.
So it appears that both exports and active are recognized by Glyphs.app (2.4.1, 976) and that they have the same meaning, although exports is the one currently used when ticking the checkbox from the GUI.

Thanks, @anthrotype. Changed to recognize both. Have another look?


storage: filesystem, initialize the default folder scaffolding

It creates the default scaffolding for a .git folder exactly as cgit does
/cc @osklyar

@mcuadros When merged I will be able to simply the init logic in my client, nice!


'version' is not a valid attribute for a RoleMetadata

When using this role with Ansible 2.0, the following error is displayed: ERROR! 'version' is not a valid attribute for a RoleMetadata.
See ansible/ansible#13496

Confirmed.  The workaround is to comment it out at least.  I put instructions on how to do this on my blog.

@fuzzygroup thank you for that. I have been working to get all of our published roles up to date with ansible's changes. This one has fallen through the cracks but you will be seeing an update soon. :thumbs_up:

This would be fixed by https://github.com/crushlovely/ansible-sidekiq-upstart/pull/8


feat(route_selector): add processing time publisher

Description
The processing time of route_selector was measured and made to Pub.
Since A is not a module that is processed cyclically, Pub was added to the following four functions that may become heavy processing.

on_set_waypoint_route_main
on_set_lanelet_route_main
on_set_waypoint_route_mrm
on_set_lanelet_route_mrm

(TIER IV internal usecase)
This output is then read by the Basic scenario and tested daily for cycle failures.
Related links

How was this PR tested?

Place Ego and goal_pose in psim and generate route
ros2 topic echo /planning/mission_planning/route autoware_planning_msgs/msg/LaneletRoute > routefile
Delete start_pose and --- on the last line of the routefile
ros2 service call /planning/mission_planning/route_selector/mrm/set_lanelet_route tier4_planning_msgs/srv/SetLaneletRoute "$(cat routefile)"

Notes for reviewers
None.
Interface changes
None.

Effects on system behavior
None.

I want to disclose the time to handle exceptions.
Therefore, we have updated the handle_exception in service_utils.
This PR is closed because service_utils is located in mission_planner and the same content as this PR is included in the following PR.

https://github.com/autowarefoundation/autoware.universe/pull/9342/files

After consulting with @kosuke55 , it was decided not to output processing time in the event of an error.
Therefore, we will reopen this PR.


Update commons-codec version to 1.14 to fix third party bugs.

Description
Update commons-codec version from 1.11 to 1.14  in WSO2 AM 3.2.0 to fix third party bugs.
Steps to Reproduce
N/A
Affected Component
APIM
Version
3.2.0
Environment Details (with versions)
No response
Relevant Log Output
No response
Related Issues
No response
Suggested Labels
No response

Hi Team,
This is covered under pro active bumps for the release effort.
Thanks.


issue in the generation of sub-query blocks

What happened?
Dear developers,
Here are some details that would be helpful.
prql version: 0.8.1
comments: the sub-query blocks defined by with clause in sql queries from PRQL compiler select invalid columns from the table.
In the following example, prql code derives a new column new_c1 from tb1.c1*2 (line 2), then does three other operations and uses the new column (lines 3 to 5). However, inside the temporary table table_3 in the sql query (lines 1 to 7), it selects the new column directly instead of defining it.
PRQL input
from tb1
derive [new_c1 = c1*2]
join side:left tb2 [tb1.c0==tb2.c0]
sort [-tb1.new_c1]
select [d1 = tb1.c1*3]

SQL output
WITH table_3 AS (
  SELECT
    new_c1,
    c1,
    c0
  FROM
    tb1
),
table_2 AS (
  SELECT
    table_0.c1 * 3 AS d1,
    table_0.new_c1
  FROM
    table_3 AS table_0
    LEFT JOIN tb2 ON table_0.c0 = tb2.c0
  ORDER BY
    table_0.new_c1 DESC
)
SELECT
  d1
FROM
  table_2 AS table_1

Expected SQL output
WITH table_3 AS (
  SELECT
    c1 * 2 AS new_c1,
    c1,
    c0
  FROM
    tb1
),
table_2 AS (
  SELECT
    table_0.c1 * 3 AS d1,
    table_0.new_c1
  FROM
    table_3 AS table_0
    LEFT JOIN tb2 ON table_0.c0 = tb2.c0
  ORDER BY
    table_0.new_c1 DESC
)
SELECT
  d1
FROM
  table_2 AS table_1

MVCE confirmation

[X] Minimal example
[X] New issue

Anything else?
No response

Thanks, agree this is a bug.
Here's a simpler repro:
from tb1
derive [new_c1 = c1]
take 5
sort tb1.new_c1
select d1

WITH table_3 AS (
  SELECT
    d1,
    new_c1    # Doesn't exist!!
  FROM
    tb1
  LIMIT
    5
), table_2 AS (
  SELECT
    d1,
    new_c1
  FROM
    table_3 AS table_0
  ORDER BY
    new_c1
)
SELECT
  d1
FROM
  table_2 AS table_1

-- Generated by PRQL compiler version:0.8.1 (https://prql-lang.org)

I haven't caught up on the new referencing semantics yet but to me it's not that clear that this is a bug.
The compiler doesn't know what columns exist in tb1 and for all it knows there might be a column new_c1 there.
In the line derive [new_c1 = c1], that column is overridden/shadowed by a new column new_c1 which is an alias for c1.
Then in the line sort tb1.new_c1, you're explicitly telling it that you don't want the new new_c1 column but rather the original column new_c1 in tb1 so it sorts by that.
In the end you only care about d1 so both versions of new_c1 are discarded in the final output.

Sorry, you're completely correct @snth.
The original example works without the reference to tb1.new_c1:
from tb1
derive [new_c1 = c1*2]
join side:left tb2 [tb1.c0==tb2.c0]
sort [new_c1]
select [d1 = tb1.c1*3]

WITH table_3 AS (
  SELECT
    c1 * 2 AS _expr_0,
    c1,
    c0
  FROM
    tb1
),
table_2 AS (
  SELECT
    table_0.c1 * 3 AS d1,
    table_0._expr_0
  FROM
    table_3 AS table_0
    LEFT JOIN tb2 ON table_0.c0 = tb2.c0
  ORDER BY
    table_0._expr_0
)
SELECT
  d1
FROM
  table_2 AS table_1

-- Generated by PRQL compiler version:0.8.1 (https://prql-lang.org)

@YuxiLing let us know if that makes sense, feel free to reopen if I'm mistaken once more...

I actually find the following more problematic which is what you get when you remove the last line:
from tb1
derive [new_c1 = c1]
take 5
sort tb1.new_c1

which gives
WITH table_1 AS (
  SELECT
    *,
    c1 AS new_c1
  FROM
    tb1
  LIMIT
    5
)
SELECT
  *
FROM
  table_1 AS table_0
ORDER BY
  new_c1

-- Generated by PRQL compiler version:0.8.1 (https://prql-lang.org)

If there is already a new_c1 column in tb1, it is now being hidden and ignored although it appears to be directly referenced.

To me the bigger problem is that each step in the pipeline is a new relation and should really be explicitly referenceable. Power Query M Language takes the approach of explicitly requiring a name for each step. That is obviously quite verbose and not really desirable. Perhaps we could have a convenient syntax for this. My suggestion would be ^ like in git (HEAD^). This seems quite intuitive to me because it points upward.
Say you wanted to write pathological code like
from tbl
derive [x = x*x]        # squared
derive [x = x*tbl.x]    # cubed
derive [x = x*tbl.x]    # hybercubed / tesseracted / biquadrate
select [x=tbl.x, x_squared=^3.x, x_cubed=^^.x, x_hypercubed=^.x]

this would allow you to do it.

@max-sixty I agree. I'll remove that part and delete these comments.

If there is already a new_c1 column in tb1, it is now being hidden ignored although it appears to be directly referenced.

How would this be possible to work around, though?
That seems like some of the tradeoff of allowing * — I think this is a strong net benefit, but it does have its downsides...

Yeah, I'm not sure what the solution would be.
I guess I'm mostly concerned about the tb1.new_c1 reference in the sort transform.
from tb1
derive [new_c1 = c1]
take 5
sort tb1.new_c1

Why would we allow that? I feel it should either error saying "tb1.new_c1 is being shadowed by new_c1 in line 2" or the resultant SQL should explicitly reference tb1.new_c1. I don't know how you would do that in general but in DuckDB you could maybe do something like the following:
WITH table_1 AS (
  SELECT
    * EXCLUDE (new_c1),
    new_c1 AS _expr_0,
    c1 AS new_c1
  FROM
    tb1
  LIMIT
    5
)
SELECT
  *
FROM
  table_1 AS table_0
ORDER BY
  _expr_0

```elm
from tb1
derive [new_c1 = c1]
take 5
sort tb1.new_c1

Why would we allow that?

But IIUC — we don't allow it — there's no new_c1 on tb1 — it's on the pipeline now — and hence this issue. (Or am I misunderstanding?)

If there was a discussion about the new reference semantics, maybe point me at that and let me catch up because I missed that and I might well be misunderstanding something.
In the case where there is no new_c1 in tb1 it still doesn't make sense to me to allow referring to tb1.new_c1 because new_c1 was only introduced in line 2 which is a separate relation from tb1 and tb1 doesn't have a new_c1 column.
What happens in the case of joins?
from tb1
join tb2 (==id)
derive [new_c1 = c1]
select [new_c1, tb1.new_c1, tb2.new_c1]

Are all three references in the select allowed? I think it should only be the first one.

I just tried the last example on the playground and it errors on the derive saying that c1 is ambiguous. Fair enough, fixing that to the following
from tb1
join tb2 (==id)
derive [new_c1 = tb1.c1]
select [new_c1, tb1.new_c1, tb2.new_c1]

gives
SELECT
  tb1.c1 AS _expr_0,
  tb1.new_c1 AS _expr_1,
  tb2.new_c1
FROM
  tb1
  JOIN tb2 ON tb1.id = tb2.id

-- Generated by PRQL compiler version:0.8.1 (https://prql-lang.org)

And another take
from tb1
join tb2 (==id)
derive [new_c1 = tb1.c1 + tb2.c1]
select [new_c1, tb1.new_c1, tb2.new_c1]

gives
SELECT
  tb1.c1 + tb2.c1,
  tb1.new_c1 AS _expr_0,
  tb2.new_c1
FROM
  tb1
  JOIN tb2 ON tb1.id = tb2.id

-- Generated by PRQL compiler version:0.8.1 (https://prql-lang.org)

I don't think that's ideal or consistent really.

Here are two examples you can try in the playground:
Case 1: tb1 doesn't have a new_c1 column
new_c1 in this case is new_name which doesn't exist in playlists.
from playlists
derive [new_name = playlist_id]
sort playlists.new_name

This executes and sorts by playlist_id which seems like a bug to me because there is no such column as playlists.new_name.
Case 2: tb1 does have a new_c1 column
new_c1 in this case is name.
from playlists
derive [name = playlist_id]
sort playlists.name

This incorrectly sorts by the second name column which is actually playlist_id.
Interestingly if you put a take 5 in then it renames the duplicate column and sorts correctly, i.e. by the name which actually exists in the playlists table.
from playlists
take 5
derive [name = playlist_id]
sort playlists.name

Great cases, I agree those should both error...


add syntax for Graphviz’ GVPR format

Graphviz, the graph visualization software, comes with its own scripting
language for graph manipulation, “GVPR.” The syntax support for this language
that is added in this commit comes from the Graphviz repository. It was written
and then refined within the Graphviz repository, intended to be eventually
proposed for inclusion within Vim itself.

This has not had much (any?) feedback from Vim experts, so if you have recommendations or would like changes to this please let me know.

Matthew Fernandez wrote:

Graphviz, the graph visualization software, comes with its own
scripting language for graph manipulation, “GVPR.” The syntax support
for this language that is added in this commit comes from the Graphviz
repository. It was written
and then refined within the Graphviz repository, intended to be eventually
proposed for inclusion within Vim itself.

This has not had much (any?) feedback from Vim experts, so if you have
recommendations or would like changes to this please let me know.

It looks OK, but it should save/set/restore 'cpo' because of using line
continuation.  See other syntax files for examples.
The gvpr file format is not recognized yet.  Is this simply using the
.gvpr file name extension?
--
SOLDIER: What?  Ridden on a horse?
ARTHUR:  Yes!
SOLDIER: You're using coconuts!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

It looks OK, but it should save/set/restore 'cpo' because of using line continuation. See other syntax files for examples.

Thanks for the pointer. Updated.

The gvpr file format is not recognized yet. Is this simply using the .gvpr file name extension?

GVPR is old enough that file extensions weren't in common use for things like this. Most of the early users' GVPR programs don't have any extension. Is there a status quo for how this sort of situation is handled in Vim? It would even be OK to have no auto-detection for this and require users to have their own autodetect rule or manually set syntax=gvpr, if this sort of thing is acceptable.
You can see some sample GVPR programs in the Graphviz repository, https://gitlab.com/graphviz/graphviz/-/tree/main/cmd/gvpr/lib

It looks OK, but it should save/set/restore 'cpo' because of using
line continuation. See other syntax files for examples.

Thanks for the pointer. Updated.

The gvpr file format is not recognized yet. Is this simply using the
.gvpr file name extension?

GVPR is old enough that file extensions weren't in common use for
things like this. Most of the early users' GVPR programs don't have
any extension. Is there a status quo for how this sort of situation is
handled in Vim? It would even be OK to have no auto-detection for this
and require users to have their own autodetect rule or manually set syntax=gvpr, if this sort of thing is acceptable.
You can see some sample GVPR programs in the Graphviz repository, https://gitlab.com/graphviz/graphviz/-/tree/main/cmd/gvpr/lib

Apparently the file also also known as "dot", and we do recognize .dot
and .gv file extensions as "dot" files.
But we already have a dot syntax file.  And it doesn't look similar to
yours.
--
Kiss me twice.  I'm schizophrenic.
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Dot is a different format. Dot is the format for describing graphs, used as input to the main Graphviz program, dot. GVPR is an awk-like scripting language used for manipulating such dot graphs. The manpage for the GVPR interpreter is at https://gitlab.com/graphviz/graphviz/-/blob/main/cmd/gvpr/gvpr.1.

Thanks for the explanation.  It's up to the user to set 'fileformat' then.  I'll include the syntax file now.
Please don't forget to send me an update if you make improvements.

Thanks, Bram!


Detect specifics code changes when filename change.

When you're working on a file and want to rename it. Even if you've only changed one line of code and go to "source control" it says that the whole file contains only lines that have been added.
This is very annoying if you absolutely want to know at a glance which line you've modified or not when you're using a tool like Gitlens that tells you which line has been modified by whom.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Documentation corrections & navigation.

Corrected some of the documentation and added a link to the commands
documentation from the Readme.

Thanks Beau for the documentation fixes.


_vector_table: off by one, options missing pop?

In trying to build my own understanding of how the interrupt flow works, I've been spending a while staring at the different parts of the code. This PR is part "question I don't know how to answer" and part "I noticed this probably isn't right".
For the latter, I'm fairly confident that 6d5e3d4 fixes an actual bug: I didn't try too hard to come up with a test case that exposes the bad behavior, but inspecting the contents of memory (see below)  I saw
mtvec = 0x42000300 [_vector_table:??:??] ( _vector_table = 0x42000300 [_vector_table:??:??])
0x42000300 [_vector_table:??:??]: 0xe31ff06f
...
0x42000370 [_vector_table:??:??]: 0xdc1ff06f
0x42000374 [_vector_table:??:??]: 0xdbdff06f
0x42000378 [_vector_table:??:??]: 0xdb9ff06f
0x4200037c [_start_trap_rust_hal:??:??]: 0xc7867155

the instructions ending in 0x06f look like they decode to jal x0, <immediate> (AKA the "j" pseudo-instruction with an offset that's changing by 0x04 slot by slot as the relative jump gets further (or closer?) to go to the same place. The entry at mtvec+0x7c there, though, looks like it's two (compressed) instructions 0x7155 and 0xc786 that sure could start a function prologue, so I'm inclined to believe whoever is mapping that address to a symbol (espflash, maybe?) that it's the start of the rust-level trap function.
For the question part: it seemed very strange to me that there would be a lonely .option push with no corresponding .option pop hanging out so far away from where most of the assembler options were being configured. Changing the order of things around didn't seem like it had much of an impact, probably because the vector table is at the end of the assembly block? But if there were more things added below it, they would all be subject to the .balign 0x100 and .option norelax, even if .option pop were used to restore the previous value of the rvc setting, right? (Also, the .section name and "ax" flags, but those look fairly common to leave in situ).
59a1c2b is my best guess at capturing the intent there, though I do wonder if it would be better to move the vector table into its own global_asm! entirely and/or delete the .option push. I'm also happy to put the rock back and revert that commit as well, whatever y'all think is best.
inspecting memory
the snippet of a program I used to examine the _vector_table:
  extern "C" {
      #[link_name = "_vector_table"]
      fn vtable();
  }

  unsafe {
      let table = vtable as *const u32;
      println!(
          "mtvec = 0x{:x} ( _vector_table = 0x{:x})",
          mtvec::read().address(),
          table as usize
      );

      for i in 0..32 {
          let t = table.add(i);
          println!("0x{:x}: 0x{:x}", t as usize, *t);
      }
  }

Excellent, thanks for the review!


Some Bug?

There no action on inteljidea
on step 2 https://github.com/hamza-cskn/obliviate-invs/wiki
[I'm still in the stage of trying to make a plugin.]

Solved with Gui lol, pls fix your wiki lmao

Solved with Gui lol, pls fix your wiki lmao

xd thank you.


feat: add codemods for number.* polyfills

Nothing much to do with those polyfills packages. Except removing the possible imports.
Luckily they're not popular (based on downloads).

Related: https://github.com/es-tooling/module-replacements/pull/110

Thanks for the PRs! Can you double check the before fixtures? I'm missing imports for the packages that should be removed. Thanks!

Thanks for the PRs! Can you double check the before fixtures? I'm missing imports for the packages that should be removed. Thanks!

You're right, I fixed em.
Good to note: I am not sure if I got the imports right. Because to be honest, I struggle to understand the complexity of the polyfill system 🤷

Yeah I think this is fine for now, the es-shims polyfill api or whatever is pretty weird, we can improve on it in the future if it turns out to be a problem. The largest uses of these packages are fairly straightforward; import function, call function.
Thanks for the contribution!


Balance of LP Token BCH-DIF is not correct

Actual behavior:
Just the balance of one of my addresses is shown as balance for BCH-DFI. Also the cli command "gettokenbalances" shows me to less balance for BCH-DFI. This is since 2.4.0
The balances of other LP-Tokens are correct.
But when i check my addresses in https://dex.defichain.com/mainnet/pool, all balances are correct
Expected behavior:
the sum of all balances of all my addresses for BCH-DFI has to shown in DeFi Wallet.
What are your environment parameters?

DeFi Wallet Version: 2.4.0
Operating System (OS): Mac OS 11.4
– Current free storage capacity: 195 GB

Hi @baludwi , update v2.4.2 is out, this is a mandatory update.
Please read through the release notes before updating. Do give a thumbs up to this comment if your issue has been resolved, otherwise, please send new information (include screenshots) and app logs. Thank you.


battery/OpenBSD: improved charge%, adds status

This commit adds support for:

hw.sensors.acpibat0.amphour[03] for battery charge statistics. OpenBSD's acpibat(4) uses either this or hw.sensors.acpibat0.watthour[03] kernel states, so on some laptops Neofetch wasn't able to get the battery charge percentage.
Charging status

It passes shellcheck and i tried to stick to CONTRIBUTING the best i could.

LGTM :+1:
Thanks!

You're welcome :)


Improve ONNX quantization doc

Fixes https://github.com/huggingface/optimum/issues/1418

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Upload test contracts with ink-wrapper itself.

Currently, we upload contracts in the Makefile using cargo contract upload. ink-wrapper outputs code that can upload contracts as well. We should set up tests (i.e. upload contracts) using ink-wrapper generated code instead.
@obrok , does that sound good? Or was there a reason for doing it via cargo contract that I am now forgetting?

It's mostly historic - we didn't have that functionality at the beginning.


vuejs app architecture for dynamic template with dynamic data and dynamic component type issue

Sorry for posting 'issue' here. I have posted question on vue forum and stackoverflow but with no feedback. I am now developing an app with vuejs and the architecture is important from begining.
Here is the link:
http://forum.vuejs.org/topic/4604/how-to-address-component-with-dynamic-template-and-its-relative-data
http://stackoverflow.com/questions/38342241/vuejs-better-way-to-address-component-with-dynamic-template-and-its-relative-dat
I copy here for kind proposal. It is an architecture issue.
I have following question/requirement, if anyone has good idea, please kindly post for discussion It is for the dynamically rendering for dynamical template and data use component The scenario is as following:
1.root vue instance fetch data from backend, say following data returned:
[
{
    /* this section will be fed to a component */
    type: 'FirstSub',
    templatestr: '<div> <more-vue-customized-component itsdata="xxx"></more-vue-customized-component>  </div>',
    data: [
        datafordynamicComponent: xxxx
    ]

},
...
{
    /* this section will be fed to a component */
    type: 'lastSub',
    templatestr: '<p> <more-vue-customized-component itsdata="xxx"></more-vue-customized-component>  </p>',
    data: [
        datafordynamicComponent: xxxx
    ]

}

Which structure/architecture we can use to render as following composition using above data?

<root>
<FirstSub></FirstSub>
...
<lastSub></lastSub>
</root>

Does this solve your problem?
<component v-for="item in yourComponentsFromAPI" is="item.name" :some-prop="item.data">
</component>

@fnlctrl , thanks for your response. That dynamic component pattern can meet the requirement if we have no "dynamically loaded template".  The templatestr string data works as the template for the FirstSub/lastSub component.
The only gap here is: how we dynamic compile and make alive FirstSub component with its template and other data in live reactive manner.
thanks to @yyx990803 , i found async component pattern can bridge some gap(can make dynamic loaded html into live). @fnlctrl , Unfortunately, i do not know how to give props to async component.
That is to say: if  yourComponentsFromAPI contains an async component, how can we access the some-prop property within that async component??
Again, I have raised one stackoverflow for that specific question:
http://stackoverflow.com/questions/38344091/vuejs-can-we-give-props-to-async-component-via-dynamic-component-pattern-compo
Thanks~!

@fnlctrl , please see live fiddle here:
https://jsfiddle.net/matiascx/wjab87om/8/

How "dynamic" is your ajax loaded template? Are they arbitrary and random? If not, have you tried extracting the "dynamic" bits and create static components (they can be async-loaded with webpack)
If you just need to pass props to a dynamically created component, use propsData

Hello ..
your issue is a usage/support question, and the issue tracker is reserved exclusively for bug reports and feature requests.
And you seem to know this.
So this issue is closed now.

@fnlctrl , you are right, if i extract the dynamic data in the template string, it can work. But not want to do that way. I'd like to save the templatestr(including some variables)into database and fetch it as a whole.
Throw the data to vuejs for rendering.
propsData seems not valid for dynamical component?
thanks~!

@fnlctrl , i have no idea how to make webpack work, now i use browersify , unfortunately, it can not support that feature you mentioned.(async-loaded )

Here is a related issue with feature request  https://github.com/vuejs/vue/issues/2114.
I have wrote a component-proxy  to  resolve it which may do some  help to  you.
import _ from 'lodash'
import Vue from 'vue'

export default {
  props: ['name', 'props', 'value'],
  template:  '',
  created(){
    let props = []
    if(this.props ){
      // apply properties to component data
      _.forOwn(this.props, (value, key)=>{
        // console.debug( key,  this[key])
        props.push(`:${_.kebabCase(key)}="props['${key}']"`)
      })
    }

    // console.debug('component proxy', props.join(' '))
    this.$options.template = `<component :is="name" ${props.join(' ')} :value.sync="value"></component>`
  },
}

```

About usage:

```jade
.ui.form
    .field(v-for="column in table.columns")
      label {{column.title}}
      component-proxy(:name="column.editor.type",:props="column.editor.propsData",:value.sync="column.name")
```

@terrydai , thanks, it seems it is a great idea, i will do some try.. For the usage, i can not understand well.
What does .field and .ui.form mean?  Would you give a little explain on your usage code?
thanks a lot!

@cnweibo  It is  jade template ,    using Semantic-UI

@terrydai , i have found your contribution on https://github.com/vuejs/vue/issues/3231 ,great idea.
in your comments, what is the intention for value.sync here? can you give a small explain on :name,:props and :value.sync respectively? I have not full caught what should i do following your proposal.
component-proxy(:name="column.editor.type",:props="column.editor.propsData",:value.sync="column.name")

thanks~!

@cnweibo  you need to review jade docs  and my component-proxy definition above

@terrydai , i got it, that is defined in jade


Can't connect to custom local interpreter

In Workspace window, click Add.
Click on the browse button next to the path text box, and pick the same folder R Client\RSERVER folder as in the picture below:

Save and click connect.  Progress bar appears and it never connects.
If you cancel VS hangs. Dump here: \pytools\r\Bugs\2954

Reproes for me as well.

https://github.com/Microsoft/RTVS/commit/16f3e664e51f2f88e8ad7220eed50bcff3358709


Type check window for env detection instead of document

Issue: https://github.com/mochajs/mocha/issues/1764

See discussion in #1764


Usage: Pass app's module rather than file path.

Is your feature request related to a problem? Please describe.
Not a "real" problem, just smth that feels incredibly odd and unpythonic:
fastream run src/path/to/python/module/__init__:variable_name (without the .py extension)
(either using / or .)
Having to put the src or the __init__ feels just wrong....
Your app can end up in .venv/lib/[.......] or any other place, the CLI should just leverage python's module resolution to get this done.
Describe the solution you'd like
Should be able to start the app with
fastream run module.import.string:my_variable
Feature code example
In the CLI, rather than the "get_app_path", "try_import_app", smth like:
import importlib
from faststream import FastStream
from faststream.exceptions import FastStreamException  # TODO

module_path, application_name = app.split(":")

# Raises a ModuleNotFoundError if not found
module = importlib.import_module(module_path)

# Raises an AttributeError if not found
app = getattr(module, application_name)

# Extra: checkout the app type
if not isinstance(app, FastStream):
    raise FastStreamException(
        f"{application_name} in {module_path} is not a FastStream application (found: {type(app)})"
    )

I can't undestand the real problem
FastStream supports the following syntax
fastream run module.import.string:app_object

The same with uvocorn/gunicorn/etc way

Well, I got it, thank you for the Issue!
I, think, we can just copy and reuse the original uvicorn importer
Added it to backlog

The new release fixes this:
https://github.com/airtai/faststream/releases/tag/0.2.14


Complete desk research into the size and structures of other design working groups

What
Find out how other design working groups at other organisations run.
Why
So we know what to aim for when creating a design working group for the NHS digital service manual.
Relates to
EPIC: Create a design system working group #666
Depends on

Other design working groups existing
Other groups working in open ways for us to be able to observe

Who needs to know about this
User researchers @henocookie  @amyj2110 , service manual team
Done when
Tasks we need to do:

[ ] Compile research
[ ] Document findings in a presentable format

GOV.UK Design System working group - Principles and ways of working

MOJ (Ministry of Justice) Design system working group

Notes: Red-gate design working group
Meeting held on 18-Nov-20
Design system name: Honeycomb
Working group: organically formed
Group size: 8 [4 designers/ 4 developers]
Group make up: Broad design set [brand, product, interaction], developers [front-end, full stack]
Schedule: 2hrs every Friday morning + high level planning on Thursday with head of product and head of engineering
Format: standup [roundtable, catch-up, problems, collaboration, prioritisation]
Facilitation: One lead facilitator
Decisions: Group consensus, disagreement gets resolved by head of product and head of engineering
Motivation: developers join to boost skills, tries to match role with those looking for development opportunity. Gives VIP treatment to contributors [faster responses]
Communications: share progress on slack
Advocacy: relies on members to act as trojan to reach other developers. Uses same with head of product and head of engineering as backing

See also https://github.com/nhsuk/nhsuk-service-manual/issues/812


No module named 'milvus_database'

hello, how can I solve the problem of "No module named 'milvus_database'"?

hello, May I ask you how to solve this problem?

I'm sorry for the late reply. you can import milvus_database.py from src/embedding/.

I've never seen this error and I suggest you refer to milvus docs to figure out this problem.


Command /prisma/migrate/deploy impl

done by https://github.com/violet-ts/violet-infrastructure/pull/19


Changed both Hall fields from "IntegerField to CharField"

Upon registration in my localhost server it was showing error in datatype value of Hall No. because it was set to integer..Changing it to CharField has resolved it.
New Feature Submissions or Bug Fixes:

[x] Does your submission pass build tests locally?
[x] Have you indented your code locally prior to submission?

Changes to Core Features:

[ ] Have you added an explanation of what your changes do and why you'd like us to include them?

@rapperdinesh Thanks for catching this issue !