MAINT:Translate the entirety of cephes into C++

Update: I've rewritten this PR message since the original I wrote when this was a work-in-progress is no longer relevant.
This PR translates the entirety of Cephes into C++ capable of running on CUDA through conditional compilation. This PR is rebased on #20405 which is rebased on #20089 which is rebased on #19954, so though still gargantuan, the true diff is a little smaller than what is seen now.
Most of this was fairly straightforward, there was just a lot of it. One challenge was translating double-double arithmetic from cephes/dd_real.c and friends (actually from the qd extended precision package) into C++. I chose to do this in a more modern style with operator overloading.
The old cephes has been removed entirely. I wrote C wrappers for use in Cython and C files which have not been translated to C++. special_c_wrappers.cpp for special functions, and dd_real_wrappers.cpp for double double arithmetic, which is used in _cunity.pxd and which has test code written in Cython.
 Thanks for agreeing to review this in your time between terms.

This is rebased on the branch for #20089 which is in turn rebased on the branch for #19954. If someone merges those, the diff on this one will shrink a little. cc @rlucas7, @tirthasheshpatel, @rgommers

I’ll investigate more closely later, but it seems like the failures in stats on Linuxes 32 bit and aarch64 would be ok to resolve with tolerance bumps. Some of them look like exact equality checks.

I’ll take a look this weekend.-Lucas Roberts On Apr 4, 2024, at 7:27 PM, Albert Steppi @.***> wrote:
I’ll investigate more closely later, but it seems like the failures in stats on Linuxes 32 bit and aarch64 would be ok to resolve with tolerance bumps. Some of them look like exact equality checks.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

I’ll take a look this weekend.

Thanks. I appreciate it.

I've completely excised the old C cephes and all tests pass locally. What remains is

Figure out if the couple of failing stats tests can just have their tolerances bumped.
Add a healthy number of comments explaining why some things are structured as they are. Particularly for wrappers for calling cephes functions from C and Cython, and any time where cephes double double arithmetic is used outside of cephes.

The trickiest thing in this PR was probably getting the double double arithmetic to work. I opted to write it in a more modern style using operator overloading. Fortunately there was already direct testing for the double double arithmetic, because these tests failed at first despite all tests for functions passing.
Phew. That is the largest diff I've ever worked on.

I've tried to rebase this on #20405, but things won't compile due to unsuccessful resolution of conflicts with #20403, which I merged today. @izaid, can you submit a PR to this branch fixing these conflicts? I could probably figure it out, but I'm running out of steam. The issue seems to be with using old cephes functions in the new ufunc infrastructure.
Here's a sample of the errors I get when I try to compile.

../scipy/special/_special_ufuncs.cpp: In function ‘PyObject* PyInit__special_ufuncs()’:
../scipy/special/_special_ufuncs.cpp:184:10: error: invalid ‘static_cast’ from type ‘int(double, double*, double*, double*, double*)’ to type ‘func_d_dpdpdpdp_t’ {aka ‘void (*)(double, double*, double*, double*, double*)’}
  184 |         {static_cast<func_d_dpdpdpdp_t>(special::airy_wrap), static_cast<func_D_DpDpDpDp_t>(special::cairy_wrap)}, 4,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../scipy/special/_special_ufuncs.cpp:184:62: error: invalid ‘static_cast’ from type ‘int(std::complex<double>, std::complex<double>*, std::complex<double>*, std::complex<double>*, std::complex<double>*)’ to type ‘func_D_DpDpDpDp_t’ {aka ‘void (*)(std::complex<double>, std::complex<double>*, std::complex<double>*, std::complex<double>*, std::complex<double>*)’}
  184 |         {static_cast<func_d_dpdpdpdp_t>(special::airy_wrap), static_cast<func_D_DpDpDpDp_t>(special::cairy_wrap)}, 4,
      |                                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../scipy/special/_special_ufuncs.cpp:183:38: error: no matching function for call to ‘SpecFun_NewUFunc(<brace-enclosed initializer list>, int, const char [5], const char*&)’
  183 |     PyObject *airy = SpecFun_NewUFunc(
      |                      ~~~~~~~~~~~~~~~~^
  184 |         {static_cast<func_d_dpdpdpdp_t>(special::airy_wrap), static_cast<func_D_DpDpDpDp_t>(special::cairy_wrap)}, 4,
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  185 |         "airy", airy_doc);
      |         ~~~~~~~~~~~~~~~~~
