Fails to build with gcc 12.2 – this not specified in enclosing parallel

Describe the bug
Fails to build from source on recent gcc:
ninja: job failed: /usr/bin/g++  -I./include -I./src -I/usr/include/python3.11 -isystem ./deps/install/include -isystem /usr/local/include -fomit-frame-pointer -DNO_STACKTRACE -Wall -Wno-unused-local-typedefs -Wno-unused-but-set-variable -Wno-unused-variable -Wno-unused-value -Wno-unused-function -Wno-reorder -DLGRAPH_USE_MOCK_KV=0 -D__STDC_FORMAT_MACROS -fopenmp -std=c++17 -static-libstdc++ -static-libgcc -O3 -DNDEBUG -std=gnu++17 -MD -MT plugins/CMakeFiles/lpa_standalone.dir/cpp/lpa_standalone.cpp.o -MF plugins/CMakeFiles/lpa_standalone.dir/cpp/lpa_standalone.cpp.o.d -o plugins/CMakeFiles/lpa_standalone.dir/cpp/lpa_standalone.cpp.o -c ./plugins/cpp/lpa_standalone.cpp
In file included from ./src/olap/olap_config.h:20,
                 from ./src/olap/olap_io.h:22,
                 from ./src/olap/olap_on_disk.h:17,
                 from ./plugins/cpp/lpa_standalone.cpp:15:
