docs: a stub for client libraries section

Also includes initial description for the rounding during encoding/decoding datetimes

Would it make sense to add a note on why we chose round to even or a link to something that explains the advantages? This sounds very bizarre if you have never seen it before.

Would it make sense to add a note on why we chose round to even or a link to something that explains the advantages? This sounds very bizarre if you have never seen it before.

Well, yes it sounds bizarre first time. But it makes sense in statistics. Also Postgres does that. Here are few links by quick googling:

https://stackoverflow.com/questions/45223778/is-bankers-rounding-really-more-numerically-stable
https://softwareengineering.stackexchange.com/questions/256265/why-do-some-languages-round-to-the-nearest-even-integer

I'm not sure these are good to put into the docs. Maybe someone knows the "canonical" link for that.

I went back and forth between thinking this might be out of the documentation scope and liking it as a note, so the user can see it's an aside but we give context inline rather than forcing the user to seek it outside our docs. I think I'm leaning slightly toward the latter, I think.
What would you think about something like this as a .. note::? (Also, have I accurately reflected our reasoning for doing this? This was my assumption when I noticed it.)

You may not be familiar with rounding to even. Most rounding goes in the same direction every time: either up from the midpoint or down. This can be a problem because it means you are rounding more often in the direction you choose. Ideally, for rounded numbers to, in aggregate, be more representative of the values they were rounded from, you would want to round up half the time and down the other half.
By rounding to the nearest even number, you are no longer always rounding in a single direction. If the even is down, you round down. If the even is up, you round up. Rounding to even allows you to balance out your rounding by considering a second factor in determining which direction you will round.

I personally would prefer a link to something external. It seems like that would give a more thorough explanation and example algorithm. It is also less text in our docs. The problem is, as @tailhook pointed out, that there is not a great canonical link to point to. I found this one clear and to the point, but who knows how long it will be there.

Also, for round-to-even negative numbers are treated differently than positive numbers, but we don't explicitly mention what dates if any we consider negative. It seems we treat all dates as positive numbers. This information is given implicitly with the examples but it might be nice if this was explicitly called out. There are lots of dates that could be considered the threshold between positive and negative. All of them except maybe the big bang are rather arbitrary so it is hard to guess.

@fmoor

Also, for round-to-even negative numbers are treated differently than positive numbers,

I think they also round to nearest even. And evens are the same. What is the difference?

but we don't explicitly mention what dates if any we consider negative.

Well, intuitively dates are all positive. At least starting from year 1 which we support. (Unix) epoch timestamps can be negative, but this is not how we think of dates even if they are implemented like that.
But even with negative timestamps around any given epoch, rounding doesn't happen to be any different on whether it's positive or negative. Maybe some specific calculation doesn't work for negative numbers, but it doesn't change the docs unless we provide some example formulas.
@raddevon
I would like to include good summary in the note, but I don't think what you propose summarizes it well. And I fail to come up with a good summary myself.

I think they also round to nearest even. And evens are the same. What is the difference?
evens round towards zero and odds away from zero

Well, intuitively dates are all positive.
This is subjective. Others may not have the same intuition. I was thinking of dates as a unix epoch and initially took the sign into account. This seems like an easy detail to include.

@tailhook I'm happy to rework my summary given some direction. This is how I understand it, but maybe the problem is that I don't understand it, or at least not well enough. 😅

@tailhook I'm happy to rework my summary given some direction. This is how I understand it, but maybe the problem is that I don't understand it, or at least not well enough. sweat_smile

Well, I don't know. What you have written is intuitively kinda right. But is scientifically wrong :) Which is probably okay to some degree.
Thinking more about it would provide just some direction of the research rather than explaining. Like this:

When you perform multiple operations of summing up and rounding values, the the error margin of the resulting value tends to increase. When using rounding half-to-even the expected value of such calculation should be the most accurate (while in the "half-up" method, for example, expected value tends to become bigger the more calculations are done)

That sounds good, @tailhook. I think that's what I meant, but I didn't do the best job getting it across. I'll rework my explanation around your suggestion. Thank you!

If we perform multiple operations of summing while rounding half-up or rounding half-down, the error margin of the resulting value tends to increase. If we round half-to-even instead, the expected value of summing tends to be more accurate.

See if this seems accurate and still captures everything we want to capture, @tailhook. I tried to reframe it a bit more as an explanation in hopes of anchoring it more within the context, while hopefully retaining accuracy.

Oops, sorry. It looks like I've somehow pushed "merge" button by a mistake :( Feel free to make a PR with your suggestion.

It's my fault. I should have used "request changes" instead of "approve." 😅  I'll put in a PR. Thanks, @tailhook!


[rsocket] Add new port

Describe the pull request
C++ implementation of RSocket http://rsocket.io
https://github.com/rsocket/rsocket-cpp
What does your PR fix? Fixes issue #
N/A
Which triplets are supported/not supported? Have you updated the CI baseline?
Not support x64-windows x64-windows-static
Does your PR follow the maintainer guide?
Yes

Maybe I shouldn't add vcpkg_fail_port_install(ON_ARCH "x64"), it seems that x64 contains linux environment.
I just want skip windows environment.

Thanks for your suggestions @malirod .
The main reason why I compiled this package is that fbthrift depends on this, so all changes are for compiling fbthrift.
I will try my best to solve the above problem. However, I cannot guarantee that the windows can be used since there is no windows environment.

@curoky ,
seems folly built fine on linux. there is something wrong with rsocket itself
https://dev.azure.com/vcpkg/c1ee48cb-0df2-4ab3-8384-b1df5a79fe53/_apis/build/builds/35961/logs/58

2020-05-02T10:07:45.2960882Z Installing package folly[core,zlib]:x64-windows...
2020-05-02T10:07:45.2961217Z Installing package folly[core,zlib]:x64-windows... done
2020-05-02T10:07:45.2961481Z Elapsed time for package folly:x64-windows: 10.21 s
2020-05-02T10:07:45.2962094Z Starting package 84/84: rsocket:x64-windows
2020-05-02T10:07:45.2962603Z Building package rsocket[core]:x64-windows...
2020-05-02T10:07:45.2963220Z Could not locate cached archive: C:\agent_work\1\s\archives\77\779727562299ee2c6b7f57c07b2704e69734c3d8.zip
2020-05-02T10:08:07.7616776Z -- Downloading https://github.com/rsocket/rsocket-cpp/archive/b237f5dba44bd360ee8c24fb998af83606355116.tar.gz...
2020-05-02T10:08:07.7617845Z -- Extracting source C:/agent/_work/1/s/downloads/rsocket-rsocket-cpp-b237f5dba44bd360ee8c24fb998af83606355116.tar.gz
2020-05-02T10:08:07.7618398Z -- Applying patch fix-cmake-config.patch
2020-05-02T10:08:07.7618746Z -- Using source at C:/agent/_work/1/s/buildtrees/rsocket/src/3606355116-b3d329c9e2
2020-05-02T10:08:07.7619220Z -- Downloading https://github.com/ninja-build/ninja/releases/download/v1.10.0/ninja-win.zip...
2020-05-02T10:08:07.7620321Z -- Configuring x64-windows
2020-05-02T10:08:07.7620826Z CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
2020-05-02T10:08:07.7621571Z     Command failed: ninja -v
2020-05-02T10:08:07.7622458Z     Working Directory: C:/agent/_work/1/s/buildtrees/rsocket/x64-windows-rel/vcpkg-parallel-configure
2020-05-02T10:08:07.7622859Z     Error code: 1
2020-05-02T10:08:07.7623647Z     See logs for more information:
2020-05-02T10:08:07.7624559Z       C:\agent_work\1\s\buildtrees\rsocket\config-x64-windows-out.log
2020-05-02T10:08:07.7624845Z
2020-05-02T10:08:07.7625765Z Call Stack (most recent call first):
2020-05-02T10:08:07.7626407Z   scripts/cmake/vcpkg_configure_cmake.cmake:297 (vcpkg_execute_required_process)
2020-05-02T10:08:07.7627151Z   ports/rsocket/portfile.cmake:16 (vcpkg_configure_cmake)
2020-05-02T10:08:07.7627972Z   scripts/ports.cmake:90 (include)
2020-05-02T10:08:07.7628604Z
2020-05-02T10:08:07.7629298Z
2020-05-02T10:08:07.8966038Z Error: Building package rsocket:x64-windows failed with: BUILD_FAILED
2020-05-02T10:08:07.8966823Z Elapsed time for package rsocket:x64-windows: 22.6 s