In file included from ../scipy/special/_special_ufuncs.cpp:17:
../scipy/special/ufunc.h:220:11: note: candidate: ‘PyObject* SpecFun_NewUFunc(std::initializer_list<SpecFun_Func>, int, const char*, const char*)’
  220 | PyObject *SpecFun_NewUFunc(std::initializer_list<SpecFun_Func> func, int nout, const char *name, const char *doc) {
      |           ^~~~~~~~~~~~~~~~
../scipy/special/ufunc.h:220:64: note:   no known conversion for argument 1 from ‘<brace-enclosed initializer list>’ to ‘std::initializer_list<SpecFun_Func>’
  220 | PyObject *SpecFun_NewUFunc(std::initializer_list<SpecFun_Func> func, int nout, const char *name, const char *doc) {
      |                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
../scipy/special/ufunc.h:239:11: note: candidate: ‘PyObject* SpecFun_NewUFunc(std::initializer_list<SpecFun_Func>, const char*, const char*)’
  239 | PyObject *SpecFun_NewUFunc(std::initializer_list<SpecFun_Func> func, const char *name, const char *doc) {
      |           ^~~~~~~~~~~~~~~~
../scipy/special/ufunc.h:239:11: note:   candidate expects 3 arguments, 4 provided
../scipy/special/_special_ufuncs.cpp:188:41: error: invalid ‘static_cast’ from type ‘int(double, double*, double*, double*, double*)’ to type ‘func_d_dpdpdpdp_t’ {aka ‘void (*)(double, double*, double*, double*, double*)’}
  188 |     PyObject *airye = SpecFun_NewUFunc({static_cast<func_d_dpdpdpdp_t>(special::cairy_wrap_e_real),
      |                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../scipy/special/_special_ufuncs.cpp:189:41: error: invalid ‘static_cast’ from type ‘int(std::complex<double>, std::complex<double>*, std::complex<double>*, std::complex<double>*, std::complex<double>*)’ to type ‘func_D_DpDpDpDp_t’ {aka ‘void (*)(std::complex<double>, std::complex<double>*, std::complex<double>*, std::complex<double>*, std::complex<double>*)’}
  189 |                                         static_cast<func_D_DpDpDpDp_t>(special::cairy_wrap_e)},
      |                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../scipy/special/_special_ufuncs.cpp:188:39: error: no matching function for call to ‘SpecFun_NewUFunc(<brace-enclosed initializer list>, int, const char [6], const char*&)’
  188 |     PyObject *airye = SpecFun_NewUFunc({static_cast<func_d_dpdpdpdp_t>(special::cairy_wrap_e_real),
      |                       ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  189 |                                         static_cast<func_D_DpDpDpDp_t>(special::cairy_wrap_e)},
      |                                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  190 |                                        4, "airye", airye_doc);
      |                                        ~~~~~~~~~~~~~~~~~~~~~~
In file included from ../scipy/special/_special_ufuncs.cpp:17:
../scipy/special/ufunc.h:220:11: note: candidate: ‘PyObject* SpecFun_NewUFunc(std::initializer_list<SpecFun_Func>, int, const char*, const char*)’
  220 | PyObject *SpecFun_NewUFunc(std::initializer_list<SpecFun_Func> func, int nout, const char *name, const char *doc) {
      |           ^~~~~~~~~~~~~~~~
../scipy/special/ufunc.h:220:64: note:   no known conversion for argument 1 from ‘<brace-enclosed initializer list>’ to ‘std::initializer_list<SpecFun_Func>’
  220 | PyObject *SpecFun_NewUFunc(std::initializer_list<SpecFun_Func> func, int nout, const char *name, const char *doc) {
      |                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
../scipy/special/ufunc.h:239:11: note: candidate: ‘PyObject* SpecFun_NewUFunc(std::initializer_list<SpecFun_Func>, const char*, const char*)’
  239 | PyObject *SpecFun_NewUFunc(std::initializer_list<SpecFun_Func> func, const char *name, const char *doc) {
      |           ^~~~~~~~~~~~~~~~
../scipy/special/ufunc.h:239:11: note:   candidate expects 3 arguments, 4 provided
../scipy/special/_special_ufuncs.cpp:276:35: error: ‘cephes_iv’ was not declared in this scope
  276 |         {static_cast<func_dd_d_t>(cephes_iv), static_cast<func_dD_D_t>(special::cbesi_wrap)}, "iv", iv_doc);
      |                                   ^~~~~~~~~
../scipy/special/_special_ufuncs.cpp:275:36: error: no matching function for call to ‘SpecFun_NewUFunc(<brace-enclosed initializer list>, const char [3], const char*&)’
  275 |     PyObject *iv = SpecFun_NewUFunc(
      |                    ~~~~~~~~~~~~~~~~^
  276 |         {static_cast<func_dd_d_t>(cephes_iv), static_cast<func_dD_D_t>(special::cbesi_wrap)}, "iv", iv_doc);
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../scipy/special/_special_ufuncs.cpp:17:
../scipy/special/ufunc.h:220:11: note: candidate: ‘PyObject* SpecFun_NewUFunc(std::initializer_list<SpecFun_Func>, int, const char*, const char*)’
  220 | PyObject *SpecFun_NewUFunc(std::initializer_list<SpecFun_Func> func, int nout, const char *name, const char *doc) {
      |           ^~~~~~~~~~~~~~~~
../scipy/special/ufunc.h:220:11: note:   candidate expects 4 arguments, 3 provided
../scipy/special/ufunc.h:239:11: note: candidate: ‘PyObject* SpecFun_NewUFunc(std::initializer_list<SpecFun_Func>, const char*, const char*)’
  239 | PyObject *SpecFun_NewUFunc(std::initializer_list<SpecFun_Func> func, const char *name, const char *doc) {
      |           ^~~~~~~~~~~~~~~~
../scipy/special/ufunc.h:239:64: note:   no known conversion for argument 1 from ‘<brace-enclosed initializer list>’ to ‘std::initializer_list<SpecFun_Func>’
  239 | PyObject *SpecFun_NewUFunc(std::initializer_list<SpecFun_Func> func, const char *name, const char *doc) {
      |                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
[59/85] Compiling C++ object scipy/special/_ufuncs_cxx.cpython-311-x86_64-linux-gnu.so.p/meson-generated__ufuncs_cxx.cpp.o
ninja: build stopped: subcommand failed.
Build failed!

I've tried to rebase this on #20405, but things won't compile due to unsuccessful resolution of conflicts with #20403, which I merged today. @izaid, can you submit a PR to this branch fixing these conflicts? I could probably figure it out, but I'm running out of steam. The issue seems to be with using old cephes functions which no longer exist in the new ufunc infrastructure.
Here's a sample of the errors I get when I try to compile.

Think we fixed this now.

Think we fixed this now.

Yes, fixed thanks to your help. I missed that this morning when editing out comments that were no longer relevant.

One detail I am starting to see is that we are using inline keyword everywhere. Though the compiler is free to ignore it or inline it when there is no inline, we don't need to force it all the time because it has the risk of bloating the binaries due to repetitive code expansion. Just FYI. And I did a similar mistake in the Cython code too but I think we don't need repeat the mistake again.

I think it is a bit too late but If you also use the git's rename option then it would be possible to get a smaller diff and also a chance to still see the git history.

One detail I am starting to see is that we are using inline keyword everywhere. Though the compiler is free to ignore it or inline it when there is no inline, we don't need to force it all the time because it has the risk of bloating the binaries due to repetitive code expansion. Just FYI. And I did a similar mistake in the Cython code too but I think we don't need repeat the mistake again.

Thanks @ilayn! Good point, but it actually does have a use in C++. It allows a function to appear in two different translation units, see the first answer here for instance https://stackoverflow.com/questions/29796264/is-there-still-a-use-for-inline
We are doing it by design. :)

One detail I am starting to see is that we are using inline keyword everywhere. Though the compiler is free to ignore it or inline it when there is no inline, we don't need to force it all the time because it has the risk of bloating the binaries due to repetitive code expansion. Just FYI. And I did a similar mistake in the Cython code too but I think we don't need repeat the mistake again.

I think making everything inline is necessary to avoid symbol clashes in a header only library. I was getting errors in some cases when leaving them out, in particular for functions which are used in ufuncs but also called in C code through wrappers.  Things need to be header only so they can work on CUDA, but I've been trying to think of ways to mitigate increase in binary size.

One detail I am starting to see is that we are using inline keyword everywhere. Though the compiler is free to ignore it or inline it when there is no inline, we don't need to force it all the time because it has the risk of bloating the binaries due to repetitive code expansion. Just FYI. And I did a similar mistake in the Cython code too but I think we don't need repeat the mistake again.

I think making everything inline is necessary to avoid symbol clashes in a header only library. I was getting errors in some cases when leaving them out, in particular for functions which are used in ufuncs but also called in C code through wrappers. Things need to be header only so they can work on CUDA, but I've been trying to think of ways to mitigate increase in binary size.
Update: @izaid beat me to it.

I believe there are ways to have it instantiate only once. But if we put all the ufuncs in a single Python extension like _special_ufuncs.cpp, we won't need that anyway.

I think it is a bit too late but If you also use the git's rename option then it would be possible to get a smaller diff and also a chance to still see the git history.

I don't think it's too late actually. While I was working on this, I had to keep the old cephes around, and didn't think of the now obvious idea of backing up each cephes file before I translated it, doing git mv, and then replacing the cephes C file with its backup. Even before you mentioned it, I've thought about backing up the new C++ files, starting over, and doing git mv, and then immediately replacing each with its updated C++ version. It wouldn't be anywhere near as tedious as translating 80+ files from cephes, so I'd be happy to do it if it will make review easier.

We are doing it by design. :)

I didn't know that, thanks. This feature© of C++ is just insane to me but what do I know. As long as I don't touch C++, not my problem.

Things need to be header only so they can work on CUDA

I still don't get this why but I take your word for it. However, if true they are creating the next fortran libraries of the future. Hopefully I won't be around to retranslate it 😅
We should not be adjusting everything to CUDA though, since our main userbase has nothing to do with a proprietary framework. Not implying anything malicious just a nano-ping

@steppi Review done! Obviously this is a huge amount of amazing work, so that's really fantastic. I've put some comments in about how I think things can be done for "best practice". For the most part, I've excluded applying that to the original cephes algorithms because they have so much history.

Thanks @izaid! I've applied the suggestions from your comments. I've kept double_double arithmetic in its own namespace however. I think it seems clearer within the functions using it to do things like using special::dd_real::double_double. I like that it makes it more explicit that double_double arithmetic is being used, and provides reminders at the calling site that double_double versions of functions are being applied.
Also, it makes it easier for these things to be found when called from inside special::cephes::detail. (I get errors sometimes when trying to call stuff from outside the detail namespaces when inside of them). I consider the use of these double_double types as just an implementation detail, so wouldn't want them in the top level namespace, but putting them in special::cephes::detail seems off to me too, although this would make things the cleanest, because special::cephes::detail is the only place double_double arithmetic is used outside of the C wrappers.

Before I do that though, I want to try to fix the failing tests on 32 bit Linux, but just haven't had time to debug yet.

Yes don't mind me. It is just a "nice-to-have" when all stabilized.

I traced the failing 32 bit tests to g++ optimizations on 32 bit systems rearranging things in a way that produces a less accurate result for cephes implementation of log of gamma when x is > 1000.. I've managed to fix these failing tests locally by conditionally using pragmas to disable optimizations on 32 bit systems for cephes when the compiler is gcc. I still need to resolve all of the merge conflicts to get things to run in CI.

Merge conflicts finally resolved. If there are no relevant test failures I'll use a script to redo this preserving cephes history, and then force push.

This is starting to look awesome !

I'm giving up on preserving the ties to the old cephes. Most of the diffs are too large for git to detect, mostly due to indentation level changing by putting everything in namespaces. For the ones that aren't too large, git already detected them, even without using git mv.

I guessed so. It would be much of a surgery that is probably not needed. And I think it is legacy code that we can find elsewhere should there would be any need for it

Related: when testing I found a build warning (with GCC 12) that came from a previous PR - it'd be nice to address that in a follow-up:

Ah yes, in scipy/special/special/loggamma.h there's a complex valued gamma implementation with signature
std::complex<double> gamma(std::complex<double> z)

that lives in the special namespace.
@izaid's intention in scipy/special/special/gamma.h here:
https://github.com/scipy/scipy/blob/b4f3037e04bd0d312cd671b7d1d5d9ffd8923472/scipy/special/special/gamma.h#L18-L21
is to write a templated version which can handle 32 bit float input in the ufuncs, by passing the inputs to the double version, but that the resolution works correctly seems like it might be based on undefined behavior. @izaid, what do you think we should do here? Just explicitly write a gamma with signature
std::complex<float> gamma(std::complex<float> z)

maybe?

Thanks @rgommers! I appreciate that you went to the length of checking the full diff. Good catch that I missed the comment about the static variables.

Related: when testing I found a build warning (with GCC 12) that came from a previous PR - it'd be nice to address that in a follow-up:

Ah yes, in scipy/special/special/loggamma.h there's a complex valued gamma implementation with signature
std::complex<double> gamma(std::complex<double> z)

that lives in the special namespace.
@izaid's intention in scipy/special/special/gamma.h here:
https://github.com/scipy/scipy/blob/b4f3037e04bd0d312cd671b7d1d5d9ffd8923472/scipy/special/special/gamma.h#L18-L21
is to write a templated version, (also in the special namespace), which can handle 32 bit float input in the ufuncs, by passing the inputs to the double version, but that the resolution works correctly seems like it might be based on undefined behavior. @izaid, what do you think we should do here? Just explicitly write a gamma with signature
std::complex<float> gamma(std::complex<float> z)

maybe?

Yeah, that should just be calling our complex gamma function. I can fix it in another PR, it's unrelated to anything here.

All right - merged! Thanks a lot @steppi and @izaid 🚀


Images losing resolution

Hello,
Thanks for creating this theme! It's amazing.
I would like to ask; The images are losing their resolution when it's shown on either pages (home, photos). Is it due to the resize function making images lose resolution drastically? Or some kind of compression issue?
Anyway, Is there any fix to this? Please help.
Also, I'll try to solve it too.

Hello,
Have you solve it ? I'm also stuck at this point.
Thanks,

I use the built-in Resize function to resize the image (e.g., here). If you want to change the size of the image, please modify the template.


When trying to confirm the tx, the call returns "Insufficient balance" -  more transparency might be needed around what kind of balance they need to interact with an extrinsics.

After https://github.com/paritytech/substrate/issues/5678 is finished, we should add support for a new attribute macro.
This attribute macro should be similar to the weight and should expose information about deposits, locks etc to the outside. This could be combined with the transaction payment pr to find out how much balance a user requires for a certain transaction, instead of doing trial and error as described above.
So we will require the following:

Some type that expresses how much and for what a transaction requires tokens (reserve, spent, etc)
Add a new attribute macro (name tbd)
If the attribute macro is not given, we would only fallback to show the amount of tokens being payed for the transaction itself.
Provide a RPC that probably replaces the transaction payment RPC to make these information accessible.

Provide a RPC that probably replaces the transaction payment RPC to make these information accessible.

Can't the content of this new attribute macro be a new filed in the metadata?

@rrtti with just your description and and the title I can barely understand the issue, can you elaborate bit more? and is it similar to this? https://github.com/paritytech/substrate/issues/7240

@kianenigma For that reason I have added a comment that explains on what should be done :P

Regarding #7240, this is something different AFAIK. This new macro should be able to express stuff like deposits. So, you can query how much actual tokens you need (deposit + fees). Currently we can only query the fees and we need to know that a certain function requires a fixed amount for deposits.


could JSON dependency be relaxed to >= 1.8?

https://github.com/CurrencyCloud/currencycloud-ruby/blob/259c7fab87d137cc7c9b450ade8b2771826c5875/currency_cloud.gemspec#L17
1.8 is 4 years old now

Hi @yachi, this is now implemented in v0.12.5


capi: Release official CAPI's.

Changes:

Removed beta api tag from CAPI module
For some APIs, the tag has not been changed due to main API status
Moved some documentation changes to have similar descriptions in main
API and CAPI
Removed deprecation warnings.

waiting for @mgrudzinska  @mmaciola 's verification.


chore: remove unnecessary primer.css conflicting with minima theme

It seems to me use of primer.css (GitHub default's design system) conflicts with this blog's theme ("minima" customized) in some places, but most importantly unvisited links.
This result in being unable to distinguish in a blog post which are the available links (common in websites). Examples will be provided down below.
This PR proposes to remove primer.css imports to avoid said conflicts.
This PR is continued from: https://github.com/kubeflow/blog/pull/150#issuecomment-2220198719
cc @StefanoFioravanzo @rimolive @juliusvonkohout wdyt?
Examples today Vs this_pr

as can be seen in Netlify preview in the action runs below.

It looks better to me :-)

fwiw it looks better to be too :rocket:
/lgtm


crash app when write app in Arabic

use floem::IntoView;
use floem::views::text;

fn app_view() -> impl IntoView {
    text("السلام عليكم")
}

fn main() {
    floem::launch(app_view)
}

error:
warning: testapp v0.1.0 (/home/igbaria/dev/MyProjects/RustProjects/testapp) ignoring invalid dependency `lapce` which is missing a lib target
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.26s
     Running `target/debug/testapp`
thread 'main' panicked at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-cosmic-text-0.7.2/src/shape.rs:108:17:
begin <= end (10 <= 8) when slicing `السلام`
stack backtrace:
   0: rust_begin_unwind
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:652:5
   1: core::panicking::panic_fmt
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/panicking.rs:72:14
   2: core::str::slice_error_fail_rt
   3: core::str::slice_error_fail
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/str/mod.rs:89:5
   4: core::str::traits::<impl core::slice::index::SliceIndex<str> for core::ops::range::Range<usize>>::index
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/str/traits.rs:244:21
   5: core::str::traits::<impl core::ops::index::Index<I> for str>::index
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/str/traits.rs:62:9
   6: floem_cosmic_text::shape::shape_fallback
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-cosmic-text-0.7.2/src/shape.rs:108:17
   7: floem_cosmic_text::shape::shape_run
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-cosmic-text-0.7.2/src/shape.rs:220:37
   8: floem_cosmic_text::shape::ShapeWord::new
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-cosmic-text-0.7.2/src/shape.rs:429:32
   9: floem_cosmic_text::shape::ShapeSpan::new
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-cosmic-text-0.7.2/src/shape.rs:497:28
  10: floem_cosmic_text::shape::ShapeLine::new
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-cosmic-text-0.7.2/src/shape.rs:613:24
  11: floem_cosmic_text::buffer_line::TextLayoutLine::shape
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-cosmic-text-0.7.2/src/buffer_line.rs:200:35
  12: floem_cosmic_text::buffer_line::TextLayoutLine::layout
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-cosmic-text-0.7.2/src/buffer_line.rs:222:25
  13: floem_cosmic_text::buffer::TextLayout::shape_until
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-cosmic-text-0.7.2/src/buffer.rs:395:26
  14: floem_cosmic_text::buffer::TextLayout::shape_until_scroll
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-cosmic-text-0.7.2/src/buffer.rs:454:28
  15: floem_cosmic_text::buffer::TextLayout::set_text
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-cosmic-text-0.7.2/src/buffer.rs:585:9
  16: floem::views::label::Label::set_text_layout
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/views/label.rs:167:9
  17: <floem::views::label::Label as floem::view::View>::layout::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/views/label.rs:393:21
  18: floem::context::LayoutCx::layout_node
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/context.rs:845:25
  19: <floem::views::label::Label as floem::view::View>::layout
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/views/label.rs:388:9
  20: <alloc::boxed::Box<dyn floem::view::View> as floem::view::View>::layout
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:327:9
  21: <alloc::boxed::Box<dyn floem::view::View> as floem::view::View>::layout
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:327:9
  22: floem::view::recursively_layout_view::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:191:24
  23: floem::context::LayoutCx::layout_node
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/context.rs:845:25
  24: floem::view::recursively_layout_view
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:186:5
  25: floem::view::View::layout
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:245:9
  26: <alloc::boxed::Box<dyn floem::view::View> as floem::view::View>::layout
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:327:9
  27: <alloc::boxed::Box<dyn floem::view::View> as floem::view::View>::layout
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:327:9
  28: floem::view::recursively_layout_view::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:191:24
  29: floem::context::LayoutCx::layout_node
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/context.rs:845:25
  30: floem::view::recursively_layout_view
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:186:5
  31: floem::view::View::layout
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:245:9
  32: <alloc::boxed::Box<dyn floem::view::View> as floem::view::View>::layout
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:327:9
  33: <alloc::boxed::Box<dyn floem::view::View> as floem::view::View>::layout
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:327:9
  34: floem::view::recursively_layout_view::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:191:24
  35: floem::context::LayoutCx::layout_node
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/context.rs:845:25
  36: floem::view::recursively_layout_view
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:186:5
  37: floem::view::View::layout
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/view.rs:245:9
  38: floem::context::LayoutCx::layout_view
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/context.rs:854:9
  39: floem::window_handle::WindowHandle::layout
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/window_handle.rs:517:18
  40: floem::window_handle::WindowHandle::process_update_no_paint
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/window_handle.rs:694:17
  41: floem::window_handle::WindowHandle::process_update
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/window_handle.rs:667:12
  42: floem::app_handle::ApplicationHandle::handle_updates_for_all_windows
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/app_handle.rs:392:13
  43: floem::app_handle::ApplicationHandle::idle
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/app_handle.rs:387:9
  44: floem::app::Application::run
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/app.rs:143:9
  45: floem::app::launch
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/1589f5a/src/app.rs:34:5
  46: testapp::main
             at ./src/main.rs:259:5
  47: core::ops::function::FnOnce::call_once
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Process finished with exit code 101

It should be fixed now in latest main.

thank you
it's work now, but it needs more work for text_editor
The cursor in the text_editor is not behaving as expected when typing or navigating with the keyboard.
I apologize for not being able to assist at this time, as I'm currently new to Rust development.

I encountered an error that I couldn't identify the cause of. I was typing randomly in Arabic between English words.
cargo run --color=always --package untitled4 --bin untitled4
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.23s
     Running `target/debug/untitled4`
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
Editor changed
thread 'main' panicked at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/editor/visual_line.rs:1744:9:
line: 0, line_index: 1, line_count: 2, vline: RVLine { line: 0, line_index: 1 }, start: 109, end: 101, backwards: false text_len: 111
stack backtrace:
   0: rust_begin_unwind
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:652:5
   1: core::panicking::panic_fmt
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/panicking.rs:72:14
   2: <floem::views::editor::visual_line::VisualLinesRelative<T> as core::iter::traits::iterator::Iterator>::next
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/editor/visual_line.rs:1744:9
   3: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::next
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/iter/adapters/map.rs:108:9
   4: <core::iter::adapters::take::Take<I> as core::iter::traits::iterator::Iterator>::next
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/iter/adapters/take.rs:41:13
   5: <core::iter::adapters::enumerate::Enumerate<I> as core::iter::traits::iterator::Iterator>::next
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/iter/adapters/enumerate.rs:48:17
   6: floem::views::editor::normal_compute_screen_lines
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/editor/mod.rs:1545:28
   7: floem::views::editor::text::Document::compute_screen_lines
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/editor/text.rs:157:9
   8: floem::views::editor::Editor::compute_screen_lines
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/editor/mod.rs:481:9
   9: floem::views::editor::create_view_effects::{{closure}}::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/editor/mod.rs:1419:36
  10: core::option::Option<T>::map
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/option.rs:1075:29
  11: floem_reactive::signal::signal_update_value
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/reactive/src/signal.rs:407:9
  12: floem_reactive::signal::RwSignal<T>::update
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/reactive/src/signal.rs:57:13
  13: floem::views::editor::create_view_effects::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/editor/mod.rs:1418:9
  14: floem::views::editor::create_view_effects::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/editor/mod.rs:1497:9
  15: <floem_reactive::effect::Effect<T,F> as floem_reactive::effect::EffectTrait>::run
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/reactive/src/effect.rs:235:25
  16: floem_reactive::effect::run_effect::{{closure}}::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/reactive/src/effect.rs:173:13
  17: floem_reactive::scope::with_scope
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/reactive/src/scope.rs:129:18
  18: floem_reactive::effect::run_effect::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/reactive/src/effect.rs:171:9
  19: std::thread::local::LocalKey<T>::try_with
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/thread/local.rs:283:12
  20: std::thread::local::LocalKey<T>::with
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/thread/local.rs:260:9
  21: floem_reactive::effect::run_effect
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/reactive/src/effect.rs:167:5
  22: floem_reactive::signal::Signal::run_effects
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/reactive/src/signal.rs:366:13
  23: floem_reactive::signal::signal_update_value
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/reactive/src/signal.rs:409:5
  24: floem_reactive::signal::RwSignal<T>::try_update
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/reactive/src/signal.rs:68:9
  25: floem::views::editor::text_document::TextDocument::update_cache_rev
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/editor/text_document.rs:109:9
  26: <floem::views::editor::text_document::TextDocument as floem::views::editor::text::Document>::receive_char
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/editor/text_document.rs:226:17
  27: floem::views::editor::Editor::receive_char
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/editor/mod.rs:474:9
  28: floem::views::editor::view::editor_content::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/editor/view.rs:1180:25
  29: floem::views::decorator::Decorators::on_event_stop::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/views/decorator.rs:172:13
  30: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/alloc/src/boxed.rs:2077:9
  31: floem::context::EventCx::unconditional_view_event::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/context.rs:439:35
  32: <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::fold
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/slice/iter/macros.rs:230:27
  33: floem::context::EventCx::unconditional_view_event
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/context.rs:438:24
  34: floem::window_handle::WindowHandle::event
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/window_handle.rs:191:34
  35: floem::window_handle::WindowHandle::key_event
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/window_handle.rs:385:13
  36: floem::app_handle::ApplicationHandle::handle_window_event
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/app_handle.rs:185:21
  37: floem::app::Application::run::{{closure}}
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/app.rs:151:21
  38: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/ops/function.rs:294:13
  39: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/ops/function.rs:294:13
  40: floem_winit::platform_impl::platform::wayland::event_loop::EventLoop<T>::single_iteration
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-winit-0.29.4/src/platform_impl/linux/wayland/event_loop/mod.rs:461:13
  41: floem_winit::platform_impl::platform::wayland::event_loop::EventLoop<T>::poll_events_with_timeout
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-winit-0.29.4/src/platform_impl/linux/wayland/event_loop/mod.rs:323:9
  42: floem_winit::platform_impl::platform::wayland::event_loop::EventLoop<T>::pump_events
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-winit-0.29.4/src/platform_impl/linux/wayland/event_loop/mod.rs:237:13
  43: floem_winit::platform_impl::platform::wayland::event_loop::EventLoop<T>::run_on_demand
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-winit-0.29.4/src/platform_impl/linux/wayland/event_loop/mod.rs:201:19
  44: floem_winit::platform_impl::platform::EventLoop<T>::run_on_demand
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-winit-0.29.4/src/platform_impl/linux/mod.rs:821:56
  45: floem_winit::platform_impl::platform::EventLoop<T>::run
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-winit-0.29.4/src/platform_impl/linux/mod.rs:814:9
  46: floem_winit::event_loop::EventLoop<T>::run
             at /home/igbaria/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem-winit-0.29.4/src/event_loop.rs:249:9
  47: floem::app::Application::run
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/app.rs:144:17
  48: floem::app::launch
             at /home/igbaria/.cargo/git/checkouts/floem-69eea0a757d1e3ee/32c41cb/src/app.rs:34:5
  49: untitled4::main
             at ./src/main.rs:76:5
  50: core::ops::function::FnOnce::call_once
             at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Process finished with exit code 101


Bug with encapsed strings

PHP Version
7.4 and 8.0
Code Example
"$property->name[]";

Actual Behavior
==> syntax error: unexpected '[' at line 2

Expected Behavior
No error.

"$a[10]: some".      is $a[10] . ": some"
"$a->prop[10]: some" is $a->prop . "[10]: some"


Can i Use this library with SignalR core

what SignalR versions are supported by this library?

I have not tried this, but I am fairly confident the answer is no. There were a number of breaking changes in SignalR core to simplify on the server side.  At this time, we have not looked into supporting SignalR core.

Zsign technical support:
Apple signature tool supporting ios15 and ios16
Support the removal of dylib dynamic library
Completely free, permanently free!
https://urlzs.com/44zCx


Browse By Category Alignment Issue

Describe your specific features or fixes
Fixes alignment issue with browse by category block at large screen resolutions
Resolves: MWPW-NUMBER
Test URLs:

Before: https://main--express--adobecom.hlx.page/express/
After: https://browse-by-cat-alignment--express--adobecom.hlx.page/express/print

merging as hotfix for print


fix(product): don't modify original product when building variant attributes

The old code deleted the attribute of an object that was part of the original product attribute. So instead of correct format:
{ name: 'attributeName', value: 'attributeValue' }

we had:
{ name: 'attributeName' }

in the variant attributes of the original product. I fixed it by replacing the old code with the one from the new node SDK.
https://github.com/commercetools/nodejs/blob/ab8edfb41bdc7d429f20554d3d8a45ef251228f8/packages/sync-actions/src/product-actions.js#L286

[ ] commit messages are commitizen-friendly
[ ] code is unit tested
[ ] code is integration tested
[ ] public code is documented
[ ] code is reviewed by at least one person
[ ] code satisfies linter rules

Coverage decreased (-0.05%) to 97.528% when pulling 681f74c3e9dfa594fae056f6e03df5d1b6709f68 on fix/original-attributes-modified into 1fae3107f22c4f03ac7be2c481eb89904bd4340d on master.

Coverage decreased (-0.05%) to 97.528% when pulling ceab3833e361dbb958ba5f53db1b820bcdb5f1b9 on fix/original-attributes-modified into 1fae3107f22c4f03ac7be2c481eb89904bd4340d on master.

Coverage decreased (-32.8%) to 64.733% when pulling ceab3833e361dbb958ba5f53db1b820bcdb5f1b9 on fix/original-attributes-modified into 1fae3107f22c4f03ac7be2c481eb89904bd4340d on master.


fix: autofill on server side

Fix: Autofill on Server Side
This issue has been successfully resolved by implementing a fix for the server-side autofill functionality as seen in gh-40 . Previously, there were inconsistencies and error messages when trying to fill in the form, causing inconvenience and inaccuracies in data entry. With the recent fix, users can now experience a seamless and accurate autofill process on the server side. This improvement ensures that relevant data is automatically populated with precision, enhancing user efficiency and reducing manual data entry errors. Our team should thoroughly test and implemented the fix to guarantee a reliable and efficient autofill experience. Thanks!

hi @mosespace thank you for opening this pr

please elaborate more on autofillling on server side
please guide on how the changes in this PR can be tested out

Attention:
Hello, @HassanBahati It appears that using chrome causes the error message to appear. I've tested it on various browsers, and to my surprise, it functions flawlessly. However, it seems that after completing out the form, nothing is sent; instead, a blank email window is opened, requiring the user to input their message again.

Attention:
Hello, @HassanBahati It appears that using chrome causes the error message to appear. I've tested it on various browsers, and to my surprise, it functions flawlessly. However, it seems that after completing out the form, nothing is sent; instead, a blank email window is opened, requiring the user to input their message again.

ohh that could...i have been testing this on chrome..
please share screenshorts/screencasts of what your test results are like on the other browsers

also please elaborate more on autofillling on server side....how this is happening and how it is being implemented..
from what i see happening is that the changes here are addition of autoComplete="on" attribute  on the input tag
please help me understand how its translating into autofilling on server side

This preview is of Fire Fox

also please elaborate more on autofillling on server side....how this is happening and how it is being implemented..
from what i see happening is that the changes here are addition of autoComplete="on" attribute on the input tag
please help me understand how its translating into autofilling on server side

On the server side, autofilling often combines client-side input with server-side processing. One of the ways to enable autofilling in HTML forms is by using the autoComplete="on" attribute, as I previously indicated. This attribute tells the browser to offer autofill suggestions based on previously entered data when it is added to an input tag.
I hope this explanation helps clarify how autofilling on the server side works. Let me know if you have any further questions!


Create example using the NREL solar radiation data

I have worked with NREL solar radiation data on a separate project.  It wouldn't take me long to make an example notebook that downloads the solar radiation CSVs from here in one of the NREL historical data sets and uses dask / pandas to work with the CSVs of hourly data.

Sounds great!


Fix clippy warnings in core crates

For #996
cargo clippy --all -- -A clippy::missing_safety_doc can now run without any warnings.  Note that this excludes every #[test] unless --all-targets is passed, which does not lint cleanly yet.

@kennykerr What do you think about gradually introducing clippy to windows-rs instead? It's quite the burden to fix tons of warnings in the tests (that usually intentionally write things a certain "inefficient" way for validation) or to write appropriate # safety docs, when it is anyway much more relevant to keep the published crates clean and held to a certain standard instead.
After this PR we can reopen #996 and I can subsequently change the command to the one listed above. I'll document the desire to enable --all-targets at some point, as well as removing -A clippy::missing_safety_doc.

Let's get what we can building. I don't know what's involved with getting the tests clean but if that's minimal let's do it. Otherwise we can at least get everything else clean as a start.

@kennykerr There's a lot of noise from comparing against boolean literals with assert_eq!(), a bunch of .len() == 0 and a bunch of nontrivial operations with copies for the tests; I don't dare to touch those as I'm not entirely certain what you're trying to test.
Shall I push as many fixes as possible to this PR and get #996 reinstantiated, then you can look at the warnings and fix the remaining issues that require some more thought?

Sounds good - thanks!


Proofreading pass

@rotycenh

OPS Build status updates of commit c0dfcc5:
:warning: Validation status: warnings

File
Status
Preview URL
Details

toc.json
:warning:Warning

Details

bread/toc.json
:warning:Warning

Details

building-blocks/extending-templates/toc.json
:warning:Warning

Details

docs/cloud-adoption/governance/security-management/overview.md
:white_check_mark:Succeeded
View

toc.json

[Warning] Error happen when converting toc.json to Pdf. Details: Could not find file 'T:\boaz\toc.json'.

bread/toc.json

[Warning] Error happen when converting bread/toc.json to Pdf. Details: Could not find a part of the path 'T:\boaz\bread\toc.json'.

building-blocks/extending-templates/toc.json

[Warning] Error happen when converting building-blocks/extending-templates/toc.json to Pdf. Details: Could not find a part of the path 'T:\boaz\building-blocks\extending-templates\toc.json'.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Escape class names in selectors

This fixes handling of classes containing special characters (such as ':').
Older browsers may require CSS.escape() polyfill.
Fixes michu2k/Accordion#61

I wouldn't classify this as a bug, but as a new possibility to allow different class formats.
Anyway, looks good, polyfill may not be needed. Thanks


[ISSUE-3476] style: narrow css specificity for code elements

Why:
All code elements written as markdown in mdx files via backticks will automatically have the nextra-code class.
Any other code elements that could come from custom components, might not want the default nextra style applied to it.
In fact, if you have tailwind applied to your custom <code> elements, it will be overwritten by the global code:not([class*='twoslash-']) specifier since it has a higher specificity.
If someone prefers the global css for custom <code> elements, they can add the class nextra-code to get it applied still.
Closes:
https://github.com/shuding/nextra/issues/3476
What's being changed (if available, include any code snippets, screenshots, or gifs):
css specifier
Check off the following:

[x] I have reviewed my changes in staging, available via the View
deployment link in this PR's timeline (this link will be available after
opening the PR).

I think we should do the same for line<EMAIL_ADDRESS>wdyt?
Note
we need add new class for \<pre\> since it doesn't have for now 😅 ignore it, we select code anyway

Good catch.
It's safer indeed if someone wanted to to a custom .


Cant change Toggle Block Comment shorcut

Does this issue occur when all extensions are disabled?: Yes

VS Code Version:  1.75.0
OS Version: Elementary OS 6.1 (Ubuntu 20.04.5)

Steps to Reproduce:

Open the shortcuts configuration tab.
Change 'Toggle Block Comment' keybinding (Default -> ctrl + ç)

When I change the Toggle Block Comment bind from default to [ctrl + ç] it appears when I press enter as [ctrl + y].
I have tried with the extensions disabled and it does not allow to replace the shortcut correctly either. Of course this shortcut [ctrl + ç] is not in use in any other shortcut.

All my customs shortcuts are reset (or nor working).
My keybindings.json file is correctly set (at least it used to work with the previous VSCode version)
[
    {
        "key": "ctrl+d",
        "command": "-editor.action.addSelectionToNextFindMatch",
        "when": "editorFocus"
    },
    {
        "key": "ctrl+d",
        "command": "editor.action.duplicateSelection"
    },
    {
        "key": "ctrl+k ctrl+c",
        "command": "-editor.action.addCommentLine",
        "when": "editorTextFocus && !editorReadonly"
    },
    {
        "key": "ctrl+alt+[Period]",
        "command": "editor.action.removeCommentLine",
        "when": "editorTextFocus && !editorReadonly"
    },
    {
        "key": "ctrl+k ctrl+u",
        "command": "-editor.action.removeCommentLine",
        "when": "editorTextFocus && !editorReadonly"
    },
    {
        "key": "alt+left",
        "command": "workbench.action.navigateBack"
    },
    {
        "key": "alt+right",
        "command": "workbench.action.navigateForward",
        "when": "canNavigateForward"
    },
    {
        "key": "ctrl+shift+6",
        "command": "-workbench.action.navigateForward",
        "when": "canNavigateForward"
    },
    {
        "key": "ctrl+[Period]",
        "command": "editor.action.commentLine",
        "when": "editorTextFocus && !editorReadonly"
    },
    {
        "key": "ctrl+shift+[Period]",
        "command": "-editor.action.commentLine",
        "when": "editorTextFocus && !editorReadonly"
    },
    {
        "key": "alt+f9",
    {
        "key": "alt+f9",
        "command": "-editor.action.nextCommentThreadAction",
        "when": "editorFocus"
    },
    {
        "key": "ctrl+[Period]",
        "command": "-breadcrumbs.focus",
        "when": "breadcrumbsPossible && breadcrumbsVisible"
    },
    {
        "key": "ctrl+[Period]",
        "command": "workbench.action.terminal.sendSequence",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+[Period]",
        "command": "-workbench.action.terminal.sendSequence",
        "when": "terminalFocus"
    }
]

But no effect after update to latest version
Ubuntu 22.04
VSCode 1.75.0

I have a similar problem with my custom keybind CTRL + # to toggle line comments. I am on linux and use a german layout. My setting before worked fine.
{
    "key": "ctrl+[Backslash]", // <-- I don't know why it's called Backslash, but it got correctly bound to '#'
    "command": "editor.action.commentLine",
    "when": "editorTextFocus && !editorReadonly"
  },

But with the new update it strangely binds to CTRL + Y.

Same issue with the last update

Duplicate of #173325


Improve Platform.sh provider integration with an add-on

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe
Platform.sh integration currently requires a little bit of effort and manual work. see https://ddev.readthedocs.io/en/latest/users/providers/platform/
Describe the solution you'd like
The setup can probably be completely automated and the project_id and environment_name derived from the code, assuming that the PLATFORMSH_CLI_TOKEN is already set and available.

Create a ddev add-on (https://ddev.readthedocs.io/en/latest/users/extend/additional-services/#creating-an-additional-service-for-ddev-get) that

Has a ddev platform custom command
Derives the necessary information and automatically sets up Platform integration

Describe alternatives you've considered
No response
Additional context
No response

Work on this is ongoing on https://github.com/platformsh/ddev-platformsh - happy to have anybody along for the ride there, moving conversation/issues/PRs over there.


Accessiblity: Frontpage fixes

Changes:

Add option to write an alt text for gallery images in keystone.
Add titles to Jumbo logos (SVG).
Gallery slider navigation buttons are now keyboard accessible.
Add section and main tags.
Jumbo teaser text is now the H1. Before there was none on the frontpage.

Screenshot:

Oh, btw, did we look into updating the slick library? If we aren't doing it now, we should add it as a card in Trello (if not already done).

Oh, btw, did we look into updating the slick library? If we aren't doing it now, we should add it as a card in Trello (if not already done).
We're using a version of Slick that does support some accessibility (arrow navigation). I have not looked further into upgrading, but thanks for reminding me :).


hide Node version in prompt when nvm is installed and system node …

hide Node version in prompt when nvm is installed and nvm is returning system alias. There is no need to display system in the prompt.

That makes a lot of sense. 👍


tracking new syntax def features in ST

http://www.sublimetext.com/forum/viewtopic.php?f=2&t=17892

The new syntax definition format used by Sublime Text can fully parse LL(1) grammars. Assuming that PowerShell's syntax isn't LL(1), we should try to figure out which constructs are most useful to parse more thoroughly.
At the very least, the new syntax def should be as comprehensive as the existing one.
I'll create a new branch and start working on the new syntax definition.
However, PowerShell has evolved a lot and I'm not really up-to-date with all the new stuff, so I'll start with the parts I know better and we can expand it from there.

Closing in favor of https://github.com/PowerShell/EditorSyntax


Electricity demand

This PR takes euro-calliopes rules for creating electricity demand and casts them into a module.

@jnnr seems like the current code is incompatible with v0.7 (demand cannot be negative). Would it be possible to alter the code slightly to produce positive outputs as part of this PR?

👍 Done in 1b666ba.


Fixes and upgrades version 2.0.5

changed default directory when opening to ~/work/workspace
fixed voila preview
replaced readme and which is now present inside ~/work/workspace/README.ipynb
updated Makefile with more commands for development
brought back octave kernel
brought back deactivated plugins
upgraded jupuyter-lab to v3.2.9

Small comment from a user point of view: it might be a bit confusing to now land in the "workspace" folder (and not in "work" anymore).
E.g. a user of previous versions might be used to see the "inputs" and "outputs" folders, which are not in the current working directory anymore.

Small comment from a user point of view: it might be a bit confusing to now land in the "workspace" folder (and not in "work" anymore).
E.g. a user of previous versions might be used to see the "inputs" and "outputs" folders, which are not in the current working directory anymore.

Small comment from a user point of view: it might be a bit confusing to now land in the "workspace" folder (and not in "work" anymore).
E.g. a user of previous versions might be used to see the "inputs" and "outputs" folders, which are not in the current working directory anymore.

Due to how the dynamic-sidecar handles the inputs, outputs and the state of the service, inputs and outputs folders can no longer be nested inside work.


New tooltip for binary market chart, with date and time

Always open to suggestions, I'm no designer

I would have liked to have a dot or something on the selected point because it can be kind of confusing which line you're looking at, but nivo doesn't have an option for that. We could switch from the "slice" tooltip to the "mesh" tooltip, but the mesh tooltip is fixed to the selected point and doesn't center itself on the screen like the slice one does and so hangs way over the edge of the chart. Just replace enableSlices="x" with useMesh={true} to compare.

Thanks! Good suggestions.
The cursor getting stuck is something I noticed too. I think the only way to fix that would be to generate fake data points that nivo can jump to. I'll look into how much work that would be.
The other two should be straightforward. I did have the text on one line at first and thought that took up too much horizontal space, I'll send a comparison.

Here's the tooltip on one line.
Thoughts on date formatting for markets less than a week long? Currently for the x axis ticks it displays just the time if the tick is today, otherwise displays the date and time. If you don't want the granularity on the tooltip to change I think we should say Today and Yesterday in place of the date, and I think that's more readable on the x axis ticks as well.

Current tick formatting for reference:

This is beautiful; thank you so much!


Builds broken in 3.3.0 in conf-lib.c

The following compile errors occur because conf-lib.c incorrectly defines _XOPEN_SOURCE_EXTENDED. This define must be set to 1 if specified. Platforms that already specify this #define break and cannot compile.
 #define _XOPEN_SOURCE_EXTENDED   /* To get a definition of strdup() */
          ^
"/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Pipeline/crypto/conf/conf_lib.c", line 10: warning(140):
          macro redefined differently

  #if _XOPEN_SOURCE_EXTENDED == 1
                             ^

This is a critical breakage and stops OpenSSL from compiling.

The code should have an #ifdef/undef guard around it.
This was not present at beta1

@levitte could you look at this please?

Hmm, I think the proper fix would be to move the define to the VMS configuration the same way the NonStop and BASE-unix configs have it.

Hmm, I think the proper fix would be to move the define to the VMS configuration the same way the NonStop and BASE-unix configs have it.

Is there anything I can do for this one? I don't have a VMS system available for testing if I change that config.

This also occurs in crypto/conf/conf_sap.c and apps/ocsp.c,

Yeah, @levitte should fixup his VMS fix.

To avoid such regressions in future it would help if @rsbeckerca you could try to build the git tree from the branch before the release.

Unfortunately it is inevitable that such regressions occasionally happen for platforms that we do not have in CI.

To avoid such regressions in future it would help if @rsbeckerca you could try to build the git tree from the branch before the release.

@t8m I run build/test cycles at least once a week. This one slipped past because I did not get time to test it. Last announce was beta1. I'm happy to keep trying and have a monitor running on this. Not sure why we did not see the failure earlier.

Also, I do build from the git tree. Still not sure why I missed this. We had no failures until 3.3.0 came out.

I wonder if it would be beneficial, when we freeze the tree for a release (alpha/beta/final) that, in addition to emailing the comitters list, we also cc the community platform maintainers, indicating that during these freeze periods that target release branches should undergo additional community ci (daily build/test, etc) to help ensure changes admitted during freeze dont have adverse effects on those community platforms.
@t8m do we maintain a canonical list of community maintainers which we can use for that?

I wonder if it would be beneficial, when we freeze the tree for a release (alpha/beta/final) that, in addition to emailing the comitters list, we also cc the community platform maintainers, indicating that during these freeze periods that target release branches should undergo additional community ci (daily build/test, etc) to help ensure changes admitted during freeze dont have adverse effects on those community platforms.
@t8m do we maintain a canonical list of community maintainers which we can use for that?

I really like this idea. We could turn around test results in a few hours on x86. If something goes sideways on ia64 we would likely just not release on that variant.

@t8m do we maintain a canonical list of community maintainers which we can use for that?

Yes, there is the list at https://www.openssl.org/policies/general-supplemental/platforms.html

Fix in #24083 (made against the openssl-3.3 branch), please try it out

Also, I do build from the git tree. Still not sure why I missed this. We had no failures until 3.3.0 came out.

The offending PR was merged in last thursday.

Fix in #24083 (made against the openssl-3.3 branch), please try it out

I've tried the fix, and it now builds on both systems where I encountered the issues (AIX and Solaris)

I wonder if it would be beneficial, when we freeze the tree for a release (alpha/beta/final) that, in addition to emailing the comitters list, we also cc the community platform maintainers, indicating that during these freeze periods that target release branches should undergo additional community ci (daily build/test, etc) to help ensure changes admitted during freeze dont have adverse effects on those community platforms.
@t8m do we maintain a canonical list of community maintainers which we can use for that?

I really like this idea. We could turn around test results in a few hours on x86. If something goes sideways on ia64 we would likely just not release on that variant.

Just a quick followup. We have a CI monitor job now that will check every merge to 3.3 and run 64-bit and PUT build/test cycles. Hopefully, we will catch issues earlier. Another will be made for master.

There can be a lot of merges from time to time. IMO doing a CI run once or twice day would be sufficient.

There can be a lot of merges from time to time. IMO doing a CI run once or twice day would be sufficient.

@t8m The poll is scheduled between 2am and 3am daily. That should work.


[FEATURE] Support VEX without needing Components

As per this CycloneDX example, it is valid to have a CycloneDX document that includes just VEX data and through use of CycloneDX BomLink link to Components held in a separate CycloneDX document.
This mechanism allows for real-world Use Cases as the composition of a piece of software is fixed at a given point in time, whereas the known Vulnerabilities (or a Supplier's response to known Vulnerabilities) changes over time.
The adage: "Software ages like milk not wine" applies.
At present in cyclonedx-python-lib, the data model is structured such that Vulnerabilities are added to Component instances. The serialisers in this library also assume that Vulnerability data is only present if there are Components too.
This Feature should:

Allow for Vulnerability (VEX) data to be modelled without modelling Components fully
Enable consideration for bom-ref's that utilise CycloneDX BomLink

FYI @jkowalleck

The suggested plan to tackle this is to:

Update cyclonedx.model.bom.Bom to have a SortedSet of Vulnerability
Remove SortedSet of Vulnerability in cyclonedx.model.component.Component, but look to retain the existing method for adding a Vulnerability that relates to a Component to minimise breaking changes

Considerations remaining:

Should BomLinks be enforced / validated against external CycloneDX documents? If so, how? (note: this would probably require resolution/implementation of #185)

Included in 4.0.0 - now released.


[ADAP-1091] [Feature] Include Snowflake session_id in run results response

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt-snowflake functionality, rather than a Big Idea better suited to a discussion

Describe the feature
As a dbt user, I want to be able to quickly look up information about the set of queries associated with a dbt model run rather than just the final create/insert/update statement. While the query_id is powerful, the session_id can provided richer information back to Snowflake users to under the full lifecycle of queries executed.
To implement this feature, we could extend the SnowflakeAdapterResponse to include the session_id.
@dataclass
class SnowflakeAdapterResponse(AdapterResponse):
    query_id: str = ""
    session_id: str = ""

Describe alternatives you've considered
Similar to the alternatives discussed within https://github.com/dbt-labs/dbt-snowflake/issues/7, a post-hook might work, but not give an idea of the full lifecycle in case of failures.
Who will this benefit?
This would help dbt-snowflake users to more effectively debug and understand why their queries succeeded or failed.
Are you interested in contributing this feature?
Yes!
Anything else?
No response

+1, being able to easily see all connected queries in a given model instead of just the final query would be be very helpful in debugging / potential optimization!


gitignore: no exclude linq js files for web distribution

fix issue https://github.com/ENikS/LINQ/issues/88#issue-535736918 for linq.js and linq.min.js

Coverage remained the same at 99.804% when pulling f9374f8257f66b2cb9bfd4d05a43539525a6d131 on clystian:master into db697c1dbbcd2a9d47f7316798c74a344812e600 on ENikS:master.

These files are auto generated and should not be in repository


futures_income_history

I can't seem to get the last 4 days... It returns anything before that time but nothing more recent.
I've tried with and without startTime=, endTime=.
Any ideas?

I can't seem to get the last 4 days... It returns anything before that time but nothing more recent. I've tried with and without startTime=, endTime=.
Any ideas?

Nevermind... It was my mistake using income_history when I wanted trade_history


Serde only deserializes classes implementing an interface, if the interface has an abstract method.

Expected Behavior
Java/Kotlin classes implementing a common interface should be deserializable. Java records should optionally be deserializable.
Actual Behaviour
We noticed some very unexpected behaviour when switching from jackson to serde-jackson, resulting in a runtime exception thrown by the serde object mapper.
We are receiving command objects from RabbitMQ that have a common interface and are discerned by a type parameter. The patterns is:
@Serdeable
@JsonTypeInfo(
    use = JsonTypeInfo.Id.NAME, property = "type"
)
interface Command {
    @JsonTypeName("one")
    class CommandOne implements Command {
    ... more properties here
    }

    @JsonTypeName("one")
    class CommandTwo implements Command {
    ... more properties here
    }
}

@RabbitListener
class CommandListener {
    @Queue("command.queue")
    public void receive(Command command) {
    }
}

to deserialize JSON objects of the form
{

    "type": "one",
    ... more properties here
}

{

    "type": "two",
    ... more properties here
}

We have installed a Serde deser for micronaut.rabbitmq which is working.
Now to the fun part: when the interface has an abstract method that is implemented by the classes, everything works fine. When the interface has a default method that is overriden by the classes, deserialization fails. If the interface has no method at all, deserialization fails. If we use records instead of classes, the deserialization fails.
I have linked a small project with a unit test and without any technology overhead, that demonstrates the problem.
Steps To Reproduce
Please see the code in the linked example project (just a unit test plus variants of interface/class pattern).
Environment Information

Linux (kernel 5)
Micronaut 3.7.3
Serde
Oracle JDK 17

Example Application
https://github.com/scameronde/micronaut-serde-bugreport
Version
3.7.3

Thanks for the great issue report. PR sent.


feat(cd): Use cargo-dist for releasing

cargo-dist supports Homebrew.
Why
For now, if fzf-make is installed via Homebrew, binary is built on user's machine.
If we can distribute binary for enough target, time to install decrease significantly.

duplicate of https://github.com/kyu08/fzf-make/issues/372


Fixed typos in ToSetTest and AdaptedBinaryOperatorTest

Attempt to fix issue #289

 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.

Thanks for the PR! You need to update the copyright headers for the files you have changed, which can be done by running mvn spotless:apply

Codecov Report

Merging #290 (0f426ec) into develop (fc773e8) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop     #290   +/-   ##
==========================================
  Coverage      82.08%   82.08%
  Complexity      1616     1616
==========================================
  Files            194      194
  Lines           4316     4316
  Branches         435      435
==========================================
  Hits            3543     3543
  Misses           592      592
  Partials         181      181

Continue to review full report at Codecov.

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


[MNT] numpy 2 compatibility

numpy 2 has been released. We should test framework and all estimators for compatibility, and bump the version with the next MINOR release.

From https://github.com/sktime/skpro/pull/393, framework is compatible without any issues.

From https://github.com/sktime/skpro/pull/395, everything including all estimators is compatible without any issues. Minor restriction is that, in case of soft dependencies, we know this only for packages that already support numpy 2, but I would not expect any major problems as interface code does not use numpy typically, and if it does, only very superficially.

Meaning, we can bump the numpy bound in 2.4.0.


Remove trailing dot from hostnames

Fixes #922
Note that various smoke-tests (240, 630) which ought to be relevant are failing for unrelated reasons; perhaps better to hold up merging this until those are also fixed.

LGTM

LGTM


Could not find source label errors

This code compiles successfully:
def db as base;
def d0 as GasSensor;
def d1 as WallCooler;
def d2 as WallHeater;
def $midTemp as 23;
def $lowTemp as 20;
def $highTemp as 26;
fn main (){
var getTemp;
var cooling;
var heating;
loop {
read GasSensor.Temperature into getTemp;
read WallCooler.On into cooling;
read WallHeater.On into heating;
}
}
If I add one more line, to simply, say, round the getTemp variable (or do anything else, like an if statement)
getTemp = round(getTemp);
Then I get the following error:
Exception in thread "main" com.github.The127.MScript.MScriptCompilationException: Could not find source label: {source::goto::__round}pop r4
at com.github.The127.MScript.LabelResolver.lambda$resolveLabels$0(LabelResolver.java:34)
at java.base/java.lang.Iterable.forEach(Iterable.java:75)
at com.github.The127.MScript.LabelResolver.resolveLabels(LabelResolver.java:28)
at com.github.The127.MScript.MScriptCompiler.main(MScriptCompiler.java:37)
I have tried renaming the variable, moving the round into a function and returning the result as in the 1 sample program provided, but always get this error.  I don't understand what Could not find source label means.
Help is appreciated... I really like this concept a lot!
Thanks!

Ok, I can do this just fine.
getTemp = 0;
getTemp = getTemp + 1;
My best guess is GasSensor.Temperature isn't valid (although it doesn't complain on that read).  It is not clear how to enumerate what the valid list of things is.

Hi, thanks for opening an issue and using this little project.
I could reproduce and fix the "Could not find source label: {source::goto::__round}pop r4" bug.
My latest commit should have fixed this one.

Thanks, I will give it a try and report back.  Cheers!
On Mon, Jan 15, 2024, 3:23 PM Darkarotte @.***> wrote:

Hi, thanks for opening an issue and using this little project.
I could reproduce and fix the "Could not find source label:
{source::goto::__round}pop r4" bug.
My latest commit should have fixed this one.
—
Reply to this email directly, view it on GitHub
https://github.com/The127/MScript/issues/23#issuecomment-1892778179, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACLIOPO5KNCI3QGCS3NCYDTYOWM4NAVCNFSM6AAAAABBZ57PD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJSG43TQMJXHE
.
You are receiving this because you authored the thread.Message ID:
@.***>

This worked, thank you!
I haven't done Assembly with any regularity in 20 years.  This was much nicer!


PowerShell "nvm" is not

I downloaded nvm but when I type nvm ls it gives this error. I downloaded it properly.
https://i.imgur.com/VItVRuC.png

The latest released version of nvm only supports Windows via WSL2. The next version may support other Windows mechanisms.
The readme for the latest version is https://github.com/nvm-sh/nvm/tree/v0.38.0#readme.


Don't black bar for 'EOF from server' error

r? @keybase/react-hackers

Does this EOF error resolve itself after a while?

@songgao yeah, they happen when the service restarts, and are usually transient. Before this you'd see the reachability screen and then a black bar on reconnecting. This removes the black bar.

Cool; thanks. I'll be able close some KBFS ticket too then!

@chrisnojima I moved the check to a new function isErrorTransient, PTAL


add missing nc files (fixes #27)

Add the 2 missing netcdf files for Kaikoura (fixes #27).
In the initial setup (the one used in the paper), my velocity model was wrong.
In fact, I did not realize that the New Zealand velocity model is given in a rotated coordinate system.
Since #26, I have fixed this problem. There are 2 netcdf files, one of finer resolution used near the faults and a coarser one further away from the fault system.

CI fails, but not caused by this. We'll fix this soon, after this we can merge.

CI should be fixed now (fingers crossed :D)


feat: Add Returning ID after Insert

Add Returning ID after insert in SQLite

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@13f91d3). Click here to learn what that means.
The diff coverage is 45.45%.

@@            Coverage Diff            @@
##             master      #15   +/-   ##
=========================================
  Coverage          ?   68.15%
=========================================
  Files             ?        4
  Lines             ?      292
  Branches          ?        0
=========================================
  Hits              ?      199
  Misses            ?       93
  Partials          ?        0

Flag
Coverage Δ

#SwiftKuerySQLite
68.15% <45.45%> (?)

Impacted Files
Coverage Δ

Sources/SwiftKuerySQLite/SQLiteConnection.swift
68.18% <45.45%> (ø)

Continue to review full report at Codecov.

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

We should probably address this first:  https://github.com/IBM-Swift/Swift-Kuery-SQLite/issues/18

My approach in #19, while awaiting an upstream PR merge, ensures that auto-increment columns can be created in the first place.


Support generation of docs for a command subtree

Invokers should be able to genreate docs for the riff init [invoker]
and riff create [invoker] commands without generating docs for all
riff commands.
# generate docs for `riff init command` and `riff create command`
$ RIFF_INVOKER_PATHS="command-invoker.yaml" riff docs -d docs --command "init command"
$ RIFF_INVOKER_PATHS="command-invoker.yaml" riff docs -d docs --command "create command"

Refs #454

Merged as ca1bb9e2, which includes polish found in https://github.com/ericbottard/riff/commit/ad8b955d736d8bc01e47949b6f00b7bdc56361d2
I'm not sure I understand the test addition though? Where is this actually used? Is this gonna be used in invoker projects (and the test is just that: a test?)

@ericbottard the intent is for invokers to create docs in their repo for the init and create commands using the local *-invoker.yaml file. The test in the Makefile felt more natural than using a go test since that's how the command is expected to be used.

OK, that's what I understood then. Carry on :) 👍


fix: add build admin

Jira Ticket ID:

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix (non-breaking change which fixes an issue)
[x] Feature (non-breaking change which adds functionality)
[ ] Code style update
[ ] Refactor (refactoring or adding test which isn't a fix or add a feature)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

Did you test your solution?

[x] I lightly tested it in one browser
[ ] I deeply tested it in several browsers
[ ] I wrote tests around it (unit tests, integration tests, E2E tests)

Problem Description
Developers often recieve false alarms from both internal and external project members. It has been a lack of visibility of what version of the application they are looking at. In addition to that, Developers get bug reports with minimal information; not knowing their device type, OS, browser, browser version, and viewport sizes.
Solution Description
Introducing Admin panel that conveys all important information that helps Developers to understand.

Side Effects, Risks, Impact

[x] N/A

Aditional comments:

add build link

Awesome ok thank you, @Donghyuk


large files are corrupted when served through elm-reactor

This is a SSCCE for #213
With Elm 0.18.0, Mac OS X 10.11.6
Files larger than ~900kb are corrupted by elm-reactor when they are served.

Create a file larger than 1MB (you can get a good one with curl -O http://norvig.com/big.txt)
start elm-reactor from the folder with the large file
download the file through elm-reactor (curl http://localhost:8000/big.txt > downloaded.txt)

If you now compare the downloaded file to the original, (diff -u <(xxd big.txt) <(xxd downloaded.txt)), you will see that around 900,000 characters in, the beginning of the file is repeated.
Additional info:

The downloaded file has the same size as the original, but the content differs
The file gets corrupted at different locations each time it is downloaded
The beginning of the file is actually repeated several times:$ grep -n "The Project Gutenberg EBook of The Adventures of Sherlock Holmes" big.txt
1:The Project Gutenberg EBook of The Adventures of Sherlock Holmes

$ grep -n "The Project Gutenberg EBook of The Adventures of Sherlock Holmes" downloaded.txt
1:The Project Gutenberg EBook of The Adventures of Sherlock Holmes
11607:theThe Project Gutenberg EBook of The Adventures of Sherlock Holmes
17740:Articles"The Project Gutenberg EBook of The Adventures of Sherlock Holmes
18729:What a time it seemed! From comparing notes afterwards it was but an hour and a quarter, yet it appeared to me that the night must have almost gone, and the dawn be breaking above us. My limbs were weary and stiff, for I feared to change my position; yet my The Project Gutenberg EBook of The Adventures of Sherlock Holmes

I wonder if this is due to using a newer version of the snap-core Haskell package. I wonder if they have any issues open along these lines, because I basically did not touch the elm-reactor code at all for this release.

I took a quick look and didn't see an obviously matching issues on snap-core.  If I get a chance, I'll try making a bare-bones project using snap-core and see if it has the same issue so we can report it there.


Without map information, can magicdrive be trained?

If my dataset doesn't include map, can magicdrive work well during training and infrnece?

We did not try to train without maps. For inference, see #19 and #9.


Mapping of metadataStandardName

The metadata standard as defined in ISO 19115 XPath:
gmd:MD_Metadata/gmd:metadataStandardName/gco:CharacterString
gmd:MD_Metadata/gmd:metadataStandardVersion/gco:CharacterString
has to be mapped to GeoDCAT-AP, e.g. in a dct:confomsTo
A vocabulary is needed to which metadata standard of metadata can be conform to…
Currently mapped to something like:
foaf:isPrimaryTopicOf/rdf:Description/dct:source/dct:conformsTo	Metadata Standard
<dct:source rdf:parseType="Resource">
    <cnt:characterEncoding rdf:datatype="http://www.w3.org/2001/XMLSchema#string">UTF-8</cnt:characterEncoding>
    <dct:conformsTo rdf:parseType="Resource">
        <dct:title xml:lang="de">INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119</dct:title>
        <owl:versionInfo xml:lang="de">V. 1.2</owl:versionInfo>
    </dct:conformsTo>

@uvoges since this is mapped in dct:conformsTo already, do you suggest to create a new controlled vocabulary for the various standards used in INSPIRE?
As far as I understand, any standard can be currently named like this in the INSPIRE metadata and there is no such controlled vocabulary / list of usable standards.


error 25299 when trying to store values with access mode kSecAttrAccessibleAlways

the library https://github.com/p2/OAuth2 uses SwiftKeychain to store Oauth2 tokens in the keychain, it does this with the default setting kSecAttrAccessibleWhenUnlocked
As soon as I try to use kSecAttrAccessibleAlways I get the error
Failed to store to keychain: The process could not be completed. (swift.keychain.error.domain-Fehler -25299.)

found out the reason for this: when you try to add an entry with a different access mode it can not be stored because it is not unique
the problem is that access mode is not considered for uniqueness but considered for query, so the remove request did not remove the entry

+1

I ran into this problem too, except with the the scenario of using "onFirstUnlock", which by the way if you are storing login credentials is the safest and most secure. If you store as "always", it is stores unencrypted in the keychain, with the first unlock, it is accessible by the time you application opens after its been unlocked by the user, and is encrypted with the built in hardware encryption key. Since we need to use the access token while the application is in the background, you must use "Always" or "On first Unlock". I'd strongly recommend to the project admins to move the default to be "OnFirstUnlock" from "Unlock" since unlock is only available while the application is in the foreground, so if you application makes use of ANY extensions, or runs in the background for any amount of time, that token is not available, since it is in the background.
If you have a previously stored key, that key has the access control defined as "OnUnlock", so it is not found in the query, so you get a -25300, on the OSStatus response. Then when you go to insert it with the new value, there is an error on the insert getting the -25299, duplicate found, since there is in fact a keychain item there. When you respond on the errSecDuplicateItem (-25299), the delete fails with a -25300 since it can not find that item to delete. Then it gets re added, and fails for the same reason the initial failure occurred:
The solution i found was to change:
public func insertItemWithAttributes(attributes: [String: AnyObject]) throws {

        var statusCode = SecItemAdd(attributes, nil)
        if statusCode == errSecDuplicateItem {
            SecItemDelete(attributes)
            statusCode = SecItemAdd(attributes, nil)
        }

        if statusCode != errSecSuccess {

            throw errorForStatusCode(statusCode)
        }
    }

to
public func insertItemWithAttributes(attributes: [String: AnyObject]) throws {

        var statusCode = SecItemAdd(attributes, nil)
        if statusCode == errSecDuplicateItem {
            var removeAttributes = attributes
            removeAttributes.removeValueForKey(String(kSecAttrAccessible))
            SecItemDelete(removeAttributes)
            statusCode = SecItemAdd(attributes, nil)
        }

        if statusCode != errSecSuccess {

            throw errorForStatusCode(statusCode)
        }
    }

and to also change the removeItem in a similar way to ensure it is removed, on say logout:
public func removeItemWithAttributes(attributes: [String: AnyObject]) throws {
var removeAttributes = attributes
removeAttributes.removeValueForKey(String(kSecAttrAccessible))
let statusCode = SecItemDelete(removeAttributes)
    if statusCode != errSecSuccess {

        throw errorForStatusCode(statusCode)
    }
}

I've tested this in local code, but have not yet forked, and done a PR for it, but it appears to solve the issue.


Fix date serialization

The date is currently being automatically serialized due to the jsonify() function from Flask. Try to find a solution so @jkiddo can use it.

@jkiddo try now!

Date has this format

this seems wrong:
"div": "\u003cdiv xmlns\u003d\"http://www.w3.org/1999/xhtml\"\u003e\u003cp\u003eEl medicamento Dovato 50

that part might be okay ... but I now see this:
ca.uhn.fhir.parser.DataFormatException: HAPI-1821: [element="date"] Invalid attribute value "2024-06-03 15:36:10.374713": Invalid date/time format: "2024-06-03 15:36:10.374713": Expected character 'T' at index 10 but found

this seems wrong: "div": "\u003cdiv xmlns\u003d\"http://www.w3.org/1999/xhtml\"\u003e\u003cp\u003eEl medicamento Dovato 50

regarding this, i will check. maybe due to ISO format

Try now! dateformat should be working
"date": "2024-06-03T15:59:33.284375",
the div issue is curious because for me, it is working well

if date still not working, i have another bullet on the chamber ready 😃

works

👏🏻

now what is left is to get the fix from @joofio on the conditions part


⚠ Bofrost.be has degraded performance

In 8b2524e, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1146 ms

Resolved: Bofrost.be performance has improved in e8694e7.


Update library make app crash

I want to update library from 1.8.4 to 1.9.3 and all app is crash.
Seems like appcompat-v7:23.4.0 is not compatible with this version.
java.lang.RuntimeException: Unable to start activity ComponentInfo{package.name/package.name.activity.MainActivity}: android.view.InflateException: Binary XML file line #11: Binary XML file line #97: Error inflating class android.support.design.widget.FloatingActionButton

The support version was bumped to compile 'com.android.support:appcompat-v7:24.2.1' in the library. Perhaps it's best to use the lowest version possible to ensure compatability? I'll have to play around with this one.
You can eiher update the version in your app or download the code locally and change the version and add as a library project until this is investigated further.


Create Base Components for Implementation of simple-cqrs

Commands are the objects that will be passed to a Command Handler for processing. For simplicity a one to one relationship should be maintained, at least for this phase of work. The following should be achieved with this component.
The general work with this is to create an interface, that will allow determination of what handler should handle without the need for specifically calling out the handler, the response to the command must also be inferred so the "caller" will know what is being returned.

Refactored to include all components necessary.


Set azure user agent env for azure provider

This PR sets Azure User Agent environment variable so that the azure terraform provider will be able to pick it up.
Users have options to opt out of it by setting the corresponding config.
related issue: #103

Oops I spoke too soon, the test is failing. 😊

Oops I spoke too soon, the test is failing. blush

It's still the test data. It should be good now


Remove panics via expect

My application kept crashing due to panics when the broadlink device was temporary unavailable. I refactored all .expect calls to .map_err to return string errors for all errors. The original error is appended to still be able to determine the root cause.
Would probably be better to use an Error type instead to be able to reason about the origin of the error programmatically and prevent allocation of strings when the error is not displayed.
Don't really have a use-case for that now though, so strings are fine.

Sorry for the super long delay; I'll look at this soon!

This looks great! I'll probably go through and add real error types later, but thanks for your PR!


build: add release script

This pull request adds a ./bin/release script that interactively creates a tag and pushes it to Git.
Flow
The script:

Checks if the repository is in a clean state
Check if the current origin and branch is origin/main (this could be changed or made dynamic)
Checks if the user has write access by calling git push
Suggests new versions based on the current version
Creates and pushes the tag for the chosen version

This will trigger the "Changelog and release" action which will write to CHANGELOG.md and create a GitHub release.

[!WARNING]
The current version scheme, 1.0-alpha2, is not semver-compliant. The pre-release identifiers should be separated by dots, and the patch version should be included. It should be 1.0.0-alpha.2.
However, consistency is better, so I suggest keeping the current scheme until we reach 1.0.0. After that, we can start using this script, which will use semver-compliant version numbers (eg. 1.0.0, 1.0.1, 1.1.0, 2.0.0-alpha.1, etc)

Examples
With the current version (1.0-alpha2)
https://github.com/user-attachments/assets/b7ebc0c3-fb3c-46a8-826a-3a4692e58797
With a beta version (1.0.0-beta.3)
https://github.com/user-attachments/assets/54549765-ece0-40c5-a964-1c9ae2784209
With a non-prerelease version (1.1.0)
https://github.com/user-attachments/assets/8375475f-410c-4747-be91-c19355766d8b

Niiiiiiiice. 😍
A couple thoughts:
First, can you add some support for the items that monorepo-builder checks by way of interdependencies, etc.? I'm not saying we should use their script directly, I like this flow better, but it'd be worth incorporating.
Second, I'm going to disagree with your proposal about consistency. This is alpha, we can break what we want (jk, kinda). 🙃
I think the right approach is to correct the tagging going forward and add a corrected tag in retrospect for the previous releases. We can maintain the existing (incorrect) tags along side the corrected ones.

Side note: I really love this. Well done.

@aidan-casey
First, can you add some support for the items that monorepo-builder checks by way of interdependencies, etc.? I'm not saying we should use their script directly, I like this flow better, but it'd be worth incorporating.

Right now, none of these are used, right? Do you think calling the qa script from composer would be enough?

@aidan-casey
I think the right approach is to correct the tagging going forward and add a corrected tag in retrospect for the previous releases. We can maintain the existing (incorrect) tags along side the corrected ones.

That seems great to me as well!

Right now, none of these are used, right?

Right now bumping the inter-dependencies is done manually before release.

I think the right approach is to correct the tagging going forward and add a corrected tag in retrospect for the previous releases. We can maintain the existing (incorrect) tags along side the corrected ones.

@innocenzi this has been done. I've utilized the semantic versioning scheme and prefixed with v. If we can sort out the comments above, we can flesh out the other release steps after merging.
CC: @brendt for visibility.

@brendt yes. There is a PR in docs let me know if there was something else you wanted updated.
I'll have the rest of the tags cleaned up today. With the revisions requested, I'll get this merged.
@innocenzi can you add a little comment at the end of the contributing file about how releases are handled?

@brendt yes. There is a PR in docs let me know if there was something else you wanted updated.

Go ahead and merge it :) You can deploy by triggering the deploy action: https://github.com/tempestphp/tempest-docs/actions/workflows/deploy.yml

Go ahead and merge it

I'll go ahead and do that. Just didn't want to deploy and break the site on your weekend away. 🙃

can you add a little comment at the end of the contributing file about how releases are handled?

I'll create another PR for the bumping of inter-dependencies and that 👍


⚠ Samsung has degraded performance

In 7857a12, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2908 ms

Resolved: Samsung performance has improved in cec648a.


fix: move dummy_label_attr to a separate file

This setup was AFAIK never designed to work, and only worked by luck in this case. It is nondeterministic whether dummy_label_attr is evaluated before or after labelExtensionMapRef, depending on the iteration order over the constants in the file. See https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/initialization.20order.20fiasco/near/363247722

bors merge


Release Google.Cloud.AssuredWorkloads.V1 version 2.4.0

Changes in this release:
No API surface changes; just dependency updates.

Created release for Google.Cloud.AssuredWorkloads.V1-2.4.0