./include/lgraph/olap_base.h: In lambda function:
./include/lgraph/olap_base.h:704:46: error: 'this' not specified in enclosing 'parallel'
  704 |               for (size_t ei = 0; ei < this->num_edges_; ei++) {
      |                                        ~~~~~~^~~~~~~~~~
./include/lgraph/olap_base.h:703:9: note: enclosing 'parallel'
  703 | #pragma omp parallel for default(none)
      |         ^~~
./include/lgraph/olap_base.h: In lambda function:
./include/lgraph/olap_base.h:762:46: error: 'this' not specified in enclosing 'parallel'
  762 |               for (size_t ei = 0; ei < this->num_edges_; ei++) {
      |                                        ~~~~~~^~~~~~~~~~
./include/lgraph/olap_base.h:761:9: note: enclosing 'parallel'
  761 | #pragma omp parallel for default(none)
      |         ^~~
ninja: job failed: /usr/bin/g++  -I./include -I./src -I/usr/include/python3.11 -isystem ./deps/install/include -isystem /usr/local/include -fomit-frame-pointer -DNO_STACKTRACE -Wall -Wno-unused-local-typedefs -Wno-unused-but-set-variable -Wno-unused-variable -Wno-unused-value -Wno-unused-function -Wno-reorder -DLGRAPH_USE_MOCK_KV=0 -D__STDC_FORMAT_MACROS -fopenmp -std=c++17 -static-libstdc++ -static-libgcc -O3 -DNDEBUG -std=gnu++17 -MD -MT plugins/CMakeFiles/lcc_standalone.dir/cpp/lcc_standalone.cpp.o -MF plugins/CMakeFiles/lcc_standalone.dir/cpp/lcc_standalone.cpp.o.d -o plugins/CMakeFiles/lcc_standalone.dir/cpp/lcc_standalone.cpp.o -c ./plugins/cpp/lcc_standalone.cpp
In file included from ./src/olap/olap_config.h:20,
                 from ./src/olap/olap_io.h:22,
                 from ./src/olap/olap_on_disk.h:17,
                 from ./plugins/cpp/lcc_standalone.cpp:15:
./include/lgraph/olap_base.h: In lambda function:
./include/lgraph/olap_base.h:704:46: error: 'this' not specified in enclosing 'parallel'
  704 |               for (size_t ei = 0; ei < this->num_edges_; ei++) {
      |                                        ~~~~~~^~~~~~~~~~
./include/lgraph/olap_base.h:703:9: note: enclosing 'parallel'
  703 | #pragma omp parallel for default(none)
      |         ^~~
./include/lgraph/olap_base.h: In lambda function:
./include/lgraph/olap_base.h:762:46: error: 'this' not specified in enclosing 'parallel'
  762 |               for (size_t ei = 0; ei < this->num_edges_; ei++) {
      |                                        ~~~~~~^~~~~~~~~~
./include/lgraph/olap_base.h:761:9: note: enclosing 'parallel'
  761 | #pragma omp parallel for default(none)
      |         ^~~

Environment:

OS: Alpine Linux Edge
CPU: x86_64
Compiler: gcc 12.2.1

Additional context

https://gcc.gnu.org/gcc-9/porting_to.html#ompdatasharing

It's seems openmp is not correctly installed. Maybe you can refer the Dockerfile for compile environment, I haven't tried Alpine.
https://github.com/TuGraph-family/tugraph-db/blob/master/ci/images/tugraph-compile-centos7-Dockerfile#L31
https://github.com/TuGraph-family/tugraph-db/blob/master/ci/images/tugraph-compile-centos7-Dockerfile#L218

Add this to Good first issue. TODO: support GCC12 compilation


Fix generation of protocol buffer files

I'm getting these errors when trying to generate the protocol buffer files:
google/protobuf/descriptor.proto: File not found.
tagger/tagger.proto:5:1: Import "google/protobuf/descriptor.proto" was not found or had errors.
tagger/tagger.proto:10:8: "google.protobuf.FieldOptions" is not defined.
tagger/tagger.proto:15:8: "google.protobuf.OneofOptions" is not defined.
api.proto:19:1: Import "tagger/tagger.proto" was not found or had errors.
api/dps/api.generate.go:15: running "protoc": exit status 1

This happens after following the instructions. We need to update the instructions so that they actually allow users to generate the files in case it's needed.

The only way that this can fail is if this command can't resolve the include paths, which can have multiple reasons to fail:
protoc -I . -I /usr/local/include -I<EMAIL_ADDRESS>--gotag_out=:. --gotag_opt=paths=source_relative ./api.proto

To try to reproduce your issue, I unset the $GOPATH environment variable and uninstalled all of the dependencies listed in the README. When reinstalling them, it works as expected. In this case actually I did not even have to set the $GOPATH variable for it to work.
master $> go generate ./...
Using rosetta version 1.4.10
Found node version 0.21.1-0.20210908232656-c0afa789365e
Using middleware version 1.0.0

Can you check that you have the dependencies installed at the three following paths? Maybe for some reason, when you run go install, it does not use the same paths as for me 🤔.

<EMAIL_ADDRESS><EMAIL_ADDRESS>$GOPATH/pkg/mod/google.golang.org/grpc

Finally, and I think this is the most likely suspect -- can you check what you have in /usr/local/include? I'm not sure how it ended up here, but on my two machines, upon installing GRPC, the following files were added to /usr/local/include/google/protobuf/:
 ls /usr/local/include/google/protobuf/
total 116K
drwxr-x--- 3 ullaakut ullaakut 4.0K May 13 02:53 ./
drwxr-x--- 3 ullaakut ullaakut 4.0K May 13 02:53 ../
-rw-r----- 1 ullaakut ullaakut 5.8K May 13 02:53 any.proto
-rw-r----- 1 ullaakut ullaakut 7.6K May 13 02:53 api.proto
drwxr-x--- 2 ullaakut ullaakut 4.0K May 13 02:53 compiler/
-rw-r----- 1 ullaakut ullaakut  38K May 13 02:53 descriptor.proto
-rw-r----- 1 ullaakut ullaakut 4.8K May 13 02:53 duration.proto
-rw-r----- 1 ullaakut ullaakut 2.4K May 13 02:53 empty.proto
-rw-r----- 1 ullaakut ullaakut 8.0K May 13 02:53 field_mask.proto
-rw-r----- 1 ullaakut ullaakut 2.3K May 13 02:53 source_context.proto
-rw-r----- 1 ullaakut ullaakut 3.7K May 13 02:53 struct.proto
-rw-r----- 1 ullaakut ullaakut 6.4K May 13 02:53 timestamp.proto
-rw-r----- 1 ullaakut ullaakut 6.0K May 13 02:53 type.proto
-rw-r----- 1 ullaakut ullaakut 4.0K May 13 02:53 wrappers.proto

OK I think I know what the issue is. Apparently the new place for these files to be is no longer /usr/local/include but $HOME/.local/include. IMO, we should support both. I'll make a PR that adds that include path as well, if that makes sense to you guys.


Bugfix: Do not treat ignored field as missing member when deserializing from overriden json constructor

If all of the following conditions are true:

A class has any members marked as "JsonIgnore"
The class has a custom JsonContructor with parameters that do not include those ignored members
The SerializationSetting has MissingMemberHandling set to "Error"

Then a bug occurs, where Newtonsoft treats those ignored (but existing) members as missing members, and throws an exception.
Gist to reproduce this bug: https://gist.github.com/everfor/6d5ec290252da9de46c943882f24708d
This PR fixes the bug.
Add UT "DeserializeIgnoredPropertyInConstructorWithoutThrowingMissingMemberError" to confirm the fix works
The bug is also covered in https://stackoverflow.com/questions/59062524/property-with-jsonignore-attribute-not-ignored-when-deserializing-with-missingme

Yeah, that's a bug. Thanks for the fix and unit tests.
Merged!


Fix: Prepare publish

All changed packages have been documented!

You can try these changes at https://cadlplayground.z22.web.core.windows.net/typespec-azure/prs/212/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/typespec-azure/prs/212/


Remove unnecessary API version specification for tests

Goal

Testing

Release Notes

WHAT:
WHY:
WHO:

Current dependencies on/for this PR:

master

PR #339   👈

This stack of pull requests is managed by Graphite.

I read that for this test runner, some sensible default will be used to run your tests, e.g. the target API or something. Turns out that's not always true, or at least it's a configuration I haven't set up, and API version 1 is used if I remove these. I'm going to abandon this as I don't want to figure this out at this point.


Fixes 174

Depends on https://github.com/jdereus/labman/pull/184 so review/merge that one first.
Fixes #174

@josenavas would you mind updating this PR to resolve conflicts?

@ElDeveloper @tanaes are you available to take a look at this?

Taking a look now
On Wed, Feb 7, 2018 at 9:59 AM Jose Navas<EMAIL_ADDRESS>wrote:

@ElDeveloper https://github.com/eldeveloper @tanaes
https://github.com/tanaes are you available to take a look at this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jdereus/labman/pull/188#issuecomment-363855166, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AH6JAJKB92YncJixbLUOz2iMdBTo-AxAks5tSeR0gaJpZM4R569X
.

Also having a look at it.
On (Feb-07-18|18:01), Jon Sanders wrote:

Taking a look now
On Wed, Feb 7, 2018 at 9:59 AM Jose Navas<EMAIL_ADDRESS>wrote:

@ElDeveloper https://github.com/eldeveloper @tanaes
https://github.com/tanaes are you available to take a look at this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jdereus/labman/pull/188#issuecomment-363855166, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AH6JAJKB92YncJixbLUOz2iMdBTo-AxAks5tSeR0gaJpZM4R569X
.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/jdereus/labman/pull/188#issuecomment-363855883

Thanks!

Nice:

💥

@josenavas ready for me to merge?

Yup!!


A.26.IR38.md.contact.role

This issue has been extracted from the issue list on:https://ies-svn.jrc.ec.europa.eu/issues/2685
Comment
redundant and missing word at first bullet at "Open questions"
Proposed Change
"Is The the codeList URL ..."

Proposed Resolution
Agreed with proposed change.
Replace "Is The the codeList URL..." with "Is the codelist URL"


Update billing-upgrade-azure-subscription.md

localised content

Hi @Deansen, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

@Deansen : Thanks for your contribution to the Azure documentation! The author, @adpick, has been notified to review your proposed change.

#please-close

loc has the relative public for customer feedback, in the same way with EN. For example: https://github.com/Microsoft/azure-docs.de-de. About the PR: https://github.com/Microsoft/azure-docs/pull/584, decision is “Can’t be merged” for azure-docs (EN), please redirect the end user to  https://docs.microsoft.com/de-de/azure/billing-upgrade-azure-subscription to provide the feedback.
FYI: we localized this article billing-upgrade-azure-subscription.md already. But due to the internal tool’s issue, we can’t merged to de-de repo. Our Dev is fully aware of this issue, and is trying their best to fix it.

-Sunny


Messed up nerdtree window while restoring vim session by tmux-resurrect

Environment: Describe your Vim/NERDTree setup.

Operating System: macOS version: 10.13.3
Vim version :version: 8.0
NERDTree version git rev-parse --short HEAD: 97d2d70

NERDTree settings applied in your vimrc, if any:

    " NERDTREE
    " {
        autocmd vimenter * NERDTree
        autocmd VimEnter * wincmd p
        autocmd StdinReadPre * let s:std_in=1
        autocmd VimEnter * if argc() == 0 && !exists("s:std_in") | NERDTree | endif
        autocmd bufenter * if (winnr("$") == 1 && exists("b:NERDTree") && b:NERDTree.isTabTree()) | q | endif
        let NERDTreeShowHidden=1
        let g:NERDTreeWinPos = "left"
        let g:NERDTreeWinSize = 20
        map <Leader>n <plug>NERDTreeTabsToggle<CR>
    " }

Process: List the steps that will recreate the issue.

Install and config tmux-plugins/tmux-resurrect and tpope/vim-obsession

Follow tmux-resurrect step to restore vim session

Encounter messed up nerdtree window.

Current Result: Describe what you you currently experience from this process.

I ask for help from tmux-resurrect/issues/239 and the author consider excluding tmux-resurrect's responsibility.

Expected Result: Describe what you would expect to have resulted from this process.

I want my vim and nerdtree display without messed up.

Optional
Screenshot(s):

Thanks for your time.

See #2 and #337. There would be considerable refactoring needed to make sessions work correctly.


Fix RSS feed base URL

This is breaking links in Slacks' RSS feed integration

Nice, thanks!

Pushed.


[logins] Enabled SF and GH OAuth login

To associate accounts, just use the same link as for login, while already logged in, and add process=connect to the querystring.
See https://trello.com/c/YG9GLBf4/10-i-want-to-log-in-with-a-github-account

I think this is ready for clientside work.

 I want to log in with a github account


Install should only fetch from S3 if the requested version is a release.

Depending on "nodegit/nodegit#" still installs the latest release from S3 rather than building from the fetched source.

Woah, yeah, that's definitely a bug.

Just tested and this is no longer an issue.


Breaking Change: Updating async methods to follow C# async naming conventions

And updating version number.  This handles #183

Hi @hpsin, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Hirsch Singhal). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

This set I purposefully kept as *Async, since it’s the implementation of a required method.
From: Matt Hyman<EMAIL_ADDRESS>Sent: Monday, October 10, 2016 5:39 PM
To: Microsoft/WindowsDevicePortalWrapper<EMAIL_ADDRESS>Cc: Hirsch Singhal<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Microsoft/WindowsDevicePortalWrapper] Breaking Change: Updating async methods to follow C# async naming conventions (#188)
@MattHyman commented on this pull request.

In WindowsDevicePortalWrapper/WindowsDevicePortalWrapper.UniversalWindows/HttpRest/RestDelete.cshttps://github.com/Microsoft/WindowsDevicePortalWrapper/pull/188#pullrequestreview-3596542:

@@ -18,7 +18,7 @@

namespace Microsoft.Tools.WindowsDevicePortal
{
 /// <content>

/// Universal Windows Platform implementation of HTTP Delete

/// Universal Windows Platform implementation of HTTP DeleteAsync

Just "Delete" here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/WindowsDevicePortalWrapper/pull/188#pullrequestreview-3596542, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABltOw22Ed1iyTryLb7qb3kB8araDGnkks5qytq1gaJpZM4KTHhc.

Hirsch,
I actually deleted that comment shortly after creating it because I caught what you discussed below. Sorry for the noise.
Thanks,
Matt
From: Hirsch Singhal<EMAIL_ADDRESS>Sent: Monday, October 10, 2016 5:40 PM
To: Microsoft/WindowsDevicePortalWrapper<EMAIL_ADDRESS>Cc: Matt Hyman<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Microsoft/WindowsDevicePortalWrapper] Breaking Change: Updating async methods to follow C# async naming conventions (#188)
This set I purposefully kept as *Async, since it’s the implementation of a required method.
From: Matt Hyman<EMAIL_ADDRESS>Sent: Monday, October 10, 2016 5:39 PM
To: Microsoft/WindowsDevicePortalWrapper <WindowsDevicePortalWrapper<EMAIL_ADDRESS>Cc: Hirsch Singhal <hirsin<EMAIL_ADDRESS>Mention <mention<EMAIL_ADDRESS>Subject: Re: [Microsoft/WindowsDevicePortalWrapper] Breaking Change: Updating async methods to follow C# async naming conventions (#188)
@MattHyman commented on this pull request.

In WindowsDevicePortalWrapper/WindowsDevicePortalWrapper.UniversalWindows/HttpRest/RestDelete.cshttps://github.com/Microsoft/WindowsDevicePortalWrapper/pull/188#pullrequestreview-3596542:

@@ -18,7 +18,7 @@

namespace Microsoft.Tools.WindowsDevicePortal
{
///

/// Universal Windows Platform implementation of HTTP Delete

/// Universal Windows Platform implementation of HTTP DeleteAsync

Just "Delete" here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/WindowsDevicePortalWrapper/pull/188#pullrequestreview-3596542, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABltOw22Ed1iyTryLb7qb3kB8araDGnkks5qytq1gaJpZM4KTHhc.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/WindowsDevicePortalWrapper/pull/188#issuecomment-252782248, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABc0YwH9B7o8WaJU9aGvozJ7b2wQsuXOks5qytr1gaJpZM4KTHhc.


Kafka with SASL does not work in quarkus native mode

Cloned from https://issues.apache.org/jira/browse/CAMEL-16426.
When we run the quarkus native code, we get the error
Caused by: java.lang.SecurityException: Configuration error: java.lang.ClassNotFoundException: sun.security.provider.ConfigFile
The solution is to include sun.security.provider.ConfigFile class for Reflection.
Detailed conversation at
https://camel.zulipchat.com/#narrow/stream/257302-camel-quarkus/topic/ClassNotFoundException.20for.20Exception.20class

See also https://github.com/apache/camel-quarkus/issues/1783.

May also involve https://github.com/apache/camel-quarkus/issues/2333.


Merging Develop into Master 8.8.2018 - Unsubscribe Flow Update

Description of the change:
Reason for the change:
Link to original source:

Closes #

Hello @Whatthefoxsays,Thanks again for the PR! We appreciate your contribution and look forward to                                              continued collaboration. Thanks!                                             Team SendGrid DX


bzero pages

The kernel must bzero every page that it gives to userspace, to prevent leaking data from a process to another.
Unfortunately this implies a lot of overhead. We should find a way to be smart about it, and do it the less often possible.
First we need to decide if either:

All allocated pages are bzero'd, no matter if it's for landing them to user, or for kernel internal use.
Only userspace pages are bzero'd before use. This means that the kernel can re-use old dirty userspace pages for its own use, which could facilitate kernel exploits. However since the kernel is supposed to be so small, and all services reside in userspace, this might be acceptable.

Secondly, we need to find a strategy to keep track of dirty pages, and bzero them only once.
I imagine we can put to use the dirty flag in the page tables, but i don't really know when would be the best moment to do the clean. On allocation ? On clean ?
Also: Do we consider never-used pages as clean ? Are they guaranteed to be all zeros on boot ?
A lot of questions 😕

Can probably be closed with https://github.com/sunriseos/SunriseOS/blob/master/shell/img/meme7.gif

Given the number of "reboot and use some state left in RAM" attacks on various systems, I think that you cannot assume that never-used pages are clean.
There's a trade-off between whether you want allocation to be fast, or freeing to be fast. If you zero on allocation:

You don't have to clean never-used pages until they are actually used.

On the other hand, this may mean that stuff sticks around for a long time in memory, even if inaccessible.

Free (shouldn't) have to do anything extra.
If you zero on free:
Never-used pages should be cleared at boot.
Attacker controlled values go away as soon as the page is freed.

As a side-effect, I'd think this accomplishes 'zero memory on shutdown' kinda automatically

Allocation (shouldn't) have to do anything extra.

Upon thinking about this, I think I actually prefer zeroing on free due to the implications it has. Either a page is used and has valid(?) data, or is zero.

One unmentioned problem is that to bzero a page, it needs to be mapped. However the allocation of pages and their mapping is highly decoupled (frame_allocator vs. paging). This means we either have to:

have the frame_allocator re-map a frame every time it needs to bzero it (either at allocation or at free). This is a lot of overhead, and clearly not ideal.
map the whole RAM in our address space somewhere in the KernelLand, so that frame_allocator can bzero freed frames by accessing them directly. This is the preferred solution for 64-bit address spaces, however this is not applicable for 32-bit address spaces, since a 4GB address space isn't big enough.
find a way to re-couple the frame_allocator and paging on this matter. If we end up going for the 'zero on free' solution, we should use the 'dirty' bit in the page tables to skip pages that haven't been modified.


Fixing Game Render Box for flutter >= 1.25

Description
Flutter 1.25+ added a new method on RenderBox that needs to be implemented, this PR adds the method.
Flutter stable still don't have that new method, but since it was a method addition, flutter stable will continue to work fine, we just may get some lint warning when this version leave a pre release.
Either way, this change was tested on both stable and beta channel
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist:
If something is unclear, please submit the PR anyways and ask about what you thought was unclear.

[x] This branch is based on the latest master
[x] I have added an entry under [next] in CHANGELOG.md
[x] I have formatted my code with flutter format
[ ] I have made corresponding changes to the documentation
[ ] I have added examples for new features in doc/examples
[x] The continuous integration (CI) is passing

Sounds good to me
On Tue, Dec 22, 2020, 15:24 Erick<EMAIL_ADDRESS>wrote:

@erickzanardo commented on this pull request.
In lib/game/game_render_box.dart
https://github.com/flame-engine/flame/pull/587#discussion_r547305624:

@@ -79,4 +79,7 @@ class GameRenderBox extends RenderBox with WidgetsBindingObserver {
void didChangeAppLifecycleState(AppLifecycleState state) {
game.lifecycleStateChange(state);
}

@override
Size computeDryLayout(BoxConstraints constraints) => constraints.biggest;

That crossed my mind, but Renan reminded us that pre releases (which is
the case of our RCs) aren't analyzed by pub and I though on leaving this
correct since there is a (hopefully big) chance that the change will
already be on stable when we release the final V1. What do you think
@spydon https://github.com/spydon @christopherfujino
https://github.com/christopherfujino
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flame-engine/flame/pull/587#discussion_r547305624,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFV2Q44BMA5OFJSY2LNNVDSWCTZ7ANCNFSM4VETDYJQ
.


@sum_type doesn't work with constrained type parameter

e.g. this
julia> using SumTypes

julia> @sum_type A{X<:Real} begin
           B{X}(a::X)
           C(b::Int)
       end

throws
ERROR: TypeError: in A, in X, expected X<:Real, got Type{Uninit}
Stacktrace:
 [1] top-level scope
   @ ~/.julia/dev/SumTypes/src/sum_type.jl:202
 [2] top-level scope
   @ ~/.julia/dev/SumTypes/src/sum_type.jl:257

but I think this could work

inspecting the test I understood I should use Union{Real, Uninit}, this seems a bit awkward but probably then this can be closed?

ok I actually changed slightly the issue, this is now something which could be probably improvable

Yeah, this'll require a bit of thought to design correctly but should be possible I think. I wonder if we should just insert the Union{..., Uninit} ourselves if people constrain the parameters?

In my opinion yes, I'm already doing this in MixedStrucTypes.jl, there shouldn't be any problem doing that if I'm not mistaken

I'm not sure, but maybe it can be considered analogous to the case where you have a Union of types, there you can constrain parameters differently if you want

I ended up having ambiguity problems in MixedStructTypes because of this issue so I fixed it :-)


[feat] importmap treeshaking during build

By default that would be already great, indirectly described in https://github.com/jsenv/jsenv-template-pwa/issues/6 the build process should also be able to override a mapping (#env -> ./env.prod.js).
The urlOverrides should be implemented first

Fixed


glm.min and glm.max benchmark slower than python 3.11 min and max operating over glm.array[glm.c_float]

My benchmark was pretty informal, I used this hyperfine invocation:
> hyperfine --runs 5 --parameter-list impl pyglm,python 'python .\test-{impl}-min-max.py'

The two python scripts were this file, but with one of the two benchmarks uncommented in each:
import glm
from glm import min as glm_min

a = glm.array([glm.vec2(x, x + 1) for x in range(0, 10000, 2)])
a_x, a_y = a.split_components()

for i in range(99999):
    # PyGLM
    # glm_min(a_x)
    # glm_min(a_y)

    # Python
    min(a_x)
    min(a_y)

I got this output:
Benchmark 1: python .\test-pyglm-min-max.py
  Time (mean ± σ):     16.518 s ±  0.171 s    [User: 9.596 s, System: 0.023 s]
  Range (min … max):   16.370 s … 16.798 s    5 runs

Benchmark 2: python .\test-python-min-max.py
  Time (mean ± σ):     12.781 s ±  0.093 s    [User: 7.483 s, System: 0.023 s]
  Range (min … max):   12.705 s … 12.936 s    5 runs

Summary
  'python .\test-python-min-max.py' ran
    1.29 ± 0.02 times faster than 'python .\test-pyglm-min-max.py'

My first attempt used very small arrays.  But I increased the array size a lot, and python min and max are still faster.  I looked at #147, thinking maybe that slowed down min and max?  But I'm not sure.

The reason why min and max are slow in this context is because both operations currently only support list, tuple and other iterable types. Therefore, glm.array is simply interpreted as an iterable. Because there is a slight overhead in the glm.min function compared to the builtin min function (or max-function respectively), the builtin function is faster.
To change this, a dedicated routine for arrays would be required.
I think it's a very good idea to have one.

If I wanted to add a dedicated routine, where would I start?
On Sun, Feb 26, 2023, 4:03 AM Zuzu-Typ @.***> wrote:

The reason why min and max are slow in this context is because both
operations currently only support list, tuple and other iterable types.
Therefore, glm.array is simply interpreted as an iterable. Because there
is a slight overhead in the glm.min function compared to the builtin min
function (or max-function respectively), the builtin function is faster.
To change this, a dedicated routine for arrays would be required.
I think it's a very good idea to have one.
—
Reply to this email directly, view it on GitHub
https://github.com/Zuzu-Typ/PyGLM/issues/211#issuecomment-1445303455,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAC35ODPQQLJH4DIJ6O27X3WZML73ANCNFSM6AAAAAAVHLLFPY
.
You are receiving this because you authored the thread.Message ID:
@.***>


Issue Building Wheel with custom UMD

I am trying to eliminate the need for libnng and libuv to be shipped with tt-metal and distributed in the wheel.
To do so, I make the two dependencies private, and force them to be STATICALLY linked into libdevice.so
https://github.com/tenstorrent/tt-umd/pull/339
When testing this custom UMD in tt-metal CI...
the build-wheel workflow is still looking for shared libraries for nng and uv !!!???
https://github.com/tenstorrent/tt-metal/actions/runs/12046563342/job/33588021255
Why?
I am also led to wonder why do we need to build python wheel separately from the C++ build???
I suspect something is afoul in the workflow.
cc: @tt-rkim @afuller-TT @broskoTT

I took @broskoTT's tt-metal branch that had the custom UMD submodule.
I built the wheel locally.
I unzip the whl: unzip metal_libs-0.53.1rc2.dev4+blackhole-cp38-cp38-linux_x86_64.whl
I run ldd, and there is no linkage of uv or nng required:
$ ldd ./ttnn/_ttnn.cpython-38-x86_64-linux-gnu.so
        linux-vdso.so.1 (0x00007ffc6e89b000)
        libc++.so.1 => /lib/x86_64-linux-gnu/libc++.so.1 (0x00007f1f803bb000)
        libc++abi.so.1 => /lib/x86_64-linux-gnu/libc++abi.so.1 (0x00007f1f80384000)
        libunwind.so.1 => /lib/x86_64-linux-gnu/libunwind.so.1 (0x00007f1f80376000)
        libpython3.8.so.1.0 => /lib/x86_64-linux-gnu/libpython3.8.so.1.0 (0x00007f1f7fe20000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1f7fe1a000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1f7fdfe000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1f7fdd9000)
        libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f1f7fdcf000)
        libhwloc.so.15 => /lib/x86_64-linux-gnu/libhwloc.so.15 (0x00007f1f7fd7e000)
        libnuma.so.1 => /lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f1f7fd71000)
        libdevice.so => /home/blozano/tt-metal/TEMP/./ttnn/build/lib/libdevice.so (0x00007f1f7f94b000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1f7f6dd000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1f7f58c000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1f7f567000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1f7f375000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1f82ec7000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f1f7f36b000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f1f7f33d000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f1f7f338000)
        libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f1f7f309000)
        libltdl.so.7 => /lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f1f7f2fe000)
        libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f1f7f2e1000)