@malirod may need to add the following lines

find_package(ZLIB MODULE REQUIRED)
target_link_libraries(ReactiveSocket ... ZLIB::ZLIB)
target_link_libraries(yarpl ... ZLIB::ZLIB)

Do you have a windows environment? Try it?
-- Found folly: C:/agent/_work/1/s/installed/x64-windows-static
yarpl source dir: C:/agent/_work/1/s/buildtrees/rsocket/src/3606355116-b3d329c9e2/yarpl
-- Configuring done

CMake Error at C:/agent/_work/1/s/scripts/buildsystems/vcpkg.cmake:250 (_add_library):
  Target "ReactiveSocket" links to target "ZLIB::ZLIB" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?
Call Stack (most recent call first):
  CMakeLists.txt:205 (add_library)

CMake Error at C:/agent/_work/1/s/scripts/buildsystems/vcpkg.cmake:250 (_add_library):
  Target "yarpl" links to target "ZLIB::ZLIB" but the target was not found.
  Perhaps a find_package() call is missing for an IMPORTED target, or an
  ALIAS target is missing?
Call Stack (most recent call first):
  yarpl/CMakeLists.txt:67 (add_library)

@curoky ,
I have win env and I was able to reproduce build issue you've posted. I've added lines you've suggested and managed to pass configuration step. Then there were build issues (see below).
I've playing with the following branch ( https://github.com/malirod/vcpkg/tree/add-port-rsocket-cpp )
Win x63 build issues

Command line warning D9025 : overriding '/std:c++latest' with '/std:c++14'
vcpkg\installed\x64-windows\include\folly/container/detail/F14Mask.h(41): error C3861: '__builtin_ctzll': identifier not found
vcpkg\installed\x64-windows\include\folly/lang/Bits.h(147): error C3861: '__builtin_clzl': identifier not found

Additionally I found following things and propose to add them to this PR

There are recent commits in the rsocket-cpp repo and I see tags so it's possible to set proper version of the port

Version: v2<IP_ADDRESS>

Fmt is not mentioned in readme file but it's required in rsocket and yarpl cmake file. So It's required to mention this in CONTROL file.
Build-Depends: folly, fmt, zlib

3.Latest commit and sha
REF 8038d05e741c3d3ecd6adb069b4a1b3daa230e14
    SHA512 d7bc93af7b6130d73fa0823f534ad57a531dfa7d7aa990a2a1a1b72b6761db7eeb60573d0d38f55daa991554e3ab4ac507047f8051a4390b3343cd708a48efbb

Would be great to get feedback about these items.
I'll continue to try to make win build for a while. If you have any ideas how to fix issues please suggest.

/azp run

/azp run

When used with Visual Studio 2019, folly seems to have a bug.

Waiting for #11370 merge and rerun pipeline test.

/azp run

When builiding rsocket with x64-windows:
E:\install\x64-windows\include\folly/container/detail/F14Mask.h(39): error C3861: '__builtin_ctz': identifier not found

/azp run


Quickstart

This is a bash script that operates with the features outlined in #22.

Known issue: Git commit step fails if gitconfig is dotbotted, because the links are not yet made.

Nice!! I've wanted to have a feature like this for a while now.
I haven't had a chance to try running the code yet, but I browsed through it, and it looks pretty good to me. I might have time to play around with running the script later this week.
I'm not sure if I have time to maintain this right now. Perhaps it's best if it's kept in a separate repository? What do you think?

Once the tool is well-tested and everything, it could be cool to have a blog post or something showing off the script.

I'd be happy to maintain the repository in my own git account. I already wrote another version with some cool features, such as command line arguments to test the script and customize the output, including lower the verbosity of the configuration file.
I'll push it into a repo later today.

Do you care if I name it something like dotbot-easy or easy-dotfiles?
I assume we'd sub-repo it later?

Okay, sounds good to me. And name it whatever you like, it's your project :)
I don't think it should be a subrepo of Dotbot -- it's going to be used for initialization, it's not really a runtime dependency of Dotbot. At some point, it could be good to add a section to the readme linking to your tool.
As bad as the curl | sh pattern can be, some people might find it super convenient to do something like curl -fsSL https://raw.githubusercontent.com/Aviator45003/easy-dotfiles/master/easy-dotfiles | bash and just have everything magically set up.

I'm going to close this pull request, let's keep future discussion on this topic in #22.


Can't Resolve '.contentlayer/data'

Description
I am looking to contribute to the Chakra Documentation, though I am running into the following error when spinning up the local server and attempt to navigate to any documentation page (Or selecting "Get Started" link on the landing page):
wait  - compiling /_error (client and server)...
error - ./pages/docs/[[...slug]].tsx:1:0
Module not found: Can't resolve '.contentlayer/data'
> 1 | import { allDocs } from '.contentlayer/data'
  2 | import type { Doc } from '.contentlayer/types'
  3 | import { MDXComponents } from 'components/mdx-components'
  4 | import { GetStaticPaths, GetStaticProps } from 'next'

The following steps to reach to this error:

Fork chakra-ui/chakra-ui-docs
Clone the fork to local
Run yarn to install dependecies
Run yarn dev to run local server
Select the "Get Started " link on the landing page or query to a doc page in the address bar (i.e. http://localhost:3000/docs/disclosure/accordion)

I am noticing that both .contentlayer/data and .contentlayer/types show empty exports.
Also, the CONTRIBUTION files at the root and in the docs folder do not appear to be consistent in how to set up the local space for a PR.

Hello @TylerAPfledderer! I can't seem to reproduce this issue. Did you try removing the node_modules and .contentlayer folders and running the yarn command again? Also, what version of node are you using?

Hello, @nikolovlazar !
Node v17.4.0
If there was a .contentlayer folder that was supposed to appear on install that is not the one in node_modules then it never appeared.
I removed node_modules and ran yarn again. No change.

I tried updating to Node 17 (17.5.0 to be precise), removed .contentlayer and node_modules, ran yarn and then yarn dev and everything seems to work fine. You should see something like this in the logs:
info  - Disabled SWC as replacement for Babel because of custom Babel configuration ".babelrc" https://nextjs.org/docs/messages/swc-disabled
event - compiled client and server successfully in 2.3s (641 modules)
Generated 113 documents in node_modules/.contentlayer

Contentlayer creates its folder when you do yarn, but kicks in when you do yarn dev.
Can you provide more details regarding your dev environment? (os, yarn version, etc...)

Ok!
So with the dev environment, aside from Node:

Windows 10 v.10.0.19043.1526
yarn v1.22.5

Yea, the two files generated in node_modules/.contentlayer which are data and types show empty export objects.
I can certainly update Node to 17.5.0 and try again!

Updated Node to v17.5.0, removed node_modules and ran yarn again.
Here is the complete log in the command line when I run yarn dev and then attempt to navigate to the docs via the "Get Started" button link:
$ yarn dev
yarn run v1.22.5
$ next
ready - started server on <IP_ADDRESS>:3000, url: http://localhost:3000
warn  - The `target` config is deprecated and will be removed in a future version.
See more info here https://nextjs.org/docs/messages/deprecated-target-config
warn  - You have enabled experimental feature(s).
warn  - Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use them at your own risk.

info  - Disabled SWC as replacement for Babel because of custom Babel configuration ".babelrc" https://nextjs.org/docs/messages/swc-disabled
info  - Using external babel configuration from C:\Users\tyler\Documents\Sites\chakra-ui-docs\.babelrc
event - compiled client and server successfully in 8s (641 modules)
wait  - compiling / (client and server)...
event - compiled client and server successfully in 12.9s (2259 modules)
error - uncaughtException: Error: ENOENT: no such file or directory, open 'C:\Users\tyler\Documents\Sites\chakra-ui-docs\.next\cache\images\Nvj0gu9d6bT8htUZSP+ZZiQbkmtvJtDpFGwgLVWqrvg=\0.1644779504286.sqS9-nUkdI76ftelOb9qRmP8qbuTK8pHfEFYSptZQg4=.webp'
wait  - compiling /docs/[[...slug]]...
event - compiled client and server successfully in 667 ms (2115 modules)
wait  - compiling /docs/[[...slug]] (client and server)...
error - ./pages/docs/[[...slug]].tsx:1:0
Module not found: Can't resolve '.contentlayer/data'
> 1 | import { allDocs } from '.contentlayer/data'
  2 | import type { Doc } from '.contentlayer/types'
  3 | import { MDXComponents } from 'components/mdx-components'
  4 | import { GetStaticPaths, GetStaticProps } from 'next'

https://nextjs.org/docs/messages/module-not-found
wait  - compiling /_error (client and server)...
error - ./pages/docs/[[...slug]].tsx:1:0
Module not found: Can't resolve '.contentlayer/data'
> 1 | import { allDocs } from '.contentlayer/data'
  2 | import type { Doc } from '.contentlayer/types'
  3 | import { MDXComponents } from 'components/mdx-components'
  4 | import { GetStaticPaths, GetStaticProps } from 'next'

https://nextjs.org/docs/messages/module-not-found

@TylerAPfledderer can you try running npx contentlayer build and see what happens?

$ npx contentlayer build
Warning: Contentlayer might not work as expected on Windows
Generated 113 documents in node_modules/.contentlayer

Ran yarn dev and the docs are now successfully rendering. Thank you!


more access to dual solution; less degeneracy?

We don't have a good way to process the dual solution / SoS proof at the moment. This is probably mostly because I haven't figured out how to get anything human-meaningful out of it yet anyway. It seems like there's often a lot of degeneracy in the dual solution -- a fairly large convex space of possible SoS proofs -- and the one that the solver spits out isn't special in any way. When we (Cholesky or SVD) factor into a sum of squares, the results are dense, generic-looking polynomials. Ideally we'd like a SoS proof with, say, recognizable coefficients, low rank, or sparsity, when possible. When there's a human-comprehensible SoS proof, it'd be powerful to be able to recover that.

see also #6 -- ideas in both of the papers linked there should make dual solutions more comprehensible.


2023 03 30

frame normalization, cleaned up interpolation, and a successful run with the newly built priors


Cannot compile with info.picocli:picocli-spring-boot-starter dependency

I'm using info.picocli:picocli-spring-boot-starter:4.6.0 as a Gradle dependency.
Looks like that after fixing Gradle warnings info.picocli:picocli:4.6.0 transitive dependency became runtime and its classes can't be used at compile-time.
https://github.com/remkop/picocli/blob/572e05f98a39af074cc4872ed1eb4261fad311c2/picocli-spring-boot-starter/build.gradle#L19-L20
I suppose api should be used instead of implementation, as Gradle treats implementation as runtime only dependencies.
Take a look: https://mvnrepository.com/artifact/info.picocli/picocli-spring-boot-starter/4.6.0

I suggest changing this: https://github.com/remkop/picocli/blob/572e05f98a39af074cc4872ed1eb4261fad311c2/picocli-spring-boot-starter/build.gradle#L19-L20
... to:
 api     rootProject
 api     "org.springframework.boot:spring-boot-starter:$springBootVersion"

This change should fix the issue.

I suggest changing this: https://github.com/remkop/picocli/blob/572e05f98a39af074cc4872ed1eb4261fad311c2/picocli-spring-boot-starter/build.gradle#L19-L20
... to:
 api     rootProject
 api     "org.springframework.boot:spring-boot-starter:$springBootVersion"

This change should fix the issue.

Thank you for raising this!
This is fixed in the 4.6.1 release.

Thank you for raising this!
This is fixed in the 4.6.1 release.


PHP 7.2 support: Nette\Object extension still occurs in the code

Affected version: 5.4.9
Nette\Object is still extended by the:

Ublaboo\DataGrid\Utils\DateTimeHelper
Ublaboo\DataGrid\DataSource\FilterableDataSource

@jaroslavlibal Thank you, v5.4.10.


Inconsistent buttons bug

I have a screen (HomeScreen) with a button (RectButton) to navigate to a different screen (TagScreen).
On the TagScreen, I have list of names which can be tagged (usernameList), and an empty list to contain names which will be tagged (taggedUserList).
Both the list (usernameList and taggedUserList) have User items, which are wrapped inside RectButton, to toggle its tagged state.
However, after I have tagged/selected one User, the button does not ripple to its full height and width. It just displays a rectangular shaped ripple around the corner of the View.

As you can see from the above video, after a user is selected, only the first selected user's button work properly.
I have made a snack which reproduce the same issue. Bug Snack.
What I have found:

If the TagScreen is rendered in the App.js without any navigation stuff, button seems to work fine.

If the taggedUserList elements are removed from the TagScreen, the usernameList element buttons seems to work properly.

+1

Same with me.

I have same
Is it fixed?

Any update on this ?

this issue still exists.

Seems to be working in 1.5.0

I seems to happen only when borderRadius is set.


#[serde(borrow)] does not work with Option<Cow<'a, str>>

Minimal repro:
#[derive(Debug, PartialEq, serde::Serialize, serde::Deserialize)]
struct Demo<'s> {
    #[serde(borrow)]
    message: Option<Cow<'s, str>>,
}

#[test]
fn demo() {
    let data_orig = Demo {
        message: Some(Cow::Borrowed("Hello World")),
    };
    let bincode_buf = bincode::serialize(&data_orig).expect("serialize");
    let data_new: Demo = bincode::deserialize(&bincode_buf).expect("deserialize from buffer");
    assert_eq!(data_orig, data_new);
    assert!(matches!(data_new.message, Some(Cow::Borrowed(_))));
}

Expected behavior: the test should pass, because the string in the Cow should be borrowed from the Bincode buffer.
Actual behavior: the test fails on the assert!(matches!(...)) line, and passes if I change Cow::Borrowed to Cow::Owned.
I believe it is desired to pass the lifetime down through the Option, since Serde does this with raw string references, according to https://github.com/serde-rs/serde/issues/1029.
Related: https://github.com/serde-rs/serde/issues/723, https://github.com/serde-rs/serde/issues/1497
CC @Manishearth

Please note that fixing this bug may be a breaking change unfortunately, because people may have written data structs such as the above with the assumption that they worked with borrowed data, but then used those structs in a situation where DeserializeOwned is required.

As a workaround I wonder if it's possible for users to write a custom deserialize_fn which behaves much like de::borrow_cow_str?

I proposed a fix for this bug in https://github.com/serde-rs/serde/pull/2072 but the fix was declined.

It is possible to use serde_with v1.10.0 to borrow when the Cow type is nested. From the release notes:
use serde_with::{serde_as, BorrowCow};
use std::borrow::Cow;

#[serde_as]
#[derive(Deserialize, Serialize)]
struct Data<'a> {
    #[serde_as(as = "Option<[BorrowCow; 1]>")]
    nested: Option<[Cow<'a, str>; 1]>,
}

let mut d: Data<'static> = serde_json::from_str(r#"{"nested": ["foobar"]}"#)?;
let [cow] = d.nested.take().unwrap();
match cow {
    Cow::Borrowed(_) => println!("borrowed"),
    Cow::Owned(_) => println!("owned"),
};
// => Prints borrowed