You sent me down quite the rabbit hole, Mr. Boss. But I think I have answers for you.
So I downloaded the artifact directly from the workflow, then used patchelf to ensure we weren't linking against anything else spurious on my machine by setting it to only be $ORIGIN/build/lib. This is the intent on user machines, anyway. This step is important, as it bit me later on I realized as my artifact copy was linking against stuff on different places on my machine:
rkim@e12cs07:~/gh-artifacts-logs/12046563342/eager-dist-ubuntu-20.04-grayskull/ttnn$ patchelf --set-rpath '$ORIGIN/build/lib' _ttnn.cpython-38-x86_64-linux-gnu.so

Then I took a look with ldd:
rkim@e12cs07:~/gh-artifacts-logs/12046563342/eager-dist-ubuntu-20.04-grayskull/ttnn$ ldd _ttnn.cpython-38-x86_64-linux-gnu.so
	linux-vdso.so.1 (0x00007ffd4ecbf000)
	libc++.so.1 => /lib/x86_64-linux-gnu/libc++.so.1 (0x00007f46df1fd000)
	libc++abi.so.1 => /lib/x86_64-linux-gnu/libc++abi.so.1 (0x00007f46df1c6000)
	libunwind.so.1 => /lib/x86_64-linux-gnu/libunwind.so.1 (0x00007f46df1b8000)
	libtt_metal.so => /home/rkim/gh-artifacts-logs/12046563342/eager-dist-ubuntu-20.04-grayskull/ttnn/./build/lib/libtt_metal.so (0x00007f46deed5000)
	libpython3.8.so.1.0 => /lib/x86_64-linux-gnu/libpython3.8.so.1.0 (0x00007f46de97f000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f46de979000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f46de95b000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f46de938000)
	libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f46de92e000)
	libhwloc.so.15 => /lib/x86_64-linux-gnu/libhwloc.so.15 (0x00007f46de8dd000)
	libnuma.so.1 => /lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f46de8d0000)
	libdevice.so => /home/rkim/gh-artifacts-logs/12046563342/eager-dist-ubuntu-20.04-grayskull/ttnn/./build/lib/libdevice.so (0x00007f46de508000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f46de324000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f46de1d5000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f46de1ba000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f46ddfc8000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f46e199f000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f46ddfbe000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f46ddf8e000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f46ddf89000)
	libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f46ddf5c000)
	libltdl.so.7 => /lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f46ddf51000)
	libnng.so.1 => not found

Looks like it's looking for libnng (not libuv though, odd). Looking over your logs, it doesn't mention anything about libuv, although that's probably because it just dies upon the first lib it can't find.
Anyway, like you and I suspect, something might be afoul with how we use UMD in the wheel build. I took a look at libdevice.so:
rkim@e12cs07:~/gh-artifacts-logs/12046563342/eager-dist-ubuntu-20.04-grayskull/ttnn$ ldd /home/rkim/gh-artifacts-logs/12046563342/eager-dist-ubuntu-20.04-grayskull/ttnn/./build/lib/libdevice.so
	linux-vdso.so.1 (0x00007ffe64afc000)
	libc++.so.1 => /lib/x86_64-linux-gnu/libc++.so.1 (0x00007f75a3340000)
	libc++abi.so.1 => /lib/x86_64-linux-gnu/libc++abi.so.1 (0x00007f75a3309000)
	libunwind.so.1 => /lib/x86_64-linux-gnu/libunwind.so.1 (0x00007f75a32fb000)
	libhwloc.so.15 => /lib/x86_64-linux-gnu/libhwloc.so.15 (0x00007f75a32aa000)
	libnng.so.1 => not found
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f75a32a0000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f75a327b000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f75a3275000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f75a3093000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f75a2f44000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f75a2f29000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f75a2d37000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f75a3816000)
	libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f75a2d08000)
	libltdl.so.7 => /lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f75a2cfd000)

It's using nng there, but no uv. Which means uv seems to have statically built successfully, but not libnng.so. Not sure what's going on here.
Which brings me to my next point that you brought up:

I am also led to wonder why do we need to build python wheel separately from the C++ build???

We actually don't separate it in this case. There is a separate workflow outside of APC that does the wheel C++ build within the wheel build process, but not in APC. In APC, we take the build artifacts from build-artifact and simply copy it into the wheel. Check out the TT_FROM_PRECOMPILED env var in setup.py.
Anyway, I thought I'd take a look at what's going with the build artifact. I downloaded that and set the rpath as well:
rkim@e12cs07:~/gh-artifacts-logs/12046563342/TTMetal_build_grayskull/ttnn/ttnn$ ldd _ttnn.so
	linux-vdso.so.1 (0x00007fff4c7eb000)
	libc++.so.1 => /lib/x86_64-linux-gnu/libc++.so.1 (0x00007fa6f2bdd000)
	libc++abi.so.1 => /lib/x86_64-linux-gnu/libc++abi.so.1 (0x00007fa6f2ba6000)
	libunwind.so.1 => /lib/x86_64-linux-gnu/libunwind.so.1 (0x00007fa6f2b98000)
	libtt_metal.so => /home/rkim/gh-artifacts-logs/12046563342/TTMetal_build_grayskull/ttnn/ttnn/./../../build/lib/libtt_metal.so (0x00007fa6f28b5000)
	libpython3.8.so.1.0 => /lib/x86_64-linux-gnu/libpython3.8.so.1.0 (0x00007fa6f235f000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa6f2359000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa6f233b000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa6f2318000)
	libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007fa6f230e000)
	libhwloc.so.15 => /lib/x86_64-linux-gnu/libhwloc.so.15 (0x00007fa6f22bd000)
	libnuma.so.1 => /lib/x86_64-linux-gnu/libnuma.so.1 (0x00007fa6f22b0000)
	libdevice.so => /home/rkim/gh-artifacts-logs/12046563342/TTMetal_build_grayskull/ttnn/ttnn/./../../build/lib/libdevice.so (0x00007fa6f1e79000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa6f1c95000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa6f1b46000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa6f1b2b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa6f1939000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fa6f5546000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa6f192f000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fa6f18ff000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fa6f18fa000)
	libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007fa6f18cd000)
	libltdl.so.7 => /lib/x86_64-linux-gnu/libltdl.so.7 (0x00007fa6f18c2000)
	libnng.so.1 => not found

rkim@e12cs07:~/gh-artifacts-logs/12046563342/TTMetal_build_grayskull/ttnn/ttnn$ cd ../../build/lib && ldd libdevice.so
	linux-vdso.so.1 (0x00007ffcd8f8e000)
	libc++.so.1 => /lib/x86_64-linux-gnu/libc++.so.1 (0x00007fb765cf1000)
	libc++abi.so.1 => /lib/x86_64-linux-gnu/libc++abi.so.1 (0x00007fb765cba000)
	libunwind.so.1 => /lib/x86_64-linux-gnu/libunwind.so.1 (0x00007fb765cac000)
	libhwloc.so.15 => /lib/x86_64-linux-gnu/libhwloc.so.15 (0x00007fb765c5b000)
	libnng.so.1 => not found
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb765c51000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb765c2c000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb765c26000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb765a44000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb7658f5000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb7658da000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb7656e8000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb766236000)
	libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007fb7656b9000)
	libltdl.so.7 => /lib/x86_64-linux-gnu/libltdl.so.7 (0x00007fb7656ae000)

Odd, so libdevice.so in the raw build artifact from the C++ build also can't find it. That should then explain why we see this issue in the wheel. But then why don't the non-wheel tests (C++ tests) fail?
Firstly, we still seem to package some .so for libnng:
rkim@e12cs07:~/gh-artifacts-logs/12046563342/TTMetal_build_grayskull/build/lib$ ls -hal | grep nng
-rw-r--r-- 3 rkim rkim 559K Nov 27 08:37 libnng.so
-rw-r--r-- 3 rkim rkim 559K Nov 27 08:37 libnng.so.1
-rw-r--r-- 3 rkim rkim 559K Nov 27 08:37 libnng.so.1.8.0

So it wasn't even statically built. I don't see uv in there. I actually have seen this before when I did some recent work with UMD. For some reason, even if we try statically building with -DBUILD_SHARED_LIBS=OFF or something similar, libnng refuses to listen, and will still produce an .so. I took a quick look at nng's top-level CMakeLists.txt, and nothing looks sussy, but still, it's interesting.
But then that begs the question - how do the other tests work if under normal conditions libdevice.so can't find libnng when you attempt to statically build uv and nng?
I think this is because we set LD_LIBRARY_PATH in the workflow:
rkim@e12cs07:~/gh-artifacts-logs/12046563342/TTMetal_build_grayskull/build/lib$ cat ~/tt-metal/.github/workflows/cpp-post-commit.yaml | grep LD
      LD_LIBRARY_PATH: ${{ github.workspace }}/build/lib

This means we'll always be able to find our libs, even if the libs themselves can't find each other under normal circumstances.
So my conclusion is the following:

We seem to not be able to produce a static build of libnng
This explains why _ttnn in the wheel looks for libnng.so still, because libdevice.so is looking for it
libdevice.so has no RPATH or anything similar set, so if there libraries in build/lib that it uses, it normally can't find them
Although _ttnn has its RPATH set to a path that will eventually find build/lib, libdevice.so does not, and libdevice.so is the one actually trying to find libnng
The non-Docker/non-wheelized tests work because we set LD_LIBRARY_PATH, allowing a final hammer for all libraries to find each other in build/lib

I think I'll leave it up to you for our best way forward. I think a couple of options are:

Try to figure out what's going on libnng and static building. Maybe I'm wrong here and we are producing things properly locally, but something on CI's build-artifact job is messed up?
Perhaps set an RPATH for libdevice.so within the UMD build using $ORIGIN so it can find any missing libs built with CPM in build/lib.

I would personally avoid any further use of LD_LIBRARY_PATH if we can muster it. @TT-billteng 's exact concern was this. We did it before as a hack to make build-artifact possible, but it was always a piece of technical debt. I prefer RPATHs with $ORIGIN in them.

We seem to not be able to produce a static build of libnng
This explains why _ttnn in the wheel looks for libnng.so still, because libdevice.so is looking for it

Here is an isolated build of the UMD branch, note that there is no dynamic linkage required for either nng or uv:
$ cd tt_metal/third_party/umd
$ git checkout brosko/repeat
$ cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release
$ cmake --build build
$ ldd build/lib/libdevice.so
        linux-vdso.so.1 (0x00007fff244b2000)
        libhwloc.so.15 => /lib/x86_64-linux-gnu/libhwloc.so.15 (0x00007f57ba7e9000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f57ba7df000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f57ba7bc000)
        libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f57ba79f000)
        libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f57ba795000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f57ba78f000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f57ba51f000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f57ba3d0000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f57ba3ab000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f57ba1b9000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f57bac87000)
        libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f57ba18c000)
        libltdl.so.7 => /lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f57ba181000)

Note that we can grep for nng and uv symbols in the library as well, meaning it was successfully statically linked:
$ nm -D build/lib/libdevice.so | grep nng_recv
00000000001a6660 T nng_recv
00000000001a69d0 T nng_recv_aio
00000000001a6750 T nng_recvmsg

$ nm -D build/lib/libdevice.so | grep uv_uptime
00000000001e6a70 T uv_uptime

libdevice.so has no RPATH or anything similar set, so if there libraries in build/lib that it uses, it normally can't find them
This is irrelevant if you are static linking

There is something broken here, and I'm pretty sure its the infrastructure.
Your investigation leads me to wonder if we are bringing in stale files from a .cpmcache
What leads me to this suspicion is that the nng library's CMakeLists.txt uses the target name nng no matter if it was built as shared or static. So if there are stale files around, and the .cpmcache is not refreshed, UMD might happily link against the shared version.

This may be currently intended, but this line:
https://github.com/tenstorrent/tt-metal/blob/5af64271f243af41da88457cdd4a659553a6af72/.gitignore#L132
Prevents git clean -xffd from removing the directory.

Didn't read the whole thing yet, but I'm leaning towards hiding libuv and nng behind a SIMULATOR build flag for the simulation flow to avoid this completely for now @vtangTT
We can re-visit this when the multi-host/galaxy work goes into production
And go eat some turkey @blozano-tt 🦃  jeez

@tt-rkim @TT-billteng
I figured this out.
The problem is that we use the CMake customary cache variable "BUILD_SHARED_LIBS" to determine if we should build our libraries as static or shared.
https://github.com/tenstorrent/tt-metal/blob/ab3dc0c4f5c3ce9722261c878970bfa92a212fc9/cmake/project_options.cmake#L10
This variable globally impacts all of the dependencies we bring in through CPM, including those brought in by UMD's CPM. So if it is set, then nng ends up being a shared library.
The quick hack to fix this for my current situation is:
https://github.com/tenstorrent/tt-umd/commit/aa74c4dfc9ab907c1941e40e0cd55afff9ac87a7
I am currently not sure what the right thing to do is for the project.
We don't really want BUILD_SHARED_LIBS to globally impact our dependencies.
Maybe we should have something like METALIUM_BUILD_SHARED_LIBS as a project option, and then set BUILD_SHARED_LIBS
cc: @afuller-TT @broskoTT


Move render method from Document to Node

Resolves #16

@Lukas-Stuehrk I ended up needing this for work on https://github.com/SwiftDocOrg/swift-doc, so I decided to implement this myself really quick.


Add pid locking for premis files

https://jira.lib.unc.edu/browse/BXC-2623

I forgot to open this pr last week.  I do have some questions.
How can I reuse the pid locking code without duplicating it or creating a circular dependency between the fcrepo-clients and persistence packages?
The only other external binary log or metadata file I was able to find was the datastream history log in the persistence package which already had pid locking.  Are there any others that I missed?
I wasn't sure how to test these changes.  Is there a good way to test pid locking?

How can I reuse the pid locking code without duplicating it or creating a circular dependency between the fcrepo-clients and persistence packages?
The approach you've taken of moving the PidLockManager up to the fcrepo-clients module is good, you can remove the instances of it in persistence. You can see that we've needed to do that with a few other things with all the interfaces in fcrepo-clients in edu.unc.lib.dl.persist.api packages. You could add this class to that package. After the 5.0 release I want to revisit our modules to refocus them and to split interfaces from implementations.

The only other external binary log or metadata file I was able to find was the datastream history log in the persistence package which already had pid locking. Are there any others that I missed?

Since it seems like MODS and its history are already covered, I think that is all of them that can be modified at the moment. There are other datastreams, like FITS and the original file, but they are only updated during creation at the moment.

I wasn't sure how to test these changes. Is there a good way to test pid locking?
You could test for it with the PREMIS logger by performing concurrent modifications to the log and verifying that all the changes make it into the final version. Here's a recent example of doing something like this (the generating threads, starting them all at once, joining, etc) https://github.com/UNC-Libraries/fedora-repair-siblings/blob/main/src/test/java/edu/unc/lib/fedora/repairsiblings/RepairIT.java#L166
Try the test without your changes as well to verify that its making a difference.


psnr

I can't measure the PSNR in the paper with this code, and the PSNR in Bicubic is also different from that in the paper. Can you give me some comments@tegg89

Is there anyone who get the psnr result. The calculation is for a whole image instead of sub_image? How to calculate the PSNR when images and label aren't in same shape?