If this is closed as "won't fix", I'd like to suggest that at least serde(borrow) should complain if it tags something it doesn't know how to borrow.
The problem of getting the desired functionality is one thing, but the footgun of thinking you're borrowing when you're actually not is much worse.

As @robertbastian found in https://github.com/unicode-org/icu4x/pull/1556, #[serde(borrow)] works with Option<Cow<'a, T>> but not Option<Cow<'a, str>>.  I still believe this is a major footgun that should be fixed in Serde itself, either nby making it work as expected or by throwing some sort of error.

I think that it's… kind of ridiculous to have to wrap things in serde_as to get the proper borrow behaviour. Like, if the issue is that it's a breaking change, then… bump the major version, and fix it. Or, if you're that concerned, make serde(borrow_except_it_actually_works_correctly) and have that match the intended behaviour.
Sorry for being kinda salty about this, but I don't think that retaining compatibility with broken behaviour is a reason to not implement correct behaviour in any capacity.


Translated to Portuguese Brazil

My contribution to the application translation into Portuguese language Brazil, where I made a good review and adjustments of the terms in English to the Portuguese. I hope you enjoy the job done!


[BUG/ISSUE] Wider text area for dropdown menus

Before submitting the issue

[x] I have checked that the bug is not a duplicate or, if it is, it needs to be reopened
[x] I have checked that I am running the latest version of WingetUI
[x] I have tried resetting and reinstalling WingetUI and the issue persisted or happened again
[x] I have checked the FAQ section for solutions
[x] I have read the contributing guidelines and I agree with the Code of Conduct

Describe the bug

On this button in the settings, the German text doesn't fit. BUT it's only because the text cannot fill the entire button. There would be enough space

@marticliment there are potentially a few similar cases where the text doesn't fit. Would it be possible to make the boxes automatically expandable to avoid this problem?

Thanks :)


Added saleae-logic version 1.2.14

If there’s a checkbox you can’t complete for any reason, that's okay, just explain in detail why you weren’t able to do so.
After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if updating a cask:

[ ] If the sha256 changed but the version didn’t,
provide public confirmation by the developer: {{link}}

Additionally, if adding a new cask:

[x] Named the cask according to the token reference.
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.
[x] Checked there are no open pull requests for the same cask.
[x] Checked the cask was not already refused in closed issues.
[x] Checked the cask is submitted to the correct repo.