I can't measure the PSNR in the paper with this code, and the PSNR in Bicubic is also different from that in the paper. Can you give me some comments@tegg89

@zhaoyucong I tried the function below for calculating psnr, although visually I can see that srcnn is better, but psnr values are lower for srcnn as compared to bicubic
def psnr(img1, img2):
mse = numpy.mean( (img1 - img2) ** 2 )
if mse == 0:
return 100
PIXEL_MAX = 255.0
return 20 * math.log10(PIXEL_MAX / math.sqrt(mse))

Is there anyone who get the psnr result. The calculation is for a whole image instead of sub_image? How to calculate the PSNR when images and label aren't in same shape?

@IronLavender If you carefully check the image and label, you can basically see that if you crop the image, with padding as defined, you get one to one comparison with label

The key point is that you should use the imresize of MatLab as the paper said both for training and testing. Good luck!

The key point is that you should use the imresize of MatLab as the paper said both for training and testing. Good luck!

if you use train_data(bicubic patches sequence nx31x31) and train_label(ground truth sequence: nx21x21) calculate PSNR, first you should make them have the same size, second you should calculate as 20 * math.log10(1.0 / math.sqrt(mse)), because they have been normalized already.


FR: 【Line Break at Document End】Add two line breaks

Is Your Feature Request Related to a Problem? Please Describe.
In obsidian, The content of the two newline breaks  is a block. When I continue to write at the end of the document, it means that I am adding a new block.

Hey @irrealizable , could you explain a little more what you mean by your statement? Are you saying that you want an exception to Line Break at Document End where it will not affect 2 lines in a row at the end of the document?

It has been several days and I have not heard back. I will give this a about a week more before closing it if I do not hear back on this.

It has been several days and I have not heard back. I will give this a about a week more before closing it if I do not hear back on this.

no, I mean 【Line Break at Document End】 guarantees a blank line at the end of the document, but I want two blank lines at the end of the document

Interesting. I am not sure if this is something that will be added to the Linter, but I am not going to just reject this outright. If there is a desire for the ability to set the amount of blank lines to have at the end of a file, it should not be too hard to add.

Hey @calmwaves111 , have you tried enforcing this using Custom Replace? Using regex should handle exactly what you are referring to here.

Hey @calmwaves111 , have you tried enforcing this using Custom Replace? Using regex should handle exactly what you are referring to here.嘿，您是否尝试过使用自定义替换来强制执行此操作？使用正则表达式应该可以准确处理您在这里所指的内容。

You're right, I didn't expect that
Here are my configurations, hoping to help like-minded people


Calling DotStar.Show() eventually causes strange issues

I am running a for loop inside a task (also tried dispatchertimer and threadpooltimer) to create an animated sequence. At the end of the setpixel loop I call .show().  It all works fine however if it runs for a few seconds I get strange issues happening in my app.  For example I have a looping sound playing. It will stop abruptly. Additionally I am using a few GPIO pins to detect button presses. Those also stop working.  I have confirmed that if I comment out the .Show() method everything works.
Too many calls to .Show() make things stop working in my app. There are no errors and the light strip keeps functioning. What is happening here?

Trying to provide better information. Here is a pretty simple example of what I am doing and the trouble I am having.  After a little bit of time (< 60 seconds ) the looping audio stops playing.  If I comment out the myDotStar.Show(); line the audio loops forever and works properly as intended.  As mentioned above the audio is not the only thing that stops working. My app no longer responds to button input as well at the same time the audio drops out.
Why is calling myDotStar.Show(); causing these strange issues?  I am not seeing errors when it happens. I am not sure how to debug this issue.
If I am using this wrong how would you recommend updating the dotstar?
Thanks!
--- Simple code example that causes my issue ---
public sealed partial class MainPage : Page
{
    public MainPage()
    {
        this.InitializeComponent();

        //Initialize the sotstar
        DotStar myDotStar = new DotStar(144);
        myDotStar.BeginAsync();

        //load a sound and start playing it. It loops forever
        LoadAndPlayAmbientSound();

        //Start a Task to refresh the dotstar at roughly 60 times a second
        UpdateDotStar(myDotStar);
    }

    //Update the dotstar every 16 milliseconds
    private async Task UpdateDotStar(DotStar myDotStar)
    {

        while (true)
        {
            await Task.Delay(16);
            myDotStar.Show();
        }

    }

    //Loads the sound file and then start playing it
    public async void LoadAndPlayAmbientSound()
    {
        StorageFile AmbientSoundFile = await StorageFile.GetFileFromApplicationUriAsync(new Uri("ms-appx:///Assets/test_sound_5.wav"));
        StartAmbientSound(AmbientSoundFile);
    }

    //Start playing the ambient sound. Set it up so it loops on end
    public void StartAmbientSound(StorageFile AmbientSoundFile)
    {
        MediaPlayer AmbientMediaPlayer = new MediaPlayer();
        AmbientMediaPlayer.AutoPlay = false;
        AmbientMediaPlayer.SetFileSource(AmbientSoundFile);
        AmbientMediaPlayer.MediaEnded += AmbientMediaPlayer_MediaEnded;
        AmbientMediaPlayer.Play();

    }

    //Once the sound hits its end... restart the sound at the beginning
    private void AmbientMediaPlayer_MediaEnded(MediaPlayer sender, object args)
    {
        sender.Position = TimeSpan.Zero;
        sender.Play();
    }

}


Review hover style

Probably it should be disabled if the card content is loading?
On facebook, when you hover a card just change the box shadow (a bit). On the other hand, on Twitter, it changes the border color.

Probably it should be disabled if the card content is loading?

Yeah I thought the same, valid points @kikobeats

Kiko Beats<EMAIL_ADDRESS>8 December 2017 at 12:22

Probably it should be disabled if the card content is loading?
On facebook, when you hover a card just change the box shadow (a
bit). On the other hand, on Twitter, it changes the border color.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microlinkhq/react-microlink/issues/31, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFhtm0aGosp5bJAUcwW7nPWKYsiLEWtsks5s-RvngaJpZM4Q69RM.

I also think we should adjust the hover animation in general, the opacity transition is way too harsh atm


Bug report: Exporting a flow with reserved character '>' throws exception

Description
When exporting a flow (in json format mode) with the reserved character > (on windows), the command throws an exception.
Background:
The > character can easily be included in a flow name when a Flow is created without giving it a name in the first place. Power Automate will determine its name, and will include a > character.
Steps to reproduce
Create a flow with a > character in a name.
Export it using:
m365 flow export --id xxxx --environment "Default-xxxx" --packageDisplayName "some-name" --format json

Expected results
The json file is saved on the device.
Actual results
The following error is thrown:
node:fs:585
  handleErrorFromBinding(ctx);
  ^

Error: ENOENT: no such file or directory, open './Button -> Start and wait for an approval.json'
    at Object.openSync (node:fs:585:3)
    at Object.writeFileSync (node:fs:2170:35)
    at C:\Users\MartinLingstuyl\AppData\Roaming\npm\node_modules\@pnp\cli-microsoft365\dist\m365\flow\commands\flow-export.js:123:16
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  errno: -4058,
  syscall: 'open',
  code: 'ENOENT',
  path: './Button -> Start and wait for an approval.json'

Diagnostics
No response
CLI for Microsoft 365 version
5.4.0 (next)
nodejs version
16.15.0
Operating system (environment)
Windows
Shell
PowerShell
cli doctor
No response
Additional Info
No response

I'm willing to work on this one.
I think we can solve this by removing special characters from the file name, in Windows \ / : * ? " < > | are considered special characters. However if we just remove these characters from the file name, a ridiculous Flow name like <>* would still fail because the file name will be empty.
I see 3 possibilities, what do you guys think?

Ignore the ridiculous names and just remove all special characters.
Remove all special characters and create a new name (like flow.json) when the file name is empty.
Replace all special characters by a valid character (like a . or something?).

I'd suggest that we replace special characters with a _, that way we'll avoid empty file names. Would that work?

I think that will work yes! 🙂


Explorer: shows a view header even though just 1 view visible

I was connecting to a docker image:

Is this because the extension host is not ready?

Yes. Because we do not know what views can come from extensions and it relies on last state.


Redux and Sockets

Hi,
I'm new with that technology React-Redux and I would like your help with some implementation.
I want to implement one chat application with sockets (socket.io). First, the user has to sign up ( I use passport in the server side) and after, if the sign up is successful the user has to connect to the webSocket.
I thought that the best will be to use a middleware like a pipe for all the actions and depending of what kind of action gets the middleware, do different things.

If the action type is 'AUTH_USER', create client-server connection and set up all the events which will come from the server.

If the action type is 'MESSAGE' send to the server the message.

Code Snippet:
----- socketMiddleware.js ----
import { AUTH_USER,  MESSAGE } from '../actions/types';

import * as actions from 'actions/socket-actions';

import io from 'socket.io-client';

const socket = null;

export default function ({ dispatch }) {

    return next => action => {

        if(action.type == AUTH_USER) {

            socket = io.connect(`${location.host}`);

            socket.on('message', data => {

               store.dispatch(actions.addResponse(action.data));

            });

        }

        else if(action.type == MESSAGE && socket) {

            socket.emit('user-message', action.data);

            return next(action)

        }

    }

}

------ index.js  -------
import {createStore, applyMiddleware} from 'redux';

import socketMiddleware from './socketMiddleware';

const createStoreWithMiddleware = applyMiddleware(

  socketMiddleware

)(createStore);

const store = createStoreWithMiddleware(reducer);

<Provider store={store}>

    <App />

</Provider>

What do you think about that practise, is it a better implementation?
Kind Regards,
Kevin

This is a usage question, and should really be asked over on Stack Overflow instead of the issues list.
That said, the basic description seems reasonable at first glance.  You may also be interested in looking at some of the existing middleware packages for things like websockets and such - might be useful.  I have a list of middlewares at https://github.com/markerikson/redux-ecosystem-links/blob/master/middleware.md.


[BUG] Blue color doesn't match new logo blue

Describe the bug
Coming from https://github.com/opensearch-project/security-dashboards-plugin/pull/766, the blue in the dashboards color scheme doesn't match the logo blue.
Expected behavior
Same belu.

Hi @dblock  Moved the issue from Dashboard repo, this page is owned under Security plugin.

@mihirsoni @hsiang9431-amzn was saying that this blue comes from dashboards configuration

I believe this is an EUI issue - and should be addressed by an updated theme with the correct color scheme.

We are doing some "spring cleaning in the fall", and to make sure we focus our energies on the right issues and we get a better picture of the state of the repo, we are closing all issues that we are carrying over from the ODFE era (ODFE is no longer supported/maintained, see post here).
If you believe this issue should still be considered for current versions of OpenSearch, apologies! Please let us know by re-opening it.
Thanks!

Thanks, Dave!
@KrooshalUX - let's track this (closed) issue when we do our first pass at an OUI theme

@kgcreative Would you like to reopen this issue so it can be tracked?

@peternied - not yet. We will re-open when we're ready to action on it.


Avoid use of 'sanity' and 'sanity check' in the code base

In line with:
https://source.android.com/setup/contribute/respectful-code
this change uses the terms 'coherence' and 'coherence check' where
'sanity' and 'sanity check' were previously used.