Why do we have a separate formula in homebrew-drivers when it already exists in the homebrew-cask? (https://github.com/caskroom/homebrew-cask/blob/1aa96170ead3e2bb659a240ac5087f78bc147540/Casks/logic.rb)

PR to remove from caskroom/cask: https://github.com/caskroom/homebrew-cask/issues/36635
Thanks for spotting this @wilfrieddaniels!


.yml extension has no icons

it looks like only .yaml file extension works, but .yml is a valid file extension for Yaml files too.

In the latest version, .yml is supported. I plan to close this issue tomorrow. Thank!

Thanks!


Centos 7 fails to remove files or directories which are created on build of the image using overlay or overlay2.

Description
Centos 7 fails to remove files or directories which are created on build of the image using overlay or overlay2.
Steps to reproduce the issue:
Scenario 1
Try to build the following image
FROM centos:6

RUN \
    rm -rf /var/lib/yum/yumdb && /
    echo END

Scenario 2

docker run -it centos
rm /bin/egrep
ls -lhart | grep egrep

Describe the results you received:
Scenario 1
Step 1 : FROM centos:latest
 ---> 980e0e4c79ec
Step 2 : RUN rm -rf /var/lib/yum/yumdb && /
 ---> Running in 6d563251bb19
rm: cannot remove '/var/lib/yum/yumdb/a/85e19f5abe37c08a77c42f24624d852a338583bd-acl-2.2.51-12.el7-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/a/b79b02a804fda6e4a10d4c1a68975a323363c2b2-audit-libs-2.4.1-5.el7-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/b/4e3611aa330e1eb8c42401709d03c6b3746b8a75-binutils-<IP_ADDRESS>.1-55.el7-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/b/62be349c36ee42d628776a98d2d4b688a9fe4203-bash-4.2.46-20.el7_2-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/b/cdf13cd90ccdecfc009b4cb319471faa995a9fa3-bind-license-9.9.4-29.el7_2.3-noarch': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/b/ed5c44b6d81784129138935e009a5d71fcca2e22-basesystem-10.0-7.el7.centos-noarch': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/b/fdf683c5a9852bb4ccf883ff042042923b8cd33f-bzip2-libs-1.0.6-13.el7-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/c/0ec1f87be823c6009e3635d19d9c4302e19d4575-cpio-2.11-24.el7-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/c/57bf8951d232f117c7e19bbcebfc6a40d15f7e78-cryptsetup-libs-1.6.7-1.el7-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/c/5a28ca24d3ccf264d0009576e41df09a4400b499-cracklib-dicts-2.9.0-11.el7-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/c/6e1e6faa0142bab65d7342c0b67b838c9abe07ef-ca-certificates-2015.2.6-70.1.el7_2-noarch': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/c/75c7de956ef79c6d91a2049523fc4fec931e8990-coreutils-8.22-15.el7_2.1-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/c/7c6a1ce1ee0ff382b98e0f584ad5a5b3ba523785-chkconfig-1.3.61-5.el7_2.1-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/c/988d2338f7dc11e0c5b63c2165b488b80cec883b-centos-release-7-2.1511.el7.centos.2.10-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/c/bc5c88cecec32eb303b45fc24611a2d859603bc9-cyrus-sasl-lib-2.1.26-20.el7_2-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/c/c1a9cb40fa6041bdfb09fb82c63aa8c6b34b3345-cracklib-2.9.0-11.el7-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/c/c1fefbbaf7e3b7e7c756f71d6856faa8c0fae569-curl-7.29.0-25.el7.centos-x86_64': Directory not empty
rm: cannot remove '/var/lib/yum/yumdb/d/067d41965a62020e76eea1686386e17cc178ac63-device-mapper-libs-1.02.107-5.el7_2.5-x86_64': Directory not empty

Scenario 2
[root@04f727c9abcc bin]# ls -lhart | grep egrep
ls: cannot access egrep: No such file or directory
??????????? ? ?    ?       ?            ? egrep
-rwxr-xr-x. 1 root root  123 Jul 27  2015 zegrep
lrwxrwxrwx. 1 root root    6 Sep  6 14:00 xzegrep -> xzgrep

Describe the results you expected:
Files should be removed correctly without errors.
Output of docker version:
Client:
 Version:      1.12.2
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   bb80604
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.2
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   bb80604
 Built:
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 21
 Running: 13
 Paused: 0
 Stopped: 8
Images: 19
Server Version: 1.12.2
Storage Driver: overlay2
 Backing Filesystem: xfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.8.1-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 3.848 GiB
Name: host2
ID: AEWS:D74L:S5HN:F6TX:KSYL:FMBO:KF4C:AMME:CCT6:THJB:2PRH:VW7T
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
 <IP_ADDRESS>/8

Additional environment details:
VM on Hyper-V
It looks to be a kernel Issue as it is also mentioned here: https://bugs.centos.org/view.php?id=11878&nbn=1. Posted here for visibility

Looks like you're running a custom kernel (4.8), instead of the 3.10 kernel provided by CentOS; note that we generally don't support that, especially on CentOS/RHEL, as there's a lot of back ports done by Red Hat on those distro's, which can be very specific.
Thanks for adding that link though, I'll add "overlay" and "kernel" labels
/cc @dmcgowan @AkihiroSuda

Couldn't hit in my environment

Ubuntu 16.04
Kernel 4.8.1 vanilla (config is from Ubuntu 16.04's kernel 4.4.0)
Storage driver is overlay2 (backing filesystem is ext4)

So the issue seems specific to XFS or ELRepo's patches/configs..
I'll try to set up an environment much more similar to the original report..

On CentOS7 + ELRepo kernel 4.8.1-1, I can reproduce the issue with xfs but not with ext4

@thaJeztah I managed to replicate also using overlay using 3.18 kernel.
After further investigation, I noticed that my xfs partition had ftype set to 0. Red Hat states that xfs partitions need to be formatted with ftype set to 1 if they are to be used with overlay.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.2_Release_Notes/technology-preview-file_systems.html
I guess the issue can now be closed as it's not Docker related. Hopefully people who encounter this issue can stumble upon this issue for a solution.

@darrenscerri oh, interesting; would this be something we should check for in our check-config script? https://github.com/docker/docker/blob/master/contrib/check-config.sh (Or from docker itself even when using the overlay driver) not sure if it's easy to add a check for this

rkt seems detecting this: https://github.com/coreos/rkt/pull/3105/files#diff-b5ccff3f3777d1b87c84277733a8c04fR393
I'll try to make a PR in similar way
Also, recent kernel shows a warning (not an error) in dmesg about this issue https://github.com/torvalds/linux/commit/e7c0b5991dd1be7b6f6dc2b54a15a0f47b64b007


feat: allow customizing buf modified symbol

Hey, thanks for the great plugin! Made a small change to allow customizing the modified symbol for people who prefer ●. Included an example in the readme configuration as well.

 Thanks for the help with this and the dim_inactive and for being very thorough!


Block Indent/unindent is slow for many lines

Most of the time spent is in the memory manager or WideStrUtils & WStrCat.
Using regular strings rather than PChar & WideStrUtils should be enough to solve it, and would avoid the duplications and allocations.

Quick fix done. Needs testing.

Fixed.


Update scene-understanding-SDK.md

Added links to the sample page

Docs Build status updates of commit 89a199a:
:clock10: Pending: waiting for processors (6 builds ahead of you)
:warning: Docs Build is busy, currently there are 6 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 89a199a:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

mixed-reality-docs/scene-understanding-SDK.md
:white_check_mark:Succeeded
View

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.


Fix VmaVector resize call

Thanks for spotting this. I've checked with @adam-sawicki-amd  who's the VMA library's author and he confirmed this is an actual bug.
Another thing is we really need to update this dependency, as it's been months since its version was last bumped. Will try to take care of it in the coming weeks.

That's right. The bug is already fixed in latest version of the library.


Disaster recovery

I need to recreate databases from a different cluster.
As of kubedb 0.9.0, there is no easy way to achieve this:

it's not possible to create a Snapshot resource for a non-existent database
if you create a db, so you can create a Snapshot (in Succeeded state), you can't initialise that db from the snapshot, because the admission webhook denies the request to change spec.init

Ideally, I would like to specify a Snapshot template in spec.init, and the operator automatically would create a Snapshot resource from the latest snapshot, and initialize the db from that.
Something like
apiVersion: kubedb.com/v1alpha1
kind: Postgres
metadata:
  name: recovered-postgres
  namespace: demo
spec:
  version: "9.6-v1"
  databaseSecret:
    secretName: script-postgres-auth
  storage:
    storageClassName: "standard"
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 50Mi
  init:
    snapshotSource:
        #name: instant-snapshot ## Optional, if omitted, the latest snapshot will be used
        #namespace: demo        ## Optional, defaults to the namespace of the database
        spec:
          storageSecretName: s3-secret
          s3:
            endpoint: 's3.amazonaws.com'
            bucket: kubedb
            prefix: demo

Discussion on slack: https://kubernetes.slack.com/archives/C8149MREV/p1545138216241300

In case of disaster or to restore a db from Snapshot in a new cluster, we won't have the respective Snapshot crd. So, we have to create it manually.
Recovery flow should be:

Install KubeDB in the new cluster.
Create Snapshot crd manually.
Create database crd with init section configured to initialize from the Snapshot.

Problem-1:
Creating Snapshot manually in step 2 will not succeed. KubeDB validator will reject to create the Snapshot as respective database does not exist.
Temporary Workaround of Problem-1:
A temporary workaround for problem-1 can be disabling Snapshot validator temporarily.
To disable Snapshot validator edit validators.kubedb.com validatingwebhookconfiguration and remove or modify snapshot.validators.kubedb.com section.
Example:
kubectl edit validatingwebhookconfiguration validators.kubedb.com

Then, change
 resources:
   - snapshots

to something invalid. i.e.
 resources:
   - snapshots-disabled

Then create the Snapshot. Once, the Snapshot is created, enable the webhook again.
Problem-2:
If we can solve Problem-1 we will hit another problem. When we will create a Snapshot crd, KubeDB will try to backup the respective database and will cause error as the database does not exist.
Temporary Workaround of Problem-2:
KubeDB does not process andy Succeeded or Failed Snapshot. So, we can create the Snapshot by setting status.phase: Succeeded.
Example:
apiVersion: kubedb.com/v1alpha1
kind: Snapshot
metadata:
  name: instant-snapshot
  namespace: demo
  labels:
    kubedb.com/kind: Elasticsearch
spec:
  databaseName: es-demo
  s3:
    endpoint: 's3.amazonaws.com'
    bucket: kubedb
    prefix: demo
status:
  phase: Succeeded

However, none of the workaround are not expected and hard to automate. We should have native support for this use case.

The workaround for Problem2 doesn't work for me, I still end up with a snapshot in a "Failed" state. This is kubedb 0.10.0 on Azure Kubernetes Services. This doesn't seem to prevent a restore of the snapshot, though, so maybe the workaround isn't required at all.

Okay here is what I did:

created new database with name quick-postgres to new cluster. Took empty snapshot from it with name instant-snapshot. It created empty snapshot fine and it succeeded. File is available in S3
created snapshot in old cluster in old database with name instant-snapshot it overwrites the empty snapshot file
Modified new cluster quick-postgres terminationPolicy to DormantDatabase and deleted the database using kubectl delete postgres quick-postgres.

After this we are in situation that we have working snapshot in new cluster, and also sql dump is available in S3 in correct path.

restore from snapshot like usually

Example
apiVersion: kubedb.com/v1alpha1
kind: Postgres
metadata:
  name: quick-postgres
  namespace: foobar
spec:
  version: "11.1"
  storageType: Durable
  replicas: 3
  databaseSecret:
    secretName: quick-postgres-auth
  storage:
    storageClassName: "csi-sc-cinderplugin"
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 8Gi
  terminationPolicy: DoNotTerminate
  init:
    snapshotSource:
      name: instant-snapshot
      namespace: foobar

And Tadaa! your database is moved from cluster to another. However, this is not perfect way if your old cluster is broken!

Is there a more elegant way existing as of today?
In my opinion, one should not have to fiddle with the workarounds above if you want to restore a snapshot to a different cluster.

KubeDB v2021.03.17 now uses Stash for backup/recovery. This issue is resolved.


[RFC] Making a true Runtime Singleton

The Propel class is not a true singleton. It's a class full of static methods, not easily replaceable. I suggest to refactor it to a true singleton class, the only one in Runtime, holding a reference to all the necessary configuration:

connections
runtime model (Map classes)
adapters
logger

I have started refactoring the Propel class to make the domain more apparent (see https://github.com/fzaninotto/Propel2/commit/2f1cbfb84d2264796aa5ade67c765156c11a61e0). This must go further.
So in the runtime code, any call to
$con = Propel::getConnection(BookPeer::DATABASE_NAME, Propel::CONNECTION_READ);

should be rewritten to something like:
$con = Propel::getInstance()->getSlaveConnection(BookPeer::DATABASE_NAME);

The naming is important. Propelmight not be the best name. Registry also sounds too vague for me. It's a registry for runtime configuration - there are other types of registry in Propel. Manager is not good either, as it doesn't manage much more than configuration. Any suggestion?  I'd vote for Propel\Runtime\Configuration:
$con = Configuration::getInstance()->getSlaveConnection(BookPeer::DATABASE_NAME);

which, incidentally, is a little shorter than the Propel::getConnection() version.
But there is also a Configuration namespace in Runtime. However, it contains code that can be removed if the convert-conf class creates a Configuration singleton. Something like:
<?php
// in generated $bookstore-conf.php
$conf = \Propel\Runtime\Configuration::getInstance();
$conf->addDatasource('bookstore', array(
  'dsn' => 'mysql:dbname=test',
  'user' => 'foo',
  'password' => 'bar',
  'options' => array('ATTR_PERSISTENT' => false)
));
$conf->addAdapter('bookstore', 'Propel\Runtime\Adapter\MysqlAdapter');
$conf->setDefaultDatasource('bookstore');

Advantage: Configuration can easily be done by hand, using this class. The convert-conf task would just be a utility, taking XML as input but also YAML, or whatever you want. And in the Symfony2 integration, no need for that - the DI would populate the conf at will, maybe by subclassing it and injecting the DIC. That means we can probably get rid of the classes currently under Propel\Runtime\Configuration.
I know it's a BC break, but I think it's necessary.
Comments?

Why do you use the Configuration NS so?
What about :

Propel\Runtime\ServiceProvider\ServiceProviderInterface
Propel\Runtime\ServiceProvider\StandardServiceProvider

And while we are at it... getInstance() is the sign of the Singleton pattern, which returns always the same instance of the current class. In this case, it's not a singleton, since it returns always the same instance of another class. To avoid confusion, I suggest to replace Propel::getInstance() by something like Propel::getServices(), or Propel::getConfiguration(), or whatever feels intuitive and short to write.

@jaugustin, any opinion?

we could make Propel::getContainer() return a SF2 DIC or a light container that contains services we need :

configuration
connection

But I need to think more about this and how to use it alone or with a sf2 apps

I don't want to Propel depend on a DIC. One can implement a ServiceProvider using the Symfony2 DIC (this will be necessary in PropelBundle), but the current Configuration class does the job (lazy-loading, injecting dependences) pretty well. After all, this is like a 'compiled' DIC.

To add a DIC is not on our roadmap, and we should not design Propel to only fit Symfony2 expectations..
DI is an implementation of the Inversion of Control (IOC) design pattern but this is not the unique solution.
DIC means configuration required which is something we don't want.
The Configuration class seems to implement this pattern but it has a really bad name. ServiceProvider is better but now, we need a shortcut.
Propel::getContainer() seems good as well, short and explicit. We may call the ServiceProvider a ServiceContainer which is more or less the same thing.
Propel::getProvider() is too generic anyway.
The question here is how to construct the Container/Provider class in the Propel kind of singleton + proxy ?
It seems we are building a StaticContainer (poke @jaugustin :)). But we are all agree this is a good thing for Propel.
Le 19 nov. 2011 à 14:11, Francois<EMAIL_ADDRESS>a écrit :

I don't want to Propel depend on a DIC. One can implement a ServiceProvider using the Symfony2 DIC (this will be necessary in PropelBundle), but the current Configuration class does the job (lazy-loading, injecting dependences) pretty well. After all, this is like a 'compiled' DIC.

Reply to this email directly or view it on GitHub:
https://github.com/propelorm/Propel2/issues/51#issuecomment-2798719

Something like:
<?php
use Propel\Runtime\ServiceProvider\StandardServiceProvider;
use Propel\Runtime\Propel;
$provider = new StandardServiceProvider();
$provider->setConnectionConfiguration('default', array(
  'dsn' => 'mysql:dbname=test',
  'user' => 'foo',
  'password' => 'bar'
));
$provider->setAdapterClass('default', 'Propel\Runtime\Adapter\Pdo\MysqlAdapter');
Propel::setProvider($provider);

would be a sufficient setup for Propel. Now, in the code, the configuration instance would be retrieved via:
<?php
$con = Propel::getProvider()->getConnection('default');

Sounds fine to me. Not very fan of the word Provider, though. Any other ideas?

@willdurand Yes my static container ;) is what I had in mind.
@fzaninotto for name Container or Services

Container is fine :)
Envoyé de mon iPhone
Le 19 nov. 2011 à 15:20, Jérémie<EMAIL_ADDRESS>a écrit :

@willdurand Yes my static container ;) is what I had in mind.
@fzaninotto for name Container or Services

Reply to this email directly or view it on GitHub:
https://github.com/propelorm/Propel2/issues/51#issuecomment-2798934

I'm still not very comfortable with the naming. Container means it contains something. The important word, Service, is not there, so to me it should really be ServiceContainer.
However, we want to give an easy access to the services provided by the container, and Propel::getServiceContainer()->getConnection() is really too long.
To sum up, we want to reach two goals that turn out to be contradictory: name our components in the "purest" way (from a domain-design point of view), and let the user deal with these components in the easiest way. The solution might be to duplicate naming, so as to reach both goals. Let me explicit.
The best name for the service container is ServiceContainer. So in the implementation, as well as in the generated code, we should use this name. If it's long to write, it's clear enough to be read fast.
<?php
$con = Propel::getServiceContainer()->getConnection('default');

However, in the documentation, we don't want to force the user to understand the inner workings of Propel to be able to use it. The concepts of Service and Service Container are NOT universally known, and explaining them in order to let the user get to a database connection is, in my opinion, a mistake. Therefore, we should "hide" this architecture behind an easy-to-use interface, which turns out to be:
<?php
$con = Propel::getConnection('default');

It is not much work to implement all the methods of the ServiceContainerInterface as static methods in the Propel class, proxying calls to the ServiceContainer instance. A little help from __callStatic() can even give full access to the services via static methods.
So I'm for reintroducing a few static methods into the Propel class, even if the implementation follows the ServiceContainer pattern we discussed here. These methods shouldn't be used in generated code (because they would slow down execution), but should be advocated for in the documentation.

+1 for proxy
user could use :
<?php
$con = Propel::getConnection('default');

and internaly we could use proxy in class itself to call Propel::getServiceContainer only once and proxify getConnection only where it is realy used not on every method that cascad the connection

I thought about to use the Propel class as a real Proxy too. I think I'm ok.
Le 19 nov. 2011 à 20:42, Francois<EMAIL_ADDRESS>a écrit :

I'm still not very comfortable with the naming. Container means it contains something. The important word, Service, is not there, so to me it should really be ServiceContainer.
However, we want to give an easy access to the services provided by the container, and Propel::getServiceContainer()->getConnection() is really too long.
To sum up, we want to reach two goals that turn out to be contradictory: name our components in the "purest" way (from a domain-design point of view), and let the user deal with these components in the easiest way. The solution might be to duplicate naming, so as to reach both goals. Let me explicit.
The best name for the service container is ServiceContainer. So in the implementation, as well as in the generated code, we should use this name. If it's long to write, it's clear enough to be read fast.
<?php
$con = Propel::getServiceContainer()->getConnection('default');

However, in the documentation, we don't want to force the user to understand the inner workings of Propel to be able to use it. The concepts of Service and Service Container are NOT universally known, and explaining them in order to let the user get to a database connection is, in my opinion, a mistake. Therefore, we should "hide" this architecture behind an easy-to-use interface, which turns out to be:
<?php
$con = Propel::getConnection('default');

It is not much work to implement all the methods of the ServiceContainerInterface as static methods in the Propel class, proxying calls to the ServiceContainer instance. A little help from __callStatic() can even give full access to the services via static methods.
So I'm for reintroducing a few static methods into the Propel class, even if the implementation follows the ServiceContainer pattern we discussed here. These methods shouldn't be used in generated code (because they would slow down execution), but should be advocated for in the documentation.