I agree that "coherence-check" is more awkward than "sanity-check"; I had used it because it was the most suitable of the suggested alternatives for "sanity-check".  However I agree that in many cases it is better to just describe the check; no need for "sanity-" or "coherence-" or whatever.
Thanks for the feedback.

@dneto0 I addressed your review feedback in a new PR (as this one had already been merged):
https://github.com/KhronosGroup/SPIRV-Tools/pull/3619


Add support for a body parameter in the config.yml file

Some requests may require a request body, like so:
requests:
  - endpoint: x
    body:
      INPUT: y

Use the following for an integration test:  https://documenter.getpostman.com/view/6065583/RzfmEmUY#87754d4c-3c52-44ac-bb70-a9027d23a02d
This will also require a documentation update to the README.md#Configuration section.

@prestonvasquez I work on this issue.

Closed by #360


Discussing Bootstrapping / error in the Median, skew

I'm not sure whether this is better suited for unit 5 or 6. Since non-Gaussian distributions come up fairly commonly in chemistry (e.g., Boltzmann) I think it's important to emphasize:

you may want to check the skew using scipy.stats.skew
the median may be a better "central metric" than the mean (e.g., income distribution if Jeff Bezos comes into the room)
to estimate the std. dev. of the median, you can't use np.std()
bootstrapping is a nice, simple way to get confidence intervals on median or other properties, e.g.

https://carpentries-incubator.github.io/machine-learning-novice-python/07-bootstrapping/index.html
https://github.com/ghutchis/chem1000/blob/main/lectures/09b-prob-stats.ipynb

I ended up putting it into Unit_07. I remember that when teaching 6 I just had enough material without overrunning, but unit 7 had a bit more breathing time. It fits well well after the plotting distributions recap as well.
Commit 4f8bad5 implements our proposed final version for this. I have not included boostrapping as this is something that is taught in a different course in a later year. The general idea is to avoid teaching concepts in chemistry and programming and tend to rely on the students' knowledge of stats, etc., taught in their first year in a maths course.


Error in dyn.load when running script on the cloud using ubuntu

I explained my issue here:
https://github.com/Azure/AzureStor/issues/112
The maintener suggested I should post issue here.

Is this issue related to Azure CLI?


Support entity fields containing References in SQLite

Diffbase https://github.com/PolymerLabs/arcs/pull/4673
Also fixes a deadlocking bug, where getSchemaTypeId() would lock the mutex and then call getTypeId() which locks the same one.

Presubmit passing cl/295889152


Add remote certifcate monitoring infrastructure to keymasterd.

I've pushed fixed. PTAL.

I would rather not having those folded into the source tree until they
are actually refered by something.
Camilo
On 9/24/17 8:59 PM, rgooch wrote:

@rgooch commented on this pull request.

In lib/constants/constants.go
https://github.com/Symantec/keymaster/pull/85#discussion_r140685252:

@@ -0,0 +1,8 @@
+package constants

+const (

KeymasterAdminPortNumber   = 6920
KeymasterServicePortNumber = 443

CertmonPortNumber = 6921

|CertmonPortNumber| will be used by |keymaster-certmond|, which is
coming in a followup PR. I'll send that once you've added the
|Publish*()| method calls, so I can test.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/Symantec/keymaster/pull/85#discussion_r140685252,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABN2FEZNsIGocFvNN7A13e2lVGEO9_O7ks5slyUagaJpZM4PiJX3.

Sigh. lib/constants removed. PTAL.


Introduce native rpc support for witness generation

Work in progress

Hey @frisitano this is such a useful change, i guess zero-bin would consume any evm based rpc request after ? (geth/erigon)
Is there any part that is blocking the PR, happy to try to contribute

@daniel-bcw That's correct, although initially the code @frisitano migrated isn't fully complete so may fail at generating some blocks, unlike the zero-bin payloads processed from Jerigon.
@frisitano Given that the eth-tx-proof codebase was in a fairly WIP state, I wouldn't expect you to fully clean it up in a single PR, so feel free to drop TODOs wherever you noticed refactor needs, and we can address them as follow up work.

Hey @frisitano this is such a useful change, i guess zero-bin would consume any evm based rpc request after ? (geth/erigon) Is there any part that is blocking the PR, happy to try to contribute

Hey @daniel-bcw, yes that is correct. Following this change zero-bin can target any client that implements the standard RPC API.  Thank you for your offer of support, it's appreciated but no support required at this point in time.  There are no blockers, I am just waiting on direction from repository maintainers on questions around versioning -  you can follow the discussion here https://github.com/0xPolygonZero/zero-bin/issues/33.
As an aside I've just stumbled upon the work your team have done producing helm templates for zero-bin - https://github.com/BCWResearch/zero-bin-bcw/tree/develop/deploy/helm/zero-bin. Would love to talk more about this and explore ways to collaborate. Whats the best way to get in touch?

@daniel-bcw That's correct, although initially the code @frisitano migrated isn't fully complete so may fail at generating some blocks, unlike the zero-bin payloads processed from Jerigon.
@frisitano Given that the eth-tx-proof codebase was in a fairly WIP state, I wouldn't expect you to fully clean it up in a single PR, so feel free to drop TODOs wherever you noticed refactor needs, and we can address them as follow up work.

I used eth-tx-proof as more of a guide rather than migrating actual code. The code in this PR is "new" based on my understanding of the trace protocol by inspecting the zero tracer in jerigon and the zk_evm repo. Do you have any specific insights of what I should double check / test?

@frisitano Probably a good call to move away from it and implement a clean solution directly.
With the test-only feature, we can simulate proofs fairly quickly, so one could easily target a few hundreds of Shanghai blocks with the new native mode you introduced and make sure everything runs smoothly

@frisitano I ran your branch on a 100 random blocks on Ethereum mainnet, between blocks 19240650 and 19240750
34/100 :x:, 66/100 :white_check_mark:

Missing key xxx when creating sub-partial tries (always storage trie): 4
Trie operation error: Found a Hash node during an insert in a PartialTrie! These should not be able to be traversed during an insert!: 15
Failed to get proof for account (missing trie node): 4
Kernel Panic at mpt_read_hash_node: 9
trusted rlp should be valid: RlpExpectedToBeData: 1

I've attached my logs if this helps (though info is minimal as I didn't want them to take hours or clog my disk space).
block_logs.zip

@frisitano I ran your branch on a 100 random blocks on Ethereum mainnet, between blocks 19240650 and 19240750
I got 34/100 ❌, 66/100 ✅

Missing key xxx when creating sub-partial tries (always storage trie): 4
Trie operation error: Found a Hash node during an insert in a PartialTrie! These should not be able to be traversed during an insert!: 15
Failed to get proof for account (missing trie node): 4
Kernel Panic at mpt_read_hash_node: 9
trusted rlp should be valid: RlpExpectedToBeData: 1

I've attached my logs if this helps (though info is minimal as I didn't want them to take hours or clog my disk space).
block_logs.zip

Thank you! I'm working through this now. Out of interest, is there a public RPC endpoint that supports the zeroTracer on ethereum mainnet that I can use for comparison / debugging?

Hmm I don't think there's any public RPC endpoint, as you need to have access to debug_traceTransaction

Hmm I don't think there's any public RPC endpoint, as you need to have access to debug_traceTransaction

I was hoping that someone (potentially within the team) may have synced the jerigon node with Ethereum mainnet such that we could use the zero tracer to produce traces and prove blocks which are failing using the native tracer. This would give us confidence that it is in fact the trace generation and not some issue within the zk_evm.
I've fixed one of the issues which was related to empty storage tries, however I'm still experiencing more issues.
Something I'm a little confused about when inspecting logs for the following transaction.
In the logs we can see the following:
2024-04-24T16:20:48.247562Z DEBUG evm_arithmetization::witness::transition: Cycle 348312, ctx=1, pc=mpt_read_state_trie, instruction=Push(1), stack=[844935717204094928098547272543109538884590266852, 4691,<PHONE_NUMBER>04094928098547272543109538884590266852, 9100, 1, 1,<PHONE_NUMBER>04094928098547272543109538884590266852, 4323,<PHONE_NUMBER>561266838347921199117367450816737848457277449313465846,<PHONE_NUMBER>00000]

which suggests (from my understanding of the kernel) we are trying to read the account data for account<PHONE_NUMBER>04094928098547272543109538884590266852 (0x94003a59f4172db0079f0f0ca50d69796b3469e4). When I look at the transaction traces (both prestateTracer and callTracer) there are no references of this account except for the address being a storage value, which is read, associated with contract 0x2ec705d306b51e486b1bc0d6ebee708e0661add1.
            "storage": {
                "0x0000000000000000000000000000000000000000000000000000000000000000": "0x00000000000000000000000094003a59f4172db0079f0f0ca50d69796b3469e4"
            }

So I've been investigating this issue and I suspect the following is happening. When the call to the 0x94003a59f4172db0079f0f0ca50d69796b3469e4 address is made gas is exhausted and the transaction terminates.
If we look at the sys_call kernel method seen below we can see that the invocation of the %insert_accessed_addresses method takes place before the %call_charge_gas method. Therefore the kernel believes that we have accessed this address when in fact we have not because the transaction failed due to exhausting gas.
// Creates a new sub context and executes the code of the given account.
global sys_call:
    // Check that the value is zero if the context is static.
    // stack: kexit_info, gas, address, value, args_offset, args_size, ret_offset, ret_size
    DUP4 ISZERO %not_bit
    // stack: value≠0, kexit_info, gas, address, value, args_offset, args_size, ret_offset, ret_size
    %mload_context_metadata(@CTX_METADATA_STATIC)
    // stack: is_static, value≠0, kexit_info, gas, address, value, args_offset, args_size, ret_offset, ret_size
    MUL // Cheaper than AND
    %jumpi(fault_exception)

    %stack (kexit_info, gas, address, value, args_offset, args_size, ret_offset, ret_size) ->
        (args_size, args_offset, kexit_info, gas, address, value, args_offset, args_size, ret_offset, ret_size)
    %checked_mem_expansion
    %stack (kexit_info, gas, address, value, args_offset, args_size, ret_offset, ret_size) ->
        (ret_size, ret_offset, kexit_info, gas, address, value, args_offset, args_size, ret_offset, ret_size)
    %checked_mem_expansion

    SWAP2
    // stack: address, gas, kexit_info, value, args_offset, args_size, ret_offset, ret_size
    %u256_to_addr // Truncate to 160 bits
    DUP1 %insert_accessed_addresses

    %call_charge_gas(1, 1)
    %check_depth

...