Reply to this email directly or view it on GitHub:
https://github.com/propelorm/Propel2/issues/51#issuecomment-2800486

@jaugustin: I don't like to "cache" the ServiceContainer Services as static variables of the Propel class. That prevents the user from changing these services at runtime. And for our own unit tests, for instance, it would create many problems.

#58 has been merged.
The Propel class still handles the logger and identity map, but e know we'll move these ones. So I'll close this ticket.


Morse Code converter

In this PR we have implemented the following:

[ ] Setup ruby environment
[ ] Added linter
[ ] Used workflow
[ ] Added methods to convert morse to their corresponding alphabet

Thank you @amejid


running the generate_3d_inst :  No such file or directory: 'tracker_lifted.txt'

Hello, dear authors, thank you for your great work.
When I run the generate_3d_inst.sh for ScanNet200, the error exists:
Traceback (most recent call last):
File "tools/generate_3d_inst.py", line 292, in
with open("tracker_lifted.txt", "r") as file:
FileNotFoundError: [Errno 2] No such file or directory: 'tracker_lifted.txt'
So what does this file use for?

Hi @RongkunYang,
The tracker files are used to keep track of processed scenes. You can simply uncomment this Line: https://github.com/VinAIResearch/Open3DIS/blob/main/tools/generate_3d_inst.py#L279


Cmd4 shows warnings if the bash scripts are not executables

Cmd4 shows warnings if the bash scripts are not executables
As I understand it, the bash script files do not need to be executable. They are .sh files run when the bash command runs them. But the Cmd4 plugin shows a warning in Homebridge, which is unnecessary.
Can you consider updating the plugin to not show warnings for normal .sh files?

Could you please copy/paste the warning you are writing about.
Thx,
John Talbot
On Mon, Jun 15, 2020 at 3:21 AM jsiegenthaler<EMAIL_ADDRESS>wrote:

Cmd4 shows warnings if the bash scripts are not executables
As I understand it, the bash script files do not need to be executable.
They are .sh files run when the bash command runs them. But the Cmd4 plugin
shows a warning in Homebridge, which is unnecessary.
Can you consider updating the plugin to not show warnings for normal .sh
files?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/58, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABSBCX6N6ZBLWNNIM35QB5DRWXDX5ANCNFSM4N54SNRQ
.

Your config.json as well please.
On Mon, Jun 15, 2020 at 3:24 AM John Talbot<EMAIL_ADDRESS>wrote:

Could you please copy/paste the warning you are writing about.
Thx,
John Talbot
On Mon, Jun 15, 2020 at 3:21 AM jsiegenthaler<EMAIL_ADDRESS>wrote:

Cmd4 shows warnings if the bash scripts are not executables
As I understand it, the bash script files do not need to be executable.
They are .sh files run when the bash command runs them. But the Cmd4 plugin
shows a warning in Homebridge, which is unnecessary.
Can you consider updating the plugin to not show warnings for normal .sh
files?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/58, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABSBCX6N6ZBLWNNIM35QB5DRWXDX5ANCNFSM4N54SNRQ
.

Here you go:
During platform initialization
[6/15/2020, 20:59:24] [Cmd4] Initializing Cmd4 platform...
[6/15/2020, 20:59:24] [Cmd4] Fetching config.json devices.

[6/15/2020, 20:59:24] [Cmd4] Processing accessory: Desktop PC
[6/15/2020, 20:59:24] [Cmd4] The command ./Cmd4Scripts/networkdevice.sh does not exist, It is highly likely the state_cmd will fail. Hint: Do not use wildcards that would normally be expanded by a shell.

[6/15/2020, 20:59:24] Initializing platform accessory 'Desktop PC'...

The relevant part of the config.json:
        {
            "platform": "Cmd4",
            "name": "Cmd4",
            "outputConstants": false,
            "accessories": [
               {
                    "type": "Switch",
                    "displayName": "Desktop PC",
                    "on": "FALSE",
                    "name": "Desktop PC",
                    "manufacturer": "Gigabyte",
                    "model": "Vista Home Premium",
                    "serialNumber": "abc123",
                    "polling": [
                        {
                            "on": "FALSE",
                            "interval": 2,
                            "timeout": 10000
                        }
                    ],
                    "state_cmd_prefix": "bash",
                    "state_cmd": "./Cmd4Scripts/networkdevice.sh",
                    "state_cmd_suffix": ""
                }
             ]
        }

This is interesting and you are correct.  In 'C' it is normal that when you call exec that the file to run be executable.  That is not the case in node.js.  I have the fix and will push it shortly.

fixed with commit 53b8f70.  it will be picked up in next release.


Cleanup NuGet.config

Summary
Clean up NuGet.config file to help with automated insertions from dependency flow.

Release Notes Entry

/backport to release/8.x


refactor(core): :recycle: corrected the 'OnClick' to 'onClick' props

corrected the 'OnClick' to 'onClick' props
ref: #139
Description
Clearly describe the changes you've made in this pull request. Explain the purpose and reasoning behind the changes. Reference any relevant issues or discussions using keywords like "Fixes #<issue_number>" or "Resolves #<issue_number>".
Related Issues

Testing

Checklist

[ ] I have performed a thorough self-review of my code.
[ ] I have added or updated relevant tests for my changes.
[ ] My code follows the project's style guidelines and best practices.
[ ] I have updated the documentation if necessary.
[ ] I have added or updated relevant comments in my code.
[ ] I have resolved any merge conflicts of my branch.

Screenshots (if applicable)

Additional Notes

Reviewers

Maintainer Notes

[ ] Has this change been tested in a staging environment?
[ ] Does this change introduce any breaking changes or deprecations?

Merging since approved.


Recommendation for working with large Blobs via bindings?

If I define my triggering blob as a Stream, the blob gets triggered but the data appears to be null. Then if I declare a BlobOutput and try to return the Stream object, it never gets written to the destination blob container. Assuming Stream is considered a rich binding, is there an alternative we will recommend for declaratively outputting large blobs in .NET 5 Functions?
Here are further details if needed.
The destination container exists in the same storage account, and no exception or error occurs.
Sample code snippet:
[Function("BlobTrigger1")]
[BlobOutput("destinationcontainer2/{name}", Connection = "AzureWebJobsStorage")]
public static Stream Run([BlobTrigger("test-samples2/{name}", Connection = "AzureWebJobsStorage")] Stream myBlob)
{
   return myBlob;
}

If I define my triggering blob as a string, and otherwise use the same code, the triggered blob gets written to the destination container.
The complete code is posted at the following locations in my GitHub repo:

Non-working Stream-based Function
Working string-based Function

Thank you, @gabesmsft
The approach here is to use a byte[] for input and output. We're considering Stream support but that would be misleading as the entire stream would need to be read to memory, buffered and passed in and out. This is due to limitations with the OOP model, which does to support streamed requests and responses today.

To add, the goal is to eventually support proper streaming between the two, allowing for this to be properly surfaced

Thanks @fabiocav , that makes sense. Byte[] isn't idle since the entire blob contents get loaded into memory, but glad there is the goal to eventually support streaming when using the OOP model.

Yeah, those are current OOP limitations and not specific to .NET (all OOP workers have the same behavior). We're intentionally keeping Stream out at this point so users are not confused when they realize that the entire stream is read/loaded, which would happen out output as well.


Error when converting xls file with german special character ß in file name

Gotenberg conversion fails when file name contains German special character ß.
Test file has the name Special_Chars_ß.xlsx.
Used curl to upload the file:
curl --request POST --url http://127.0.01:3000/forms/libreoffice/convert --header 'Content-Type: multipart/form-data' --form<EMAIL_ADDRESS>-o result.pdf
This leads to the following error:
{"level":"error","ts":1701360920.8984268,"logger":"api","msg":"convert to PDF: convert to PDF: unix process error: wait for unix process: exit status 6","trace":"2a1e60d7-745c-474c-a444-2ef7a0a30c74","remote_ip":"<IP_ADDRESS>","host":"<IP_ADDRESS>:3000","uri":"/forms/libreoffice/convert","method":"POST","path":"/forms/libreoffice/convert","referer":"","user_agent":"curl/8.1.2","status":500,"latency":57993208,"latency_human":"57.993208ms","bytes_in":8946,"bytes_out":21}
Special_Chars_ß.xlsx