Relevant logs:
2024-04-24T16:20:48.245978Z TRACE evm_arithmetization::witness::transition: Cycle 348113, ctx=1, pc=8876, below sys_gas, instruction=Swap(0), stack=[4323,<PHONE_NUMBER>222800136438331725559348284776481959846117363031225845,<PHONE_NUMBER>04094928098547272543109538884590266852,<PHONE_NUMBER>00000, 1175, 0, 1175, 0, 1175,<PHONE_NUMBER>00000]
2024-04-24T16:20:48.245986Z TRACE evm_arithmetization::witness::transition: Cycle 348114, ctx=1, pc=8877, below sys_gas, instruction=ExitKernel, stack=[1141283806222800136438331725559348284776481959846117363031225845, 4323,<PHONE_NUMBER>04094928098547272543109538884590266852,<PHONE_NUMBER>00000, 1175, 0, 1175, 0, 1175,<PHONE_NUMBER>00000]
2024-04-24T16:20:48.245992Z DEBUG evm_arithmetization::witness::operation: Exiting to 13813, is_kernel=false
2024-04-24T16:20:48.245995Z DEBUG evm_arithmetization::cpu::kernel::interpreter: User instruction: Syscall(241, 7, false)
2024-04-24T16:20:48.245998Z DEBUG evm_arithmetization::witness::operation: Syscall to sys_call
2024-04-24T16:20:48.246002Z DEBUG evm_arithmetization::witness::transition: Cycle 348116, ctx=1, pc=sys_call, instruction=Dup(3), stack=[1141283806222800136438331725559348284776481959846117363031225846, 4323,<PHONE_NUMBER>04094928098547272543109538884590266852,<PHONE_NUMBER>00000, 1175, 0, 1175, 0, 1175,<PHONE_NUMBER>00000]
2024-04-24T16:20:48.246009Z TRACE evm_arithmetization::witness::transition: Cycle 348117, ctx=1, pc=1107, below sys_call, instruction=Iszero, stack=[240000000000000,<PHONE_NUMBER>222800136438331725559348284776481959846117363031225846, 4323,<PHONE_NUMBER>04094928098547272543109538884590266852,<PHONE_NUMBER>00000, 1175, 0, 1175, 0, 1175]
2024-04-24T16:20:48.246017Z TRACE evm_arithmetization::witness::transition: Cycle 348118, ctx=1, pc=1108, below sys_call, instruction=Iszero, stack=[0,<PHONE_NUMBER>222800136438331725559348284776481959846117363031225846, 4323,<PHONE_NUMBER>04094928098547272543109538884590266852,<PHONE_NUMBER>00000, 1175, 0, 1175, 0, 1175]
2024-04-24T16:20:48.246024Z TRACE evm_arithmetization::witness::transition: Cycle 348119, ctx=1, pc=1109, below sys_call, instruction=Push(5), stack=[1,<PHONE_NUMBER>222800136438331725559348284776481959846117363031225846, 4323,<PHONE_NUMBER>04094928098547272543109538884590266852,<PHONE_NUMBER>00000, 1175, 0, 1175, 0, 1175]
2024-04-24T16:20:48.246031Z TRACE evm_arithmetization::witness::transition: Cycle 348120, ctx=1, pc=1115, below sys_call, instruction=GetContext, stack=[25769803784, 1,<PHONE_NUMBER>222800136438331725559348284776481959846117363031225846, 4323,<PHONE_NUMBER>04094928098547272543109538884590266852,<PHONE_NUMBER>00000, 1175, 0, 1175, 0]

This is based on my limited understanding of the kernal so I may be wrong.

Similar situation with the following transaction - relating to a sys_call invocation which fails:

https://etherscan.io/tx/0x306268fd34fc9cf8b2003405d25c7ff41eb5933cb0579c1b55c785864ad3a217

Closing as replaced by #81.


these items in the changelog for 1.36 are not listed in the documention

when reading:
http://rclone.org/changelog/
I see:
rclone check: Add --download flag to check all the data, not just hashes
rclone cat: add --head, --tail, --offset, --count and --discard
Then I go to:
http://rclone.org/docs/
and I see no explanation of these new commands/flags
I could guess about them, but ideally I think they should be given a write-up? if --download does what I think it does, it's going to be very useful for me, and help solve an issue I've had in the past, that I've been handling manually.

You can find docs for the cat command here
http://rclone.org/commands/rclone_cat/
And check here
http://rclone.org/commands/rclone_check/


[Feature request] Ability to generate new demos through URL parameters

With JSBin, it's possible to dynamically generate new demos, for example with:
http://jsbin.com/?html,js,output&html=foo&js=bar
That creates a demo with panes for HTML, JS, and HTML output, with foo as the initial HTML content and bar as the initial JS content. This is incredibly useful in blog posts and other educational materials, as it's possible to make all code examples automatically link to always up-to-date live demos.

I think somebody else suggested something similar. It is a really good feature :)


Work with map team to place enemies on the map

Description
Task: Work with map team to place enemies on the map
Feature: Sprint 3 Enemies
Work with map team to place enemies on the map.
Milestones
List of steps that need to be completed for this task.

[ ] Decide where enemies will go on the map.
[ ] Place enemies on the map.
[ ] Document on wiki
[ ] Write JUnit tests.

Completion Deadline: Sprint 3 Deadline
Documentation

Enemies Feature Page

Member

Caitlenn Alsop (c-alsop) (slack: Caitlenn Alsop)

@bach-truong just thought i'd throw in my 2 cents here. Think it would make sense to spawn the weakest enemy first (make there a few of them) - the melee only enemies (gymbro).

I think if you were to spawn the boss at the same time it would be too challenging and potentially confusing.

My team was planning to do that as well. Now it's just showing that the Boss existed for sake of grading. But we'll work on how to spawn enemies properly with team Map.

Hey Team 5 (Map team), do you guys have any plan on configuring the map so that we can spawn it on a specific area?

Hey Team 5 (Map team), do you guys have any plan on configuring the map so that we can spawn it on a specific area?

This would definitely be ideal. We need to get the spawn locations in by end of sprint. I guess waiting on map team to update implementation for now.

Hey Team 5 (Map team), do you guys have any plan on configuring the map so that we can spawn it on a specific area?

This would definitely be ideal. We need to get the spawn locations in by end of sprint. I guess waiting on map team to update implementation for now.
Hey there, Yes, we can give specific coordinates that can be used to spawn the Entities at, that should suffice in deploying them at a particular location

Hi, the level 2 enemies (basic poop enemy, mega poop boss) are on the underground map now and they have also been removed from the level 1 map

Hey Team 5 (Map team), do you guys have any plan on configuring the map so that we can spawn it on a specific area?

This would definitely be ideal. We need to get the spawn locations in by end of sprint. I guess waiting on map team to update implementation for now.

Hey there, Yes, we can give specific coordinates that can be used to spawn the Entities at, that should suffice in deploying them at a particular location

Hi, the level 2 enemies (basic poop enemy, mega poop boss) are on the underground map now and they have also been removed from the level 1 map

Hey Everyone, I've provided a miro board that displays a bunch of coordinates across the map that should help you in the placements of your entities, thanks for already getting on with the transition!
https://miro.com/app/board/uXjVPRET2Lo=/?share_link_id=131599096866


TextField does not work with multiple Navigator

Steps to Reproduce

Tap the TextField and enter text.
Change tab to Right
Tap the TextField and enter text.
Change tab to Left
Tap the TextField

Android sim: Keyboard does not open, text selection works.
iOS sim: Can not focus to the TextField.

import 'package:flutter/material.dart';
import 'package:flutter/cupertino.dart';

void main() {
  runApp(new MaterialApp(
    home: new CupertinoTabScaffold(
      tabBar: new CupertinoTabBar(
        items: <BottomNavigationBarItem>[
          new BottomNavigationBarItem(
            icon: new Icon(Icons.directions_car),
            title: new Text('Left'),
          ),
          new BottomNavigationBarItem(
            icon: new Icon(Icons.directions_railway),
            title: new Text('Right'),
          ),
        ],
      ),
      tabBuilder: (BuildContext context, int index) {
        return new MaterialApp(
          home: new Scaffold(
            appBar: new AppBar(
              title: new Text(index == 0 ? 'Left' : 'Right'),
            ),
            body: new Container(
              child: new TextField(),
            ),
          ),
        );
      },
    ),
  ));
}

When using CupertinoTabBar and BottomNavigationBar, multiple Navigators often required for each tabs to push pages.
In the example, I use MaterialApp because it includes Navigator.
Logs
No exception.
Flutter Doctor
[✓] Flutter (on Mac OS X 10.12.6 16G29, locale ja-JP, channel master)
    • Flutter at /Applications/flutter
    • Framework revision 7bfa3c5676 (31 hours ago), 2017-10-02 17:32:00 -0700
    • Engine revision e3404b81a5
    • Tools Dart version 1.25.0-dev.11.0

[✓] Android toolchain - develop for Android devices (Android SDK 26.0.1)
    • Android SDK at /Users/najeira/Library/Android/sdk
    • Platform android-26, build-tools 26.0.1
    • ANDROID_HOME = /Users/najeira/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_112-release-b06)

[✓] iOS toolchain - develop for iOS devices (Xcode 9.0)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 9.0, Build version 9A235
    • ios-deploy 1.9.2
    • CocoaPods version 1.2.1

[✓] Android Studio (version 2.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Java version OpenJDK Runtime Environment (build 1.8.0_112-release-b06)

[✓] IntelliJ IDEA Ultimate Edition (version 2017.2.1)
    • Flutter plugin version 16.0
    • Dart plugin version 172.3544.34

How about this issue now?

The issue is observed in the focus node mechanism. Though I have no solution currently.
@pedia, did you notice other navigation issues or is it text input related as well?

@xster I am not sure.
I have tried saving all FocusNode, and call
FocusScope.of(context).requestFocus();

got:
When the exception was thrown, this was the stack:
#2      FocusScopeNode._setFocus (package:flutter/src/widgets/focus_manager.dart:289:12)
#3      FocusScopeNode.requestFocus (package:flutter/src/widgets/focus_manager.dart:253:5)
#4      FocusM.onChange (/Users/odd/wa/flutter/offer/lib/t.dart:35:35)
#5      FocusWrap.onChange (/Users/odd/wa/flutter/offer/lib/t.dart:19:12)
#6      ChangeNotifier.notifyListeners (package:flutter/src/foundation/change_notifier.dart:140:21)
#7      FocusNode._notify (package:flutter/src/widgets/focus_manager.dart:103:5)
#8      FocusManager._update (package:flutter/src/widgets/focus_manager.dart:450:20)
(elided 4 frames from class _AssertionError and package dart:async)

Yes, it's the same issue as the text input focus

Fix is on the way
Small note: @najeira, you can use a CupertinoTabView instead of putting a whole MaterialApp inside of each tabBuilder

@xster The unmerged PR worked for me.

Will this PR be merged?


[SD CHANGE] Type 4 Hypothesis

On behalf of the CCCS
SD page 74 para 333 A.1.4 Type 4 Hypothesis based on fuzz testing a network interface is not applicable to most TOE types in this cPP, essentially resulting in testing the underlying OS instead of the TOE. An alternative Type 4 proposal is included in a separate document.
SWcPP - tool generated hypotheses.docx

Reviewed the recommendations and decided to adopt the Vulnerability Scanning option. The other methods were considered either not feasible (e.g. static code analysis would require access to source code) or of limited value (e.g. fuzz testing).

Note for iTC:
Update Type 4 hypothesis as follows:
Automated vulnerability scanning is a method where a specialized tool is applied to a specific attack surface in order to test it for the presence of known types of vulnerabilities. If this approach is technically feasible, the expectation is that the vulnerability scanning is conducted by the evaluator within a controlled test environment. The evaluator must ensure that the TOE is directly reachable and there is no network traffic filtering device, like a firewall, between the scanner and the TOE.
Vulnerability scanners are known to produce recommendations for hardening along with possible vulnerabilities. There is no expectation that all recommendations produced by such tool must be implemented. However, each reported vulnerability must be investigated and resolved or classified as a false positive.

Incorporated into SD


[fs] polling_interval config should be milliseconds not microseconds

regression from this commit https://github.com/php-enqueue/fs/commit/c5199ca5bac5c661aed86d6b2f751630af42378d
config should be milliseconds like in docs stated.....$this->pollingInterval is holding milliseconds which is correct.
But usleep is using microseconds. To fix it just convert milliseconds to microseconds

@makasim

ups sorry wrong repo


Blog returns wrong date when using YYYY/MM/DD format

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Prerequisites

[X] I'm using the latest version of Docusaurus.
[ ] I have tried the npm run clear or yarn clear command.
[ ] I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
[ ] I have tried creating a repro with https://new.docusaurus.io.
[ ] I have read the console error message carefully (if applicable).

Description
Typing in a date with YYYY/MM/DD format returns wrong date, which is displaying the previous date.
---
date: 2021/08/01
---

shown as:
July 31, 2021
Steps to reproduce

Expected behavior
N/A
Actual behavior
N/A
Your environment

Public source code:
Public site URL:
Docusaurus version used:
Environment name and version (e.g. Chrome 89, Node.js 16.4):
Operating system and version (e.g. Ubuntu 20.04.2 LTS):

Reproducible demo
No response
Self-service

[ ] I'd be willing to fix this bug myself.

Hi, fixed in #6244. Please test with canary release

Hi, fixed in #6244. Please test with canary release

Canary works for me.
But there is an issue if you want to use the date from the folder name.   Try a folder name of "2021-08-19-Hello" ... fails when you do  npm start  - you cannot access the main Blog screen (errors in the Browser console).   But works if you build the site.

Could you open another issue @markharrison? Your problem seems unrelated to the current one since you are actually using dates within file path.


bug: TransactionId is 0 on operation error

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
When invoking an operation that has no handler, TransactionId is set to 0. This violates the uniqueness of TransactionId for a provider, it is simply a transaction that terminates with an error.
https://github.com/Draegerwerk/sdc11073/blob/48cb62b324513c764dde336bd10355f429acad17/src/sdc11073/provider/porttypes/porttypebase.py#L175C58-L175C58
Expected Behavior
Be unique.
Minimal Reproducible Example
No response
Solution proposal
No response
Python Version
any
Operating system
any
Sdc11073 Version
48cb62b324513c764dde336bd10355f429acad17
Link to sdc11073 Logs
No response
Further Information
No response
Participation

[ ] I am willing to submit a pull request to fix this bug.

Fixed by #207 in v2


STAT Support in DoD

Is your feature request related to a problem? Please describe.
I've tried to incoporate into an existing IL4/5 (DoD) environment and having issues with API's. I've been able to solution a significant amount of issues but the 'RelatedAlerts' module continues to give me issues with HTTP requests.
Describe the solution you'd like
I would like to request a proper ARM template deployment for STAT in DoD.
Describe alternatives you've considered
I've been able to solution a significant amount of API with updating approved API versions (management.azure.com, https://api.loganalytics.io, and https://graph.microsoft.com/v1.0) but some issues /errors (404) I cannot troubleshoot.
Additional context
Add any other context or screenshots about the feature request here.

This always returns a subscriptions not found 404 error but the subscription ID is 100% correct from the Parse JSON results.

@brandonconn03 when you ran into this error had you changed the endpoint in the screenshot to management.usgovcloudapi.net or was it using management.azure.com?  Can you provide the details from the error in the failed run of the logic app (please feel free to redact any identifying details of course)?
We have only tested STAT to date in Commercial Azure paired with Commercial Office 365 and Commercial Azure paired with GCC Medium Office 365.  In your case you are using Azure Gov in one of the DoD regions and Office 365 in GCC DoD?

@briandelmsft I apologize for my delayed response as I have been TDY.
I was using management.azure.com and not management.usgovcloudapi.net. I can test with the usgovcloudapi URL to see if that changes anything.
Yes, I am using Azure Gov in one of the USGov regions and Office 365 in GCC DoD as the office data connectors are not supported in USGov.

Thank you for the information @briandelmsft ! I'll take a look :) If I have any breakthroughs on the API I'll be sure to pass along.

@brandonconn03 were you able to give the new version of STAT a try? Like @briandelmsft mentionned, since you can customize URLS for all services, it should address your challenges.


Adding the correct number type when parsing data

Fixes: #1512
Fixes: #1513
It appeared to me that when you blank the technical_lifetime the technical_lifetime got saved to the database as '' and not as  .

It seems that numeric values are being saved to the asset list as strings. I'm guessing this wasn't intentional?
Before:
---
- pressure_level_index: 0
  part: pipes
  type: pe_lp
  units: 9281.578154828
  stakeholder: system operator
  building_year: 1960
  technical_lifetime: 45
  initial_investment: 130
  yearly_o_and_m_cost: 1

After:
---
- pressure_level_index: '0'
  part: pipes
  type: pe_lp
  units: '9281.578154828'
  stakeholder: system operator
  building_year: '1960'
  technical_lifetime: '45'
  initial_investment: '130'
  yearly_o_and_m_cost: '1.1'

Also, updating a LES topology is returning an error due to an units input being blank:

Graph may not have a non-numeric "units" attribute.

I wouldn't object to defaulting topology nodes to have an explicit units value of 1, and showing a validation error if the user deletes the value. However I think this change in behaviour also wan't intentional?

I'm guessing this wasn't intentional?

No, it's even a bit odd looking at it. 🤔  I explicitly parse the numbers to floats or integers and than save the result. I think I might know what this could be though.

I wouldn't object to defaulting topology nodes to have an explicit units value of 1, and showing a validation error if the user deletes the value. However I think this change in behaviour also wan't intentional?

No, this wasn't intentional aswell. The thing is that units probably got saved as '' being parsed as 0 because ''.to_i == 0. I'll take a look at this aswell.

@antw

It seems that numeric values are being saved to the asset list as strings.

Turns out $.trim turns an integer or float back again to a string 😅

Graph may not have a non-numeric "units" attribute.

This was because I changed the from data('type') to data('dataType) and forgot to rename the topology form 😶

@antw if you could take a look.

pressure_level_index is still being cast to a string in the DB when previously it was an int, but otherwise everything else looks good.

Ahh... I spoke too soon. Strings with spaces in them – such as "system operator" and "heat producer" stakeholders – seem to have the spaces removed:
# Heat source list stakeholder:

- key: central_heat_network_dispatchable
  heat_capacity: 10.660117200536018
  units: 1
  stakeholder: heatproducer # <-----
  total_initial_investment: 100
  technical_lifetime: 30
  om_costs_per_year: 2
  marginal_heat_costs: 0.022
  distance: 1
  priority: '1'

# Gas asset list stakeholder

---
- pressure_level_index: '0'
  part: pipes
  type: pe_lp
  units: 9281.578154829
  stakeholder: systemoperator # <-----
  building_year: 1960
  technical_lifetime: 45
  initial_investment: 130
  yearly_o_and_m_cost: 1.1

stakeholder: systemoperator # <-----

This was due to [\'\" ] instead of the correct one: [\"\']. I don't know how that extra space got in there.
The pressure_level_index missed a type, I checked and the priority of the dispatchable heat source table were also saved as strings which should have been integers, and the demand of the technology_profile_matrix was an integer which should have been a float.
I also noticed that dispatchable is being saved as en empty string with must run heat sources but I'm not sure why this is again. 🤔

This looks good. :+1:
@grdw Could you look into the merge conflict when you have a moment? The master branch has changes to save_all.js: function change(e), but this PR removes that function entirely.
As soon as that's taken care of this can be merged (you're welcome to do it yourself if you wish).

you're welcome to do it yourself if you wish

I had to make a minor change to the technologies form to detect that someone selected a new csv but that's been taken care off. I'll merge this personally.


Some of FineTuning has this error

I've managed to create a few models now using FT but on some of my datasets I get this error :
(styletts) root@DESKTOP-G461NBO:/mnt/h/StyleTTS23# accelerate launch --mixed_precision=fp16 --num_processes=1 train_finetune_accelerate.py --config_path ./Configs/config_ftadam.yml The following values were not passed to accelerate launchand had defaults used instead:        --num_machineswas set to a value of1 --dynamo_backendwas set to a value of'no'To avoid this warning pass in values for each of the problematic parameters or runaccelerate config`.
Some weights of the model checkpoint at microsoft/wavlm-base-plus were not used when initializing WavLMModel: ['encoder.pos_conv_embed.conv.weight_v', 'encoder.pos_conv_embed.conv.weight_g']

This IS expected if you are initializing WavLMModel from the checkpoint of a model trained on another task or with another architecture (e.g. initializing a BertForSequenceClassification model from a BertForPreTraining model).
This IS NOT expected if you are initializing WavLMModel from the checkpoint of a model that you expect to be exactly identical (initializing a BertForSequenceClassification model from a BertForSequenceClassification model).
 Kernel size: (5 x 5). Kernel size can't be greater than actual input size
Traceback (most recent call last):
File "/root/anaconda3/envs/styletts/bin/accelerate", line 8, in
sys.exit(main())
File "/root/anaconda3/envs/styletts/lib/python3.8/site-packages/accelerate/commands/accelerate_cli.py", line 47, in main
args.func(args)
File "/root/anaconda3/envs/styletts/lib/python3.8/site-packages/accelerate/commands/launch.py", line 1017, in launch_command
simple_launcher(args)
File "/root/anaconda3/envs/styletts/lib/python3.8/site-packages/accelerate/commands/launch.py", line 637, in simple_launcher
raise subprocess.CalledProcessError(returncode=process.returncode, cmd=cmd)
subprocess.CalledProcessError: Command '['/root/anaconda3/envs/styletts/bin/python', 'train_finetune_accelerate.py', '--config_path', './Configs/config_ftadam.yml']' returned non-zero exit status 1.
(styletts) root@DESKTOP-G461NBO:/mnt/h/StyleTTS23#`

Win11 WSL anaconda

Check out the "Errors, Crashes" section here: https://github.com/yl4579/StyleTTS2/discussions/81

Yes you was right, it was too short some of the audio.

I'm using the LJSpeech dataset -- should i go ahead manually checking the length of the audio files. Is there a better way to do that?

I'm using the LJSpeech dataset -- should i go ahead manually checking the length of the audio files. Is there a better way to do that?

you can write a script that would check those wavs durations and remove all those less than 1 second in length... on Linux, you can use soxi for that, on Windows ffprobe
I have used this script with Windows PowerShell (you'll need to have all WAV files and ffprobe.exe file in a single folder):
Get-ChildItem -Exclude ffprobe.exe | ForEach-Object { if ($_.Extension -eq ".wav" -and (.\ffprobe.exe -i $_.FullName -show_entries format=duration -v quiet -of csv="p=0") -lt 1) { Remove-Item $_.FullName -Force } }

Got it! thanks for this