Hello @joernv,
For whatever reasons, LibreOffice (unoconv?) struggles to open a filnename that contains non-basic latin characters. Before I find a fix, you should only use non-special characters.


Results in "client_ros.py" was always the same.. HELP!!!!

Eveything worked great, but the results(boxes_info) in "client_ros.py" was always the same.. Plz help!!
Plus, I check the "internal_memory.txt" file in "yolov5-ros/nvdsinfer_custom_impl_yolo", the content never change either.
Plz help guys

Hello,
This repo is for real time deepstream server, your issue should go into
nvidia deepstream instead.
thank you,
On Wed, Sep 29, 2021 at 6:39 AM ronnnhui @.***> wrote:

[image: Screenshot from 2021-09-29 13-32-11]
https://user-images.githubusercontent.com/37474567/135209244-264883fb-189d-4972-8402-47d2e0893028.png
Eveything worked great, but the results(boxes_info) in "client_ros.py" was
always the same.. Plz help!!
Plus, I check the "internal_memory.txt" file in
"yolov5-ros/nvdsinfer_custom_impl_yolo", the content never change either.
Plz help guys
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/deepstreamIO/deepstream.io/issues/1105, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AATKH2TCVDBDZHJ2LKVC253UEKQ7JANCNFSM5E672ZGQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

--
Slah Lachtar
Tel. (+216) 98 221 575

Hello, This repo is for real time deepstream server, your issue should go into nvidia deepstream instead. thank you,
…
On Wed, Sep 29, 2021 at 6:39 AM ronnnhui @.***> wrote: [image: Screenshot from 2021-09-29 13-32-11] https://user-images.githubusercontent.com/37474567/135209244-264883fb-189d-4972-8402-47d2e0893028.png Eveything worked great, but the results(boxes_info) in "client_ros.py" was always the same.. Plz help!! Plus, I check the "internal_memory.txt" file in "yolov5-ros/nvdsinfer_custom_impl_yolo", the content never change either. Plz help guys — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1105>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATKH2TCVDBDZHJ2LKVC253UEKQ7JANCNFSM5E672ZGQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
-- Slah Lachtar Tel. (+216) 98 221 575

I post the issue in wrong place, sorry about the trouble.


Diagram entity manual resizing is not saved

Description
When I manually resize an entity block on an ERD diagram I want this resizing to be saved.
DBeaver Version
Community, version <IP_ADDRESS>406091028
Operating System
Windows, macOS
Database and driver
Postgress, MySQL
Steps to reproduce
Create a diagram with at least one entity and manually resize at least one entity:

Save the diagram, close it and open it again.
Expected behavior: the manual resizing must preserve.
Actual behavior: the manual resizing is ignored:

Additional context
No response

Thank you for request.
It's a duplicate of #14988.
You can vote for the mentioned issue with 👍 under the issue description to promote it to a higher priority.


THEMES!

We should discuss Theming. 🤔

Tailwind themes is enough for our scenario.
My idea for Next Commerce, is more a: create your own frontend-store, quick and easy with powerful tools.WooCommerce idea of: use our plugins / templates, where everything looks more or less the same, and customizing is not that easy. Cause then you have to track upstream plugins/templates.

In a Shopify scenario, this means everyone uses the Debut theme and changes the styles. This would be extremely limiting.
For one example, the vercel/commerce theme is a 2 column layout with a slideshow. What if the user wants a single column and no slideshow? They could change @components/ProductView, but would run into upstream merge conflicts. Then, the more customization to the @components the more merge conflicts overtime right?
I'm approaching theming right now by creating a "theme/" folder in the root. Then I copy and paste the @component elements I want to customize into this folder. When I merge upstream, I can check if there are any updates to the original component that I want to frankenstein into my custom one. The advantage I see here (in the future) is being able to promote professional custom themes like Squarespace and Shopify. Not sure if this is the goal and/or the best method, but it would really invite a larger audience of users imo.

Hey @DanielHirunrusme , i would like to use the same approach, could you kindly describe the exact steps


docs: fix link to donation.md

Should add patreon? :p

Should add patreon?

I was thinking about removing links. From my experience this page is quite useless :)


chore(value-card-utils): increase testing coverage

Closes #2110
Summary

add tests to increase coverage

https://github.com/carbon-design-system/carbon-addons-iot-react/blame/ac59b53cb92fa6a609457ff43dd2c7d6136eaac1/packages/react/src/components/ValueCard/valueCardUtils.js#L50
I see @kevinsperrine mentioned in the test coverage that the method is deprecated, and that method has a comment next to it from two months ago that says I should be removed "next release"  -- should it be removed now? @davidicus @sstone2423

I see @kevinsperrine mentioned in the test coverage that the method is deprecated, and that method has a comment next to it from two months ago that says I should be removed "next release" -- should it be removed now? @davidicus @sstone2423

This should read next major release. We will keep this around until we go to v3 for our package. Thanks for following up on that.


Add Gradient Visualization on models

I was trying GradCam implementation from this repo on EfficientNet
https://github.com/jacobgil/pytorch-grad-cam
but could not make it work with. Size mismatch error occurs in the last layer.
How about adding functionality for GradCam, GuidedBackprop, and other similar gradient visualization methods for the models.

@sowmen not on my list of things todo, but open to contributions

looking forward to this func implemented

looking forward to this func implemented

looking forward to this func implemented

There's a pytorch library called Captuna. It contains many model visualization algorithms and works with all the models from this repo. Give that a try.

looking forward to this func implemented

There's a pytorch library called Captuna. It contains many model visualization algorithms and works with all the models from this repo. Give that a try.


Feature Request: Pluggable persistence provider

Hi,
Is there any chance that the existing LevelDB integration could be refactored as a plugin interface?
I'm very interested in using this library, but not so much with LevelDB and I would like to bring my own persistence layer. (Probably either AWS S3 or DynamoDB).
Regards,
Doug

I've made these changes myself in my fork here: https://github.com/ivan-topp/y-socket.io/compare/main...dhmw:y-socket.io:generic-persistence-interface
It removes y-leveldb as a dependency from this library, but should allow you to plug it in directly yourself.
My fork also includes an adaptor so that you can provide your own storage implementation.
To use level db with these changes, you can just instantiate it in your code:
import { YSocketIO } from 'y-socket.io/dist/server'
import { LeveldbPersistence } from 'y-leveldb'

const ysocketio = new YSocketIO(
  io,
  {
    persistenceProvider: new LeveldbPersistence()
  }
)
ysocketio.initialize()

Or, any other provider which implements the PersistenceProvider interface:
import { YSocketIO, PersistenceProvider } from 'y-socket.io/dist/server'

class MyStorage implements PersistenceProvider {
 // implement the methods getYDoc, storeUpdate, flushDocument
}

const ysocketio = new YSocketIO(
  io,
  {
    persistenceProvider: new MyStorage()
  }
)
ysocketio.initialize()

My fork also includes an intermediate adaptor GenericPersistenceAdaptor which manages some Y.Doc operations before it hits the storage, you need to feed this an implementation of GenericPersistence interface:
import { YSocketIO, GenericPersistenceAdaptor, GenericPersistence } from 'y-socket.io/dist/server'

class MyPersistence implements GenericPersistence {
 // implement the methods getYDoc, storeUpdate, flushDocument
}

const ysocketio = new YSocketIO(
  io,
  {
    persistenceProvider: new GenericPersistenceAdaptor(new MyPersistence())
  }
)
ysocketio.initialize()