What EMA is the right EMA?

@twopirllc and @DaveSkender
I wanted to hear your opinion on how to start the EMA sequence - assuming we don't want to just hide the first n results with NaNs and hope that the sequence will converge sooner than later.
I wrote a short EMA study to document my thinking, but in a nutshell:

calculating SMA for the first period bars - and then switching to EMA - just feels horribly wrong. Transition from SMA to EMA is unnatural and breaks the continuity. Bad option.
assuming that the previous phantom EMA value was 0 (prev_ema = 0) and calculate EMA that way generates undershooting EMA, requiring long sequence to converge to the real EMA
assuming that the previous phantom EMA value was the same as the first value (prev_ema = data[0]) generates overshooting EMA, also requires long sequence to converge to the real EMA

There is a method from digital signal processing that can adjust outputs with diminishing attenuation, generating an EMA line that seemingly converges to the real EMA within very samples.
I took a hint from David Owen's blog and created a new 'Fast-convering EMA' (you can see the algo in the EMA study).

Blue line: input data signal {1, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0}
Upper red line: overshooting EMA(p) (assumes that prev_ema = data[0])
Lower red line: undershooting EMA(p) (assumes that prev_ema = 0)
Green Line: SMA(p) followed by EMA(p) - this is the accepted norm
Purple Line: Attenuated, fast-converging EMA(p)

First pic is for p=5, second one is for p=12

I think there's a whole lot of overfittings scenarios where you can make one of these methods look better than the other.
The only ideal initial value that would decrease convergence time is one that is closest to the unknown actual EMA value -- something you can only get if you have more history.  It's a catch-22.  Any "shoot for the middle" approach, like SMA is probably as good as any IMO since you really don't know if price is going up or down.  Starting from 0 seems to make the least sense, since you want that initial value to be near a hypothetically accurate EMA.
To do a true test of methods, you would need to randomize the quote history to generate truly all of the price action scenarios.
Maybe try again using your Brownian quotes generator and million iterations?
Curve fitting to a sinewave isn't really much of a test.

Random thought: can you transpose the EMA equation and backfill with more accurate values after 100 bars?

Another experiment:

given: EMA = lastEma + (k * (newValue - lastEma)) and k = 2 / (n + 1) where n is the lookback period and i is the series index
set n dynamically as the minimum of the objective n and current i, recalculate k
will this overweighting of earlier values leave an initial EMA that is closer than an SMA?

Hi @mihakralj  and @DaveSkender,
Based on my experience and dabbling in the Technical Arts... the short answer is there is no correct EMA.
TA Lib
Given that TA Lib is the de facto library out there, namely due to it's speed, and thus continues to set the standard, the authors also made some bootstrapping/ initializing choices for some indicators. Some of which were dictated by the needs of the current brokerage software (like TradeStation, MetaStock, et al) of that time before halting TA Lib development circa 2013.
According to TA Lib EMA comment:
 /* The first EMA is calculated differently. It
  * then become the seed for subsequent EMA.
  *
  * The algorithm for this seed vary widely.
  * Only 3 are implemented here:
  *
  * TA_MA_CLASSIC:
  *    Use a simple MA of the first 'period'.
  *    This is the approach most widely documented.
  *
  * TA_MA_METASTOCK:
  *    Use first price bar value as a seed
  *    from the begining of all the available
  *    data.
  *
  * TA_MA_TRADESTATION:
  *    Use 4th price bar as a seed, except when
  *    period is 1 who use 2th price bar or something
  *    like that... (not an obvious one...).
  */

Mathematics
Even in the more rigorous world of Mathematics, EMA can also be calculated differently (with some other descriptions via wikipedia).
Pandas TA
With Pandas TA, one of the primary goals was to implement TA Lib in Python so users would have the same/similar results of TA Lib if they were unable to uninstall TA Lib from source casually. By doing so, I bound my Python calculations to "accurately" match TA Lib by default.
Final Thoughts

Clearly there are technically quite a few variations for EMA that could (or should) be implemented. But obviously there is no need to go overboard implementing them all or some variation unless your or your clients require/request them.
Furthermore since there is an avid population of AI/ML miners, developers and practitioners some indicators could have long periods of initial NaNs in their columns which will eventually force them to drop those rows with ohlcv + inidicator columns with those NaNs before they can do model preprocessing.

Not to mention some indicators like dpo that can add data leaks due to shifting. So be cognizant of those.

As you are also aware of convergence, here is TA Libs discussion of Unstable Period (if you have not seen already) which some indicators like EMA will have an impact on calculation. I have yet to uncover how to minimize the convergence periods :expressionless:.

Ultimately since TA is the Wild West of Time Series Analysis, I recommend starting with what you deem is "more" accurate and possibly make conditional adjustments (like I have) as needed.
Hope this helps!
KJ

This incongruent field of EMA (and it's derivatives) is killing my validation tests as I don't dare to compare early values of any EMA indicators with - say - @DaveSkender or @twopirllc implementations. Tests are 100% valid after convergence happens, but the early values for this whole family of indicators (EMA, DEMA, TEMA, KAMA, T3, SMMA, ZLEMA...) are incomparable as the algos are not consistent. :(

I’m morbidly curious about whether backfilling has any merit, even if repainting.  :neckbeard:
currEma = lastEma + (k * (value - lastEma))
currEma = lastEma + k * value - k* lastEma
currEma - (k * value) = lastEma * (1 - k)
currEma - (k * value) = lastEma * (1 - k)
lastEma = (currEma - (k * value)) / (1 - k)

Few examples of cross-validation that are killing me at the moment:
SMA(5) on a random set - PASS:
Index     TA-Lib            Skender        Pandas-TA      QuanTAlib
----------------------------------------------------------------------
0            NaN             NaN             NaN          100.572
1            NaN             NaN             NaN          100.263
2            NaN             NaN             NaN           99.658
3            NaN             NaN             NaN           99.595
4         99.697          99.697          99.697           99.697
5         99.409          99.409          99.409           99.409
6         99.220          99.220          99.220           99.220
7         99.503          99.503          99.503           99.503
8         99.711          99.711          99.711           99.711
9         99.665          99.665          99.665           99.665
10        99.845          99.845          99.845           99.845

EMA(5) on a random set - PASS:
Index     TA-Lib            Skender        Pandas-TA      QuanTAlib
----------------------------------------------------------------------
0            NaN             NaN             NaN           99.435
1            NaN             NaN             NaN           99.116
2            NaN             NaN             NaN           99.206
3            NaN             NaN             NaN           99.212
4         99.024          99.024          99.024           99.024
5         99.044          99.044          99.044           99.044
6         98.976          98.976          98.976           98.976
7         99.051          99.051          99.051           99.051
8         99.169          99.169          99.169           99.169
9         99.445          99.445          99.445           99.445
10        99.691          99.691          99.691           99.691

DEMA(5) on a random set - FAIL - I modeled DEMA by TA-LIB implementation)
Index     TA-Lib            Skender        Pandas-TA      QuanTAlib
----------------------------------------------------------------------
0            NaN             NaN             NaN           99.125
1            NaN             NaN             NaN           98.409
2            NaN             NaN             NaN           97.387
3            NaN             NaN             NaN           96.637
4            NaN          96.977          96.977           95.912
5            NaN          95.622          95.622           94.878
6            NaN          95.067          95.067           94.581
7            NaN          94.811          94.811           94.521
8         94.723          94.830          94.830           94.723
9         95.118          95.190          95.190           95.118
10        95.441          95.488          95.488           95.441
11        95.532          95.563          95.563           95.532
12        95.886          95.907          95.907           95.886
13        96.433          96.447          96.447           96.433
14        96.469          96.479          96.479           96.469
15        96.918          96.924          96.924           96.918
16        97.091          97.095          97.095           97.091
17        96.803          96.806          96.806           96.803
18        96.991          96.993          96.993           96.991
19        96.776          96.777          96.777           96.776

TEMA(5) on a random set - FAIL - I modeled TEMA by Pandas-TA implementation:
Index     TA-Lib            Skender        Pandas-TA      QuanTAlib
----------------------------------------------------------------------
0            NaN             NaN             NaN           99.989
1            NaN             NaN             NaN           98.995
2            NaN             NaN             NaN           98.310
3            NaN             NaN             NaN           98.152
4            NaN          98.029          98.029           98.029
5            NaN          97.601          97.601           97.601
6            NaN          97.309          97.309           97.309
7            NaN          96.618          96.618           96.618
8            NaN          96.653          96.653           96.653
9            NaN          96.756          96.756           96.756
10           NaN          97.220          97.220           97.220
11           NaN          97.401          97.401           97.401
12        96.889          96.931          96.931           96.931
13        95.739          95.763          95.763           95.763
14        95.666          95.679          95.679           95.679
15        95.725          95.732          95.732           95.732
16        96.284          96.288          96.288           96.288
17        96.419          96.420          96.420           96.420
18        97.443          97.443          97.443           97.443
19        98.061          98.061          98.061           98.061

currEma = lastEma + (k * (value - lastEma))
currEma = lastEma + k * value - k* lastEma
currEma - (k * value) = lastEma * (1 - k)
currEma - (k * value) = lastEma * (1 - k)
lastEma = (currEma - (k * value)) / (1 - k)

I tried several variations here, all of them just weight differently the currentEma - the same effect could be achieved if we raise the factor k up towards 1/2
Which actually begs to try a model for EMA values within the period: use a dynamic factor k that starts with 1 [for EMA(0)] and progressively slides down towards 2/(period+1) towards EMA(period)

Which actually begs to try a model for EMA values within the period: use a dynamic factor k that starts with 1 [for EMA(0)] and progressively slides down towards 2/(period+1) towards EMA(period)

You’d be getting into adaptive MA world at that point, unrelated to EMA.  Generally, I’m not all that interested in improving that initial incalculable period.  I’d rather have null returned than try to fill it.


Only publish site on push to master.  Build for all PR

This resolves an issue where the GitHub action could not perform the push action against the repository.  Now the site is built for all pull requests, but only is published on the push to the master branch.  Note that the push to master event happens when the pull request is merged.
This restriction is because you do not want the PR context to be able to have write access to the repository as outlined here:
https://help.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token#permissions-for-the-github_token

@btashton Why I don't see the build auto start?

It did.  You can see it on the commit in master
https://github.com/apache/incubator-nuttx-website/runs/576061018

Yes, I saw the resut. Great!


PRFC: Merge default scaffolder field extensions

Hey, I just made a Pull Request!
Note that this PR targets the branch from #6723 for now.
Opening this without a changeset etc. to gather feedback. @OrkoHunter and I noticed that integrators who want to add additional custom scaffolder field extensions must also include all the default ones. This means that these integrators will have to update their App.tsx every time the default set of scaffolder field extensions changes. This PR introduces code in the scaffolder router which merges the default scaffolder field extensions with any custom ones supplied.
An alternative to this might be exporing a DefaultScaffolderFieldExtensions component that integrators can use to indicate that they want the default field extensions along with their custom ones.
:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Thanks for the feedback @Rugvip!

I think it would be good to go with exporting the defaults, but prolly as a constant

Interested to understand what leads you to prefer a constant over a component - just a more common pattern in the Backstage codebase, or is there some concrete reason that you prefer that approach?

That way it's not a breaking change...

Since overridden extensions take precedence over the default ones, is it really a breaking change as currently written? The only real behavior change is that people who aren't registering default pickers but are using them in templates would find that those pickers start working.

it'll still be possible for an integrator to remove the default extensions if desired

I'm struggling to come up with a use case for removing the default extensions - given they can be easily overridden, why would someone care if they're available if they're not using them?
I do like the idea of making the inclusion of the default extensions explicit, but one thing that gives me pause is that it makes it harder to write correct code when you're trying to import all the default extensions and override one specific one. The code as written in this PR allows us to differentiate between the default extensions and custom ones when loading them, and give precedence to the custom ones. Conversely, if both default and custom extensions are loaded as children of the route component, we might have to rely on the order in which the components appear to determine precedence. So the first option below would override the entity picker, but the second one would keep the default.
<ScaffolderFieldExtensions>
  {defaultScaffolderFieldExtensions}
  <MyCoolCustomEntityPickerFieldExtension />
</ScaffolderFieldExtensions>

<ScaffolderFieldExtensions>
  <MyCoolCustomEntityPickerFieldExtension />
  {defaultScaffolderFieldExtensions}
</ScaffolderFieldExtensions>

One option to explore to work around this could be to compare the extensions we find with the known list of default extensions and use that to determine precedence.

@mtlewis The constant is a very simple implementation, a component requires a bit more stuff and is otherwise essentially the same thing. It's only a breaking change if you're being very strict about it, that being tied to your last question as well. What I'm imagining is an organization that wants to avoid usage of the default extensions because they have their own custom ones that should be used instead. By removing them you avoid having people copy stuff from the official documentation and using the wrong extensions.
Was gonna go on but I realized another option that I like the most. I'm thinking we ship what you suggest in this PR, as in the merging behaviour, and then if we feel that we need to make it possible to remove the defaults in the future we can do this:
<ScaffolderFieldExtensions defaultFields={false}>
  <MyCoolCustomEntityPickerFieldExtension />
</ScaffolderFieldExtensions>

@Rugvip sounds good to me! I'll get this PR updated with a changeset and opened for review.


Pressing the "return" key on Mac to select an environment variable in the URL also sends an HTTP request

Expected Behavior
Pressing return key should only trigger the environment variable selection in the URL.
Actual Behavior
Pressing return is triggering the variable selection and also sending an HTTP request.
Reproduction Steps

Type something on the URL 2. Use the up and down keys to switch between the recommended suggestions 3. Press the "return" key to select the desired variable 4. The Bug where Insomnia also sends and HTTP request will occur 5.

Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
No response
Insomnia Version
2022.5.1
What operating system are you using?
macOS
Operating System Version
macOs Monterrey v12.5
Installation method
downloaded at https://insomnia.rest/pricing by clicking "Download App"
Last Known Working Insomnia version
No response

Hi @RafaFreitasNog, thanks for reporting this! We can also reproduce it.

This should be fixed in https://github.com/Kong/insomnia/releases/tag/core%402022.7.5


make Develop/npm run build failing with gulp error

Issue Summary
Checking out a fresh copy of Wagtail master and running make develop fails on a gulp error:
><EMAIL_ADDRESS>gulp:prod:build /Users/jim/Documents/projects/nypr/wagtail-jjnypr
> gulp build

gulp[17765]: ../src/node_contextify.cc:635:static void node::contextify::ContextifyScript::New(const FunctionCallbackInfo<v8::Value> &): Assertion `args[1]->IsString()' failed.
 1: 0x10003cff5 node::Abort() [/Users/jim/.nvm/versions/node/v10.16.2/bin/node]
 2: 0x10003c017 node::AddEnvironmentCleanupHook(v8::Isolate*, void (*)(void*), void*) [/Users/jim/.nvm/versions/node/v10.16.2/bin/node]
 3: 0x100067456 node::contextify::ContextifyScript::New(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/jim/.nvm/versions/node/v10.16.2/bin/node]
 4: 0x1002435bf v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo*) [/Users/jim/.nvm/versions/node/v10.16.2/bin/node]
 5: 0x10024275b v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<true>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/Users/jim/.nvm/versions/node/v10.16.2/bin/node]
 6: 0x100242177 v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/Users/jim/.nvm/versions/node/v10.16.2/bin/node]
 7: 0x24abe0fdbe3d
sh: line 1: 17764 Abort trap: 6           npm run gulp:prod:build
npm ERR! code ELIFECYCLE
npm ERR! errno 134
npm ERR<EMAIL_ADDRESS>build: `npm run gulp:prod:build && npm run webpack:prod:build`
npm ERR! Exit status 134

Reading up on that error, I found a suggestion that upgrading to Gulp v4 would resolve it.
Steps to Reproduce

Clone wagtail
Create virtualenv
Run make develop
Get error excerpted above

I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: yes

Technical details

Node: 10.16.2
npm 6.9.0
gulp 3.9.1
macOS 10.14.6 (18G4032)

Hi @jjnypr,
As per https://docs.wagtail.io/en/v2.8.1/contributing/developing.html#setting-up-the-wagtail-codebase , the Node tooling needs to be run under node 8.


Better error messages w.r.t. the various containers

This was first discussed in pac4j/pac4j#941.
Basically, there is some non-working combinations (mainly using the wrong JaxRsConfigProvider with a given container: no session support when expected, or servlet support with a non-servlet container, etc) and even though this is more or less documented, the errors can be quite cryptic.
We should see if we can improve the error message maybe...

Closing due to inactivity.


orca-slicer: remove FLATPAK option

Currently, this breaks building, as this option requires wxGTK3 withwebkit2gtk-4.1 support. As there is no release yet with support for that and backporting https://github.com/wxWidgets/wxWidgets/pull/23633 is difficult, let's revert to the previous (vendored) build behavior.
Previously introduced in 0a92232f3f151072f99beb0c59946af09b120faf
Closes #358666
Closes #358948

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 360219

x86_64-linux

:white_check_mark: 2 packages built:

orca-slicer
orca-slicer.debug

aarch64-linux

:white_check_mark: 2 packages built:

orca-slicer
orca-slicer.debug

backporting wxWidgets/wxWidgets#23633 is difficult,

Why is that the case? Will want to do that for https://github.com/NixOS/nixpkgs/issues/369710.

backporting wxWidgets/wxWidgets#23633 is difficult,

Why is that the case? Will want to do that for #369710.

It was the case specifically for fixing orca-slicer. It would have involved many overrides, whereas removing the build-time option here was much easier.
In general, orca-slicer should probably become its own derivation and be completely independent of bambu-studio.


I have a question about this code.

Thank you for sharing this great project.
I am new to deep learning and have a question about code.
On line 67 of cvpods> modeling> meta_arch> ssd.py,
self.default_box_generator = cfg.build_default_box_generator(cfg)

Where can i find build_default_box_generator?

Sorry, This part of code is not released yet since borderdet has nothing to do with SSD.

Thanks! :)


Create leetcode804.cpp

add a new question

add your name in contributor.txt

okay

Dont Forhet To Follow me


Update LensNFTBase.sol: Use 'immutable' for keccak instead of 'constant'

Changes are easily noticeable inside the file changed.
For better understanding -> https://gist.github.com/grGred/9bab8b9bad0cd42fc23d4e31e7347144#change-constant-to-immutable-for-keccak-variables
This issue is worth to take a look -> https://github.com/seen-haus/seen-contracts/issues/29

Yea I get that!


User Profile RSS feed and display all torrents

Nyaa had the ability of changing the page type to separate (EX: nyaa.se/?page=separate&user=43553&sort=5) for a user which would be just like the index page but it would list all their torrents. The user profile should also accept the same arguments like the search and appending "feed" to the end of the search should display an RSS feed.
Now instead of adding the "separate" page we would just use "all" after the username.
Here are some URL examples
https://nyaa.pantsu.cat/user/[user_id]/[username]/feed (rss feed of page 1)
https://nyaa.pantsu.cat/user/[user_id]/[username]/feed?c=3_&s=&sort=torrent_id&order=desc&max=50&q= (rss feed of anime max 50)
https://nyaa.pantsu.cat/user/[user_id]/[username]/page/2/feed (rss feed of page 2)
https://nyaa.pantsu.cat/user/[user_id]/[username]/all?c=6_&s=&sort=torrent_id&order=desc&q=CG
(rss feed that contains string "CG" from pictures and will ignore the max argument)
https://nyaa.pantsu.cat/user/[user_id]/[username]/all/feed (rss feed of all a user's torrents)

and will ignore the max argument

Is this a good idea? I mean, I think there should be a limit, for the same reasons why there's a limit on the search page.


ci: fixes for Go 1.16

ci: use pinned versions of images/deps
Prevent surprises with updating CI in the future 🙃
This also uses a pinned version of the tilt-dev/tilt-extensions-ci helper
ko: fix tests for Go 1.16
The package we were building does not build in Go module-aware
mode. It was also a random third-party package.
This replaces it with a tiny hello world local app. While this
does not test the remote fetch functionality of the extension,
that is actually largely inoperable with modern projects (i.e.
those that use Go modules).
See https://github.com/tilt-dev/tilt-extensions/issues/188 for details.
test-in-tilt: fix for Go 1.16
These were running module-mode incompliant commands - when you
have a go.mod, you MUST run the go test command from within
the module hierarchy (i.e. at or under the go.mod dir).
In practice, this isn't a huge issue, as generally you'd have a
Tiltfile at the same level as a go.mod, so the test structure
is adjusted to reflect this with the elimination of the fake_project
dir.
It is possible to work around this using the new dir argument
that local_resource supports, which will eventually receive it
via **kwargs, so if you have the file structure:
├── go-app
│   ├── go.mod
│   └──main.go
└── Tiltfile

You can do:
test_go('mytests', './...', './go-app', dir='./go-app')

So that the go test ./... command is run inside of the go-app
directory, instead of trying to pass ./go-app/... as the "package".

@nicks Okay, I had to make some other changes for ko + tests-in-tilt/go due to module incompliant stuff they were both doing that doesn't fly in 1.16+. Updated PR description has all the details.
This should make Go 1.17 smoother at least!


Consider dnsmasq as a workaround to AmazonProvidedDNS throttling

Before considering the implementation we will gather metrics about DNS packages lost. Based on that we will decide on further actions.
If dnsmasq is implemented, will have to be included in CAPI as well. Otherwise we can edit node-exporter to include in both if that works out.
Internal thread: https://gigantic.slack.com/archives/C6L8J93N0/p1671439728720789
@tuladhar can you please share your findings here?

Tested the ethtool collector on grizzly workload cluster, and the metrics is available via node_exporter.

Also, tested the following dashboard:

https://grafana.com/grafana/dashboards/17244-aws-ena-network-performance/?plcmt=footer

We need to adjust the dashboard JSON as per our need, such as cluster_id, etc.

Created PR to enable ethtool collector on node-exporter-app.

https://github.com/giantswarm/node-exporter-app/pull/164

changes in node-exporter changes looks good to me, so lets deploy this further

@tuladhar i know there was an incident on MCs where it was rolled out - do we have a follow up on this?

Now, that the team is back from Christmas. We need to continue the testing of changes that were done in node-exporter since v1.13.0 which are in master. The last release was done 6 months ago, and lots of changes had been accumulated that caused unexpected issues during rollout.
We did manage to push one fix in v1.14.1, but had to be rollback because of prometheus rules failures. Full thread here.
@T-Kukawka How should we move forward with it, as we need to reproduce the issue again, fixed it and then do rollout once we're confident, that it won't break.
It would be great, If anyone who has worked with node-exporter-app before that can help me on this? As I'm still not familiar with it.

@T-Kukawka How should we move forward with it, as we need to reproduce the issue again, fixed it and then do rollout once we're confident, that it won't break.

Worth trying WC testing release on our test installations i guess. @njuettner do u have an experience with it?

Sync'd with Nick, and starting the test release on Gauss installation.

Along with Erkan, we figured out the major issue with node-exporter between 1.13.0 and 1.14.1:

In 1.13.0 - node exporter was part of default apps, since beginning.
In 1.14.1 - node exporter was also pushed to app collection via CircleCI.

Thus, when we release 1.14.1 — we had two copies of node-exporter app running. And because node exporter runs as daemonset and binds to NodePort 10300, we saw pending of pods trying to bind to that port as expected.
Follow up actions:

[ ] Fix CircleCI config to remove CAPI app collection
[ ] Remove node-exporter from CAPI app collection
[ ] Release the new version of default apps

Atlas team also found a bug on node-exporter prometheus rule:

https://github.com/giantswarm/giantswarm/issues/25216

Deployed v1.14.1 on grizzly, looking good. Now, blocked by Team Atlas to release their prometheus related fixes.

@T-Kukawka Team Atlas have released v1.15.0, and has been deployed on all MCs. Now the next step would release on customer workload specially on anteater - peu01  cluster where we need to gather metrics on DNS throttling.

Nick working on v18.2.0 release of AWS, with node-exporter v1.15.0, and after that we'll validate on test cluster.

[ ] Created workload cluster with AWS release v18.2.0 with node-exporter v1.15.0 on gauss
[ ] Verified linklocal_allowance_exceeded metrics availability
[ ] Updated ops-recipes/vpc-dns-throttling with ethtool collector. See PR

Screenshots:

that part is done


Move new paid data sources to dedicated-2

Description
dedicated-2 is live. Move all new paid collections to it.
Risk
N/A dedicated-2 liveness and readiness has been tested.
Deploy Plan

deploy front

PMRW


Update ui

Codecov Report
Base: 44.92% // Head: 44.92% // No change to project coverage :thumbsup:

Coverage data is based on head (19d6b24) compared to base (ce94a31).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #124   +/-   ##
=========================================
  Coverage     44.92%   44.92%
  Complexity      429      429
=========================================
  Files           109      109
  Lines          2186     2186
  Branches        241      241
=========================================
  Hits            982      982
  Misses         1154     1154
  Partials         50       50

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Back link with scroll position restore

I'd like to have a link <a> on my page that links to the previous page. But the scroll position won't be restored unless the browser back button is used. Is there a way to "opt-in" into scroll position restoration on a link?

Scroll position with Turbo seems to be a hot topic. This is mentioned all the way back in #37. I think development on features has been stalled for the time being, or at least as far as anyone has heard. With that said, I don't believe that there's a method of maintaining scroll position on drive requests as of right now. If you have ideas or are looking for workarounds, I think #37 might be the best place to look.
Regardless, as of now I think that this issue is probably safe to close cc: @dhh.

We absolutely have issues with scroll position. Hope to kick off a larger inquiry into this as we need to fix it for HEY as well. But right now there's no such affordance.


PyMongo 3.0

closes #27
@lmperry Could I please get your help with testing centralclient.py.
@rentzso Could you please give this a test run?
@mrDarcyMurphy Apologies for adding file timestamps to this unrelated PR.

LGTM

:+1:

@gsfr ¯_(ツ)_/¯ I'm just glad they're in. Thanks!


Breaking Loop

While loops are not broken when an accept or reject statement is reached.

Changed statement evaluation function type to be Stm -> Config -> App Config


Update to ZEIT Now 2, Vercel [[Deadline: August 7th]]

ZEIT Now 1 will be phased out in less than a month and I don't see any mention of this deadline in the repo.
packd will stop working on August 7th

Official announcement: https://mailchi.mp/f923e55efe1d/simplified-pricing-1087517
Possible fix: https://stackoverflow.com/a/62453071

I tested my fork of packd and almost managed to make it run: https://github.com/fregante/packd/pull/2
The problem is that now there's a hard duration limit of 10 seconds for the "hobby" account: https://vercel.com/docs/v2/platform/limits
This severely limits the feasibility of packd on Vercel:
[GET]<EMAIL_ADDRESS>18:02:10:16
packd info [doma] requested package
packd info [doma] is not cached
packd info /var/task/server
packd info /var/task/server/child-processes/create-bundle.js
/var/task
packd info [doma] fetching https://registry.npmjs.org/doma/-/doma-3.0.1.tgz
packd info [doma] extracting to /tmp/f128ef27-dcfb-49cb-9cca-3b4707fccbba/90c0e61c9df54f74f16f5d94831cf4eaa5a6c1df/package
packd info [doma] running  npm install --production

Packd is officially offline:

bundle.run however seems to continue working. Perhaps it should just drop the Vercel integration/mention.

bundle.run isn't hosted on Vercel and not planning to taking it down


perf(semantic): reduce memory copies

Reduce memory copies when resolving references in Semantic.
If parent scope has no unresolved references for name, there is no need to generate a new Vec<ReferenceId> for name and copy in contents from current scope. Just move the existing Vec to the parent.

#4216  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @overlookmotel and the rest of your teammates on  Graphite

The double hashing problem gonna get onto your nerves isn't it ;-)

The double hashing problem gonna get onto your nerves isn't it ;-)

Yes! I was reading hashbrown's source code last night. Bedtime reading.


[SP-3153] - Backport of PDI-13829 - NPE - pressing verify this transformation (7.0 Suite)

Replaced null field names with empty strings
New locale message were added.
Validation meta info were created before ddl creation.
Created unit test.
Fixed test warnings.

@PashkovichAndrei can you please specify SP case number in the commit message?
thanks.

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f core/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f core/build.xml jacoco-integration checkstyle publish-local
ant -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local
ant -Dtestreports.dir=bin/reports/unit-test -f ui/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f ui/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  core/src/org/pentaho/di/core/row/RowMeta.java
  core/test-src/org/pentaho/di/core/row/RowMetaTest.java
  engine/src/org/pentaho/di/trans/steps/tableoutput/messages/messages_en_US.properties
  ui/src/org/pentaho/di/ui/trans/steps/tableoutput/TableOutputDialog.java
  ui/test-src/org/pentaho/di/ui/trans/steps/tableoutput/TableOutputDialogTest.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.logging.KettleLogStore.new TimerTask() {...}

Branch Change:  + 50.00%
Complexity Change:  + 33.33%
Instruction Change:  + 75.68%
Line Change:  + 83.33%
Method Change:  + 50.00%

org.pentaho.di.core.logging.LoggingBuffer

Complexity Change:  + 1.72%
Instruction Change:  + 1.09%
Line Change:  + 1.53%
Method Change:  + 3.45%

org.pentaho.di.core.row.RowMeta

Branch Change:  + 2.25%
Complexity Change:  + 2.74%
Instruction Change:  + 2.46%
Line Change:  + 3.09%
Method Change:  + 3.33%

org.pentaho.di.core.auth.core.impl.DefaultAuthenticationConsumerFactory

Branch Change:  + 7.14%
Complexity Change:  + 7.69%

org.pentaho.di.repository.kdr.KettleDatabaseRepositoryCreationHelper

Branch Change:  + 1.64%
Complexity Change:  + .69%
Instruction Change:  + 2.40%
Line Change:  + 3.51%

org.pentaho.di.trans.step.StepMeta

Instruction Change:  + .19%
Line Change:  + .27%

org.pentaho.di.trans.steps.checksum.CheckSumMeta

Instruction Change:  + .11%

org.pentaho.di.trans.steps.combinationlookup.CombinationLookupMeta

Instruction Change: -.04%:small_red_triangle_down:

org.pentaho.di.trans.steps.constant.ConstantMeta

Instruction Change:  + .10%

org.pentaho.di.trans.steps.csvinput.CsvInputMeta

Instruction Change:  + .05%

org.pentaho.di.trans.steps.datagrid.DataGridMeta

Instruction Change: -.09%:small_red_triangle_down:

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change: -.11%:small_red_triangle_down:

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change:  + 2.08%
Complexity Change:  + 2.11%

org.pentaho.di.trans.steps.ifnull.IfNullMeta

Branch Change: -2.00%:small_red_triangle_down:
Complexity Change: -1.89%:small_red_triangle_down:
Instruction Change: -.17%:small_red_triangle_down:

org.pentaho.di.trans.steps.insertupdate.InsertUpdateMeta

Instruction Change: -.05%:small_red_triangle_down:

org.pentaho.di.trans.steps.ldapoutput.LDAPOutputMeta

Instruction Change:  + .06%

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change:  + 1.18%
Complexity Change:  + 1.35%

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change: -.07%:small_red_triangle_down:

org.pentaho.di.trans.steps.singlethreader.SingleThreaderMeta

Instruction Change: -.08%:small_red_triangle_down:

org.pentaho.di.trans.steps.sort.SortRowsMeta

Instruction Change: -.08%:small_red_triangle_down:

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change:  + .18%

org.pentaho.di.trans.steps.synchronizeaftermerge.SynchronizeAfterMergeMeta

Instruction Change:  + .04%

org.pentaho.di.trans.steps.systemdata.SystemDataMeta

Branch Change:  + 2.04%
Complexity Change:  + 2.04%
Instruction Change:  + .32%
Line Change:  + .81%

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change: -.53%:small_red_triangle_down:

org.pentaho.di.ui.trans.steps.tableoutput.TableOutputDialog

Branch Change:  + 3.16%
Complexity Change:  + 4.08%
Instruction Change:  + .59%
Line Change:  + .88%
Method Change:  + 10.53%

Integration test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.trans.step.BaseStep

Complexity Change:  + .18%
Instruction Change:  + .20%
Line Change:  + .38%
Method Change:  + .49%

@mchen-len-son commit message was corrected

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f core/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f core/build.xml jacoco-integration checkstyle publish-local
ant -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local
ant -Dtestreports.dir=bin/reports/unit-test -f ui/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f ui/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  core/src/org/pentaho/di/core/row/RowMeta.java
  core/test-src/org/pentaho/di/core/row/RowMetaTest.java
  engine/src/org/pentaho/di/trans/steps/tableoutput/messages/messages_en_US.properties
  ui/src/org/pentaho/di/ui/trans/steps/tableoutput/TableOutputDialog.java
  ui/test-src/org/pentaho/di/ui/trans/steps/tableoutput/TableOutputDialogTest.java

Newly Fixed Tests:
org.pentaho.di.trans.steps.textfileinput.TextFileInputMetaLoadSaveTest.testSerialization:
:large_blue_circle: java.lang.RuntimeException
java.lang.RuntimeException: Error validating dateFormatLocale
	at org.pentaho.di.trans.steps.loadsave.LoadSaveTester.validateLoadedMeta(LoadSaveTester.java:176)
	at org.pentaho.di.trans.steps.loadsave.LoadSaveTester.testXmlRoundTrip(LoadSaveTester.java:223)
	at org.pentaho.di.trans.steps.loadsave.LoadSaveTester.testSerialization(LoadSaveTester.java:182)
	at org.pentaho.di.trans.steps.textfileinput.TextFileInputMetaLoadSaveTest.testSerialization(TextFileInputMetaLoadSaveTest.java:159)
Caused by:

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.row.RowMeta

Branch Change:  + 2.25%
Complexity Change:  + 2.74%
Instruction Change:  + 2.46%
Line Change:  + 3.09%
Method Change:  + 3.33%

org.pentaho.di.core.auth.core.impl.DefaultAuthenticationConsumerFactory

Branch Change: -7.14%:small_red_triangle_down:
Complexity Change: -7.69%:small_red_triangle_down:

org.pentaho.di.job.entries.evaluatetablecontent.JobEntryEvalTableContent

Branch Change:  + 1.01%
Complexity Change:  + 1.06%
Instruction Change:  + .17%

org.pentaho.di.job.entries.waitforsql.JobEntryWaitForSQL

Branch Change: -.66%:small_red_triangle_down:
Complexity Change: -.93%:small_red_triangle_down:
Instruction Change: -.13%:small_red_triangle_down:

org.pentaho.di.repository.kdr.KettleDatabaseRepositoryCreationHelper

Branch Change: -1.64%:small_red_triangle_down:
Complexity Change: -.69%:small_red_triangle_down:
Instruction Change: -2.40%:small_red_triangle_down:
Line Change: -3.51%:small_red_triangle_down:

org.pentaho.di.trans.step.StepMeta

Instruction Change:  + .19%
Line Change:  + .27%

org.pentaho.di.trans.steps.checksum.CheckSumMeta

Instruction Change: -.11%:small_red_triangle_down:

org.pentaho.di.trans.steps.combinationlookup.CombinationLookupMeta

Instruction Change: -.04%:small_red_triangle_down:

org.pentaho.di.trans.steps.constant.ConstantMeta

Instruction Change: -.10%:small_red_triangle_down:

org.pentaho.di.trans.steps.csvinput.CsvInputMeta

Instruction Change:  + .05%

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change:  + 1.04%
Complexity Change:  + 1.05%

org.pentaho.di.trans.steps.insertupdate.InsertUpdateMeta

Instruction Change: -.05%:small_red_triangle_down:

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change: -.07%:small_red_triangle_down:

org.pentaho.di.trans.steps.setvalueconstant.SetValueConstantMeta

Instruction Change:  + .14%

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change: -.18%:small_red_triangle_down:

org.pentaho.di.trans.steps.textfileinput.TextFileFilter

Complexity Change:  + 9.09%
Instruction Change:  + 9.26%
Line Change:  + 8.33%
Method Change:  + 9.09%

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change:  + 12.11%
Complexity Change:  + 5.18%
Instruction Change:  + 30.23%
Line Change:  + 22.72%
Method Change:  + 3.21%

org.pentaho.di.trans.steps.webservices.WebServiceMeta

Branch Change: -1.79%:small_red_triangle_down:
Complexity Change: -1.19%:small_red_triangle_down:
Instruction Change: -.07%:small_red_triangle_down:

org.pentaho.di.trans.Trans

Branch Change:  + .10%
Complexity Change:  + .14%
Instruction Change:  + .09%
Line Change:  + .11%

org.pentaho.di.www.TransformationMap

Branch Change: -3.41%:small_red_triangle_down:
Complexity Change: -1.54%:small_red_triangle_down:
Instruction Change: -5.49%:small_red_triangle_down:
Line Change: -4.62%:small_red_triangle_down:

org.pentaho.di.ui.trans.steps.tableoutput.TableOutputDialog

Branch Change:  + 3.16%
Complexity Change:  + 4.08%
Instruction Change:  + .59%
Line Change:  + .88%
Method Change:  + 10.53%

Integration test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.trans.step.BaseStep

Complexity Change: -.18%:small_red_triangle_down:
Instruction Change: -.20%:small_red_triangle_down:
Line Change: -.38%:small_red_triangle_down:
Method Change: -.49%:small_red_triangle_down:


Issue with Version 2.8 - JsonPath.java#set() and JsonPath.java#add()

set/add method evaluates the path and if not present throws the error, ideally this should not be the case.
ideally set sets the field on the desired path. In case of nested fields we should be verifying till the parent node only.
This change is breaking the code where we are setting the field in json using set method.
EvaluationContext evaluationContext = path.evaluate(jsonObject, jsonObject, configuration, true);
        if (evaluationContext.getPathList().isEmpty()) {
            boolean optSuppressExceptions = configuration.containsOption(Option.SUPPRESS_EXCEPTIONS);
            if (optSuppressExceptions) {
                return handleMissingPathInContext(configuration);
            } else {
                throw new PathNotFoundException();
            }
        }

either we should remove if or we should only check till parent element. as this check is defying the functionality of set method. Suggestions please.

@suhailSj I am stucked on this kind of issue already, please check and let me know if you faced this issue or know the solution.
https://github.com/json-path/JsonPath/issues/982#issue-2082624079


#9454: add topk to ttnn

also support vector outputs for ttnn ops on the C++ side
add support for a user-defined create_async_output_tensors to enable vector support
allows for runtime-determined tensor count when the number of tensors can be derived from the input tensors and output tensors

TODO: There are a lot of spaces/structs that require tuple and others that require vector. Allowing both is ideal.
TODO: create_async_output_tensors should also be dependent on the actual input parameters - for some torch ops the output tensors depend on parameters (torch.split)
TODO: if performance is good on ttnn.topk then delete ttl.topk
Ticket

#9454 : Add TopK to TTNN

Problem description

Currently the implementation is only linked to tt_lib, which is being deprecated

What's changed

Add to ttnn
Use new op format
Add support for vector of outputs in TTNN OPs

Checklist

[x] Post commit CI passes
[ ] Model regression CI testing passes (if applicable)
[ ] New/Existing tests provide coverage for changes

CI runners not running, but there's an expected failure related to ttnn tests that @aliuTT is debugging

Looks good. For this PR, I think we should also delete the ttlib equivalent of topk_program_factory and the custom kernels. This avoids code duplication and potential confusion if we don't delete the ttlib version in the near future.

was going to do a follow up for this since I wanted to make sure the ttnn performance works for the Mixtral people

Looks good. For this PR, I think we should also delete the ttlib equivalent of topk_program_factory and the custom kernels. This avoids code duplication and potential confusion if we don't delete the ttlib version in the near future.

was going to do a follow up for this since I wanted to make sure the ttnn performance works for the Mixtral people

You don't have to delete the ttlib interfaces, but the underlying create program + custom kernels are all the same code right? These are safe to delete

Looks good. For this PR, I think we should also delete the ttlib equivalent of topk_program_factory and the custom kernels. This avoids code duplication and potential confusion if we don't delete the ttlib version in the near future.

was going to do a follow up for this since I wanted to make sure the ttnn performance works for the Mixtral people

You don't have to delete the ttlib interfaces, but the underlying create program + custom kernels are all the same code right? These are safe to delete

Spoke offline about this with Brian. Seems like there was some issues with crossing name spaces, causing the build to fail. I will just delete all of this at once once Mixtral switches over to ttnn.


Error "urlplurals is nil" in RestDynamicController for RunnerGroup

Describe the bug
When using the RunnerGroup custom resource with the provided RestDefinition and manifest, the following error is encountered during status update processing:
2024-11-28T15:32:48Z    DEBUG   rest-dynamic-controller Observe: updating status        {"error": "urlplurals is nil"}
2024-11-28T15:32:48Z    DEBUG   rest-dynamic-controller processing event, retrying      {"retries": 0, "obj": "{cJ3731frM Observe {github.custo
mer.com/v1alpha1 RunnerGroup runner-test gh-runners}}", "error": "urlplurals is nil"}

To Reproduce
Steps to reproduce the behavior:

Use the following RestDefinition to configure the RunnerGroup resource:kind: RestDefinition
apiVersion: swaggergen.krateo.io/v1alpha1
metadata:
  name: github-runnergroup
  namespace: gh-runners
spec:
  oasPath: https://raw.githubusercontent.com/banshee86vr/github-runner-group-swagger/refs/heads/main/ghec_extracted.yaml
  resourceGroup: github.customer.com
  resource:
    kind: RunnerGroup
    identifiers:
      - org
      - runner_group_id
    verbsDescription:
      - action: findby
        method: GET
        path: /orgs/{org}/actions/runner-groups/{runner_group_id}
      - action: get
        method: GET
        path: /orgs/{org}/actions/runner-groups/{runner_group_id}
      - action: update
        method: PATCH
        path: /orgs/{org}/actions/runner-groups/{runner_group_id}
      - action: create
        method: POST
        path: /orgs/{org}/actions/runner-groups
      - action: delete
        method: DELETE
        path: /orgs/{org}/actions/runner-groups/{runner_group_id}

Deploy the following RunnerGroup manifest:apiVersion: github.customer.com/v1alpha1
kind: RunnerGroup
metadata:
  name: runner-test
  namespace: gh-runners
spec:
  runner_group_id: 123
  allows_public_repositories: false
  name: runner-test-by-crd
  org: prom-candp
  selected_repository_ids:
    - 123123123
  visibility: private
  authenticationRefs:
    bearerAuthRef: bearer-gh-ref

Observe the logs of the rest-dynamic-controller.

Expected behavior
The controller should update the status of the RunnerGroup resource without encountering the urlplurals is nil error.
Additional context

The error suggests an issue with the URL pluralization logic in the rest-dynamic-controller during status observation.
The urlplurals value may not be set appropriately or resolved in the generated API configuration for the RunnerGroup resource.

The pluraliser is offered by the Krateo BFF, so installing it solves the issue.

❤


Inner matrix dimensions must agree error in demToyUnsupervised

I get this error when I run demToyUnsupervised. When I tried to debug, I found that the dimensions actually don't agree.
Error using  *
Inner matrix dimensions must agree.

Error in ppcaEmbed (line 50)
    X = Ycentre*u(:, 1:dims)*diag(1./sqrt(v(1:dims)));

Error in vargplvmCreate (line 109)
    X = initFunc(model.m, q);

Error in vargplvmEmbed (line 67)
model = vargplvmCreate(latentDim, d, Y, options);

Error in hsvargplvmModelCreate (line 164)
                curX = [curX initFunc(m{i}, Q1, initXOptions{h}{:})];

Error in demToyHsvargplvm1 (line 101)
model = hsvargplvmModelCreate(Ytr, options, globalOpt, initXOptions);

Error in demToyUnsupervised (line 38)
demToyHsvargplvm1; % Run the actual demo

Error in tutorial (line 39)
demToyUnsupervised; % Call to the demo

Can you try to run demTutorial.m and see if it works there?

@Amar2407 I'm assuming you mean deepGP/matlab/tutorial.m. Tried that, didn't work from there either.

I will look at it surya and will get back to you!

Sure! :)

Hi, you may download netlab and add the path to  demToyUnsupervised.

Oh thanks, I'll try that.

Works, thanks for the suggestion @WeiHuang05 :)

@psurya1994 I am glad that helps you


DDC issue main method not called

Dart SDK Version (dart --version) Dart SDK version: 2.12.0-29.10.beta, Dart SDK version: 2.10.4 - tested using these dart sdks.

Whether you are using Windows, MacOSX, or Linux (if applicable) - macOS Catalina, 10.15.7

Whether you are using Chrome, Safari, Firefox, Edge (if applicable)- tested in all browsers, including safari and Firefox. Chrome version = 87.0.4

main.dart has following code:
import 'package:angular/angular.dart';
import 'package:angular_router/angular_router.dart';
import 'main.template.dart' as self;
import 'package:company/app_component.template.dart' as ng;

@GenerateInjector([
  routerProvidersHash,
])
final InjectorFactory injector = self.injector$Injector;

void main() {
  print(" in main 25 "); // main method never executed
   runApp(ng.AppComponentNgFactory, createInjector: injector); // this line never executed, neither
}

app_component.dart:
import 'package:angular/angular.dart';
import 'package:angular_router/angular_router.dart';

@Component(
    selector: 'infapp',
    templateUrl: 'app_component.html',
    directives: const [
      coreDirectives,
      routerDirectives,
    ],
)
class AppComponent  {
  AppComponent(Router router)  {
    print("AppComponent called ... "); // never executed
  }
}

index.html:
<!DOCTYPE html>

    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta charset="utf-8"/>
    <link rel="icon" type="image/ico" href="img/icons/favicon.ico">
    <title>company</title>

    <infapp>

                Loading...

                Please Wait

    </infapp>

pubsec.yaml
name: company
description: company
version: 0.0.1
environment:
  sdk: '>=2.10.0 <=3.0.0'
dependencies:
  angular: ^6.0.1
  angular_forms: ^3.0.0
  angular_router: ^2.0.0
  http: ^0.12.2
  stream_transform: ^1.2.0
  uuid: ^2.2.2
  json_annotation: ^3.1.0
  bootstrap_sass: ^4.5.0
  angular_components: ^1.0.2
dev_dependencies:
  sass_builder: ^2.1.3
  json_serializable: ^3.5.0
  build_runner: ^1.10.9
  build_web_compilers: ^2.15.1

Command used to run the app with ddc compiler:
pub global run webdev serve --debug -v
It compiles fine, no errors, but when navigating to http://localhost:8080, only index.html content is displayed, AppComponent component never instantiated, nor main method of main.dart called . Only one warning in a chrome developer console:
DevTools failed to load SourceMap: Could not load content for http://<IP_ADDRESS>:8080/packages/build_web_compilers/src/dev_compiler_stack_trace/stack_trace_mapper.dart.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
When running dart2js compiler, app behaves correctly, and AppComponent is loaded:
pub global run webdev serve --release -v
As another example, I have tested this issue with sample TOH at: https://github.com/angular-examples/quickstart/tree/master too
After fixing few dependencies, app could build, not able to run it with ddc compiler, only with dart2js.
Note: There is no build.yaml in a project sources.

Why is main.dart main method never executes ?
Why is AppComponent constructor never gets called ?
What am I doing wrong ? :)

Thank you

I cloned https://github.com/angular-examples/quickstart/tree/master
ran webdev serve and it worked.
Did you manage to make it works ?

It appeared to be a problem with permissions.
Running application with:
sudo pub global run webdev serve web:8081 --auto=refresh --debug  creates .dart_tool/webdev folder and starts a web browser.
Checking audit logs, there were permissions denied errors found to create .dart_tool/webdev folder. Running command with sudo privileges solved a problem. However non of the other other folders under .dart_tool/webdev folder require sudo permissions
Also, if a new browser window is opened, main method is not loaded, again.
I will close this issue, since it is now tracked at: https://github.com/dart-lang/webdev/issues/1216
Thank you!


Unused argument in cn_salmon

I am trying to run CellNet for RNA-Seq data locally but at the step 6.B mentioned in your Nature protocols paper, I am having an error unsed arguiment for 'geneTabfname'.
expList<-cn_salmon(stQuery, refDir="ref/", salmonIndex=iFileHuman, salmonPath=pathToSalmon, geneTabFname="geneToTrans_Homo_sapiens.GRCh38.80.exo_Jul_04_2015.R")

Error in cn_salmon(stQuery, refDir = "ref/", salmonIndex = iFileHuman,  : unused argument (geneTabFname = "geneToTrans_Homo_sapiens.GRCh38.80.exo_Jul_04_2015.R")

Then just to check I tried running it without geneTabfname, all other steps in it ran but then it gives an error that the file not found
expList<-cn_salmon(stQuery, refDir="ref/", salmonIndex=iFileHuman, salmonPath=pathToSalmon)

In readChar(con, 5L, useBytes = TRUE) :
cannot open compressed file 'ref//geneToTrans_Mus_musculus.GRCm38.80.exo_Jun_02_2015.R', probable reason 'No such file or directory'

I checked the help document and also the cn_salmon function file from the bin but couldn't find any help there as well
I also tried giving the full path for the file but it made no difference
Another point to make here, thoiugh I am using the Human example but I get the file not found for Mus musculus

Can you see what happens when you change "geneTabFname" to "geneTabfname" to match the function definition?

Hi Patrick
Thanks for your response
Yes it worked with this


msg.sender during deploy scripts is not EOA wallet addr

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0
What command(s) is the bug in?
forge script script/Deploy.s.sol:DeployHome --rpc-url sepolia --broadcast --verify -vvvv --etherscan-api-key sepolia
Operating System
Windows
Describe the bug
Ref repo: https://github.com/calnix/X-ChainToken/blob/main/script/Deploy.s.sol
I was initially running the deploy script above, using msg.sender as a param for variables such as delegate and owner, which are then passed into respective contracts, constructors.

On deployment, I expected msg.sender to be my wallet address which is 0xdE05a1Abb121113a33eeD248BD91ddC254d5E9Db
Instead, in some cases it was 0x1804c8AB1F12E6bbf3894d4083f33e07309d1f38. I have no idea where this address comes from.

At first, this effect was sporadic - first two contracts on sepolia were fine, but the remote contract on Polygon had a wonky msg.sender.
Subsequently,  it became more pronounced, and I hardcoded my address instead of using msg.sender.
(Using windows 10, natively; without WSL)

To pinpoint exactly what issue you are encountering, you'll need to be more specific about how you've configured your wallet at 0xdE05..., are you using a env var, keystore, or ledger?
I don't exactly have your issue but I've been researching today on how forge decides who broadcasts a transaction when vm.broadcast is called and this might be helpful to you https://github.com/foundry-rs/foundry/pull/7454.
In that PR, they've updated the docs to be more clear on how a signer is chosen
/// Broadcasting address is determined by checking the following in order:
/// 1. If `--sender` argument was provided, that address is used.
/// 2. If exactly one signer (e.g. private key, hw wallet, keystore) is set when `forge broadcast` is invoked, that signer is used.
/// 3. Otherwise, default foundry sender (1804c8AB1F12E6bbf3894d4083f33e07309d1f38) is used.

As a sidenote, does anyone know how the docs at book.getfoundry.sh get updated? PR 7454 looks like it was merged, yet I see the same outdated explanation for the broadcast cheatcode here https://book.getfoundry.sh/cheatcodes/broadcast

Tentatively marking as resolved by https://github.com/foundry-rs/foundry/pull/7454
@ramenforbreakfast thanks for your comment, indeed the rules for determining the sender are as follows:
    /// Broadcasting address is determined by checking the following in order:
    /// 1. If `--sender` argument was provided, that address is used.
    /// 2. If exactly one signer (e.g. private key, hw wallet, keystore) is set when `forge broadcast` is invoked, that signer is used.
    /// 3. Otherwise, default foundry sender (1804c8AB1F12E6bbf3894d4083f33e07309d1f38) is used.

When deploying without a --sender specified we now throw a warning:
Error:
You seem to be using Foundry's default sender. Be sure to set your own --sender.

Without more details on the specific deployment flow it is difficult to narrow this down. Feel free to re-open with a minimal reproduction example.

I encountered the same issue with the latest version. I didn’t use the --sender flag, and I would like to deploy the code without specifying --sender.

version

foundryup: installed - forge 0.2.0 (e16a75b 2024-09-15T00:22:35.343615000Z)
foundryup: installed - cast 0.2.0 (e16a75b 2024-09-15T00:22:35.330620000Z)
foundryup: installed - anvil 0.2.0 (e16a75b 2024-09-15T00:22:35.371909000Z)
foundryup: installed - chisel 0.2.0 (e16a75b 2024-09-15T00:22:35.317955000Z)

code

contract DeployContract is BaseScript {
    error InvalidAddress(address normal, address thrower, address txOrigin);

    function run() external {
          uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");

          address deployer = vm.rememberKey(deployerPrivateKey);
          vm.startBroadcast(deployer);

          if (msg.sender != deployer) {
              revert InvalidAddress(deployer, msg.sender, tx.origin);
          }
          ...
    }

command

forge fmt && forge clean && forge build
source .env
forge script script/Deploy.s.sol \
--rpc-url $BASE_SEPOLIA_RPC_URL \
-vvvv

forge fmt && forge clean && forge build && source .env
forge script script/Deploy.s.sol \
--rpc-url $BASE_SEPOLIA_RPC_URL \
--broadcast \
--verify \
--etherscan-api-key $BASE_SEPOLIA_KEY \
-vvvv

error


Added Greek Language

Adding a language

[ Yes] The code displays "Hello World"
[Yes ] I have updated the readme to include the new language
[Yes ] I have incremented the language count in the readme

@Richienb does anything need fixing?


Allow skipping files if the MD5 matches.  --check-md5 for

Which version of the AzCopy was used?
10.1.2
Which platform are you using?
Windows
What command did you run?
azcopy sync .\dist https://<account>.blob.core.windows.net/$web --delete-destination true --put-md5
What problem was encountered?
azcopy synchronizes all files base on the LMT property even if the content MD5 has not changed.  This means that for server side build solutions even if 99% of the generated output files are the same, it will still re-copy them because the LMT dates have changed.  I recommend adding support to sync and copy to allow --check-md5 SkipIfNotModified or something else to request that unmodified files not be sync'd.  This could also include checking if the filesize is the same to reduce the false positive rate.
How can we reproduce the problem in the simplest way?

Generate a file
azcopy sync the file somewhere
Re-generate the file with the same contents but a new Last Modified Time
azcopy sync again and notice the unchanged file is re-copied.

Have you found a mitigation/solution?
Feature Request

Hi @veleek.  Can you tell us a bit more about the context where this would be useful?
The reason I'm asking is as follows. To tell whether the MD5 has changed, we still have to read the disk file, because the only way to find the MD5 of a file on disk is to read the whole file and compute the MD5.  So for instance when syncing local disk to cloud storage, we'd have to read all the local files (or at least, all the local files where the LMT had changed, which in your example is basically all the local files). Having to read all of the local files leaves us with some difficult choices:
Choice 1: Save the whole file in memory until we know whether we need to upload it.  I.e. read it to the end, see what the MD5 is, then upload the data that we just read (and have retained in memory). Unfortunately, this approach does not generalize to cases where the amount of data to be processed does not fit in memory.
Choice 2: Read the file again.  This is like choice 1, in that we read to the end to compute the local MD5. But in this case, to avoid the memory issues, we don't retain the data in memory. Instead, if the file needs to be transferred, we read it from disk again, after we have computed the MD5.
Because choice 1 doesn't generalize to all cases, I'm reluctant to incorporate it into the codebase.  (Special cases add complexity and testing burden).  As for choice 2, my feeling its that it might not give you the performance win that you're looking for.  E.g. if your server is an Azure VM, you'll typically find that AzCopy is constrained by disk throughput, not by network throughput.  And choice 2 actually makes the disk constraint worse because we read all files (even those not transferred once) and then we read those that are transferred again. So we read over 100% of the data - i.e. we spend more time in disk reads that we do in the current design.
One place where choice 2 might help would be cases where its an op-premises VM (or physical machine) and the network bandwidth is lower than the disk throughput.  In that case, choice 2 would help.  But I can't see it helping for VMs in Azure, and I'm not sure that the on-premise case is enough to justify the cost and complexity of the feature.
Interested in your thoughts on the above, and the situations where you'd be hoping to use the feature.

I'm not uploading gigabytes of data each time and this generally applies during development where I'm repeatedly uploading the same files with one or two minor changes and validating behavior.  I'm building a static website which is hosted using the Azure Storage Static Website configuration.  I run the static site generation tool which processes all of my templates and re-generates all of the output.  The output folder is completely cleaned to ensure that we're only deploying files which are actually currently part of the output and not just left-overs.
Thankfully, other pass-thru content (images and other media) are not generated so their modification dates don't change, but I still end up having to wait another minute or two during each deployment while every html and css file is uploaded.  Since there's not a mechanism for testing this locally, pushing it up to the storage account is the only way to do so.
I understand that there's going to be SOME additional overhead and I definitely don't think that this needs to be something that's standard for every call.  But I feel like there are still plenty of scenarios (e.g. thousands of very small files) where the overhead of pre-calculating an MD5 to avoid an upload would outweigh the costs of loading it into memory or re-reading the file from disk.  So having it as an opt-in feature would really be a great thing.

@veleek  Are you running AzCopy on an Azure VM?

Or is it on-premises?

I am running AzCopy from my laptop at home.

In my environment I cannot trust file system timestamps, whether it is due to user archiving and unarchiving, copying from another source, or a program mucking with timestamps, etc. Therefore the default behavior of azcopy sync looking at timestamps doesn't work for me, frustratingly.
If azcopy sync had --check-md5 SkipIfNotModified, it would be great for me only if I could get it to ignore the last modified time. So what I really want is a --check-md5 UseMD5InsteadOfModifiedTime. This coupled with sync's --delete-destination flag gives a reliable sync.
We have --put-md5 which is great, but please take MD5 support to the next level so I can have a trustworthy sync that looks at file content and not just time according to a local file system.

Thanks @Agendum.  As you can see from my comments above, this is actually a difficult feature to implement.  For that reason, and the high number of other features in our queue, I'm not sure whether we'll do this one, and if we were to do it, I'm not sure how soon that would be. (Probably not soon, sorry).
If you have your own way of getting file Hashes (e.g. Powershell's Get-FileHash) you might be able to script your own solution for figuring out which files need to be moved.  Then you could pass a list of those files to AzCopy: https://github.com/Azure/azure-storage-azcopy/wiki/Listing-specific-files-to-transfer
I realise that 's not a great solution, but it's the best workaround I can think of at the moment.
cc @veleek

I'd like to add my support on this feature request. This isn't an issue at all when working in Azure but is usually an issue when bringing data from on-premises to Azure. I'm running into a similar problem where I have some corrupted files that were extracted that I need to re-transfer about 170 GB (1.1 million files) from my laptop to Azure Storage. Allowing a user to optionally choose an option which may be slower on Azure with a warning of the slowdown would be useful in cases where the network is the bottleneck.
I understand the limitation of resources for development, can we put this on a low priority queue rather than dropping it completely? I think this option will be quite useful to new users of Azure who are migrating data onto the system.

Same issue here. Using DocFX to build static website, copy files to azure blob and using search indexer. This last one is timing out because all the files get generated again at the start of the flow. Using a different change detection system could resolve the issue we're having.

Adding my voice in support of this feature request.  We use azcopy to bulk upload large data archives (several to tens of terabytes at a time) from on-prem assets to our Azure storage.  Network throughput is by far our biggest bottleneck, even with 1Gbps of upstream bandwidth.  When uploads are interrupted, we struggle with our conflicting need to assure data integrity and our need to manage the time and bandwidth require to re-transmit data that is likely already good.  In our case, reading the data on our local disk to generate a hash for comparison would be well worth the cost to avoid retransmission.

+1

Released in AzCopy 10.17.0

Is this the same as "FailIfDifferent"? Does this use the Azure property Content-MD5 as checksum for the destination blob or does it re-calc that as well?


Optimize jekyll page build

add to _config.yml along with fixing this problem is that there are certain unnecessary files and folders (eg; config.rb, Gemfile, Gemfile.lock and node_modules ) copied over to generated _site folder while running jekyll build. This copying of extra files may further slowdown development process when you run jekyll serve without --no-watch.

I'll push in another PR for the same. :smiley:


Uncaught TypeError: Cannot read property 'getBufferPosition' of undefined

Have linter + linter-php installed
In a PHP file, choose "Linter: next message" (from Package Control or with the shortcut  Ctrl + K - Down
Linter does not do anything and an error is thrown.

The following was the error, seems an issue was not yet created.
Atom Version: 0.176.0
System: linux 3.2.0-75-generic
Thrown From: linter package, v0.11.0
Stack Trace
Uncaught TypeError: Cannot read property 'getBufferPosition' of undefined
At /usr/share/atom/resources/app/src/text-editor.js:1339

TypeError: Cannot read property 'getBufferPosition' of undefined
  at TextEditor.module.exports.TextEditor.getCursorBufferPosition (/usr/share/atom/resources/app/src/text-editor.js:1339:34)
  at LinterView.moveToNextMessage (/home/jelmer/.atom/packages/linter/lib/linter-view.coffee:234:26)
  at atom-text-editor.<anonymous> (/home/jelmer/.atom/packages/linter/lib/linter-view.coffee:126:34)
  at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/usr/share/atom/resources/app/src/command-registry.js:243:29)
  at /usr/share/atom/resources/app/src/command-registry.js:3:61
  at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (/usr/share/atom/resources/app/node_modules/atom-keymap/lib/keymap-manager.js:558:16)
  at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (/usr/share/atom/resources/app/node_modules/atom-keymap/lib/keymap-manager.js:396:22)
  at HTMLDocument.module.exports.WindowEventHandler.onKeydown (/usr/share/atom/resources/app/src/window-event-handler.js:170:20)

Commands
     -0:56.1 core:save (atom-text-editor.editor.is-focused)
     -0:37.1 deprecation-cop:view (atom-workspace.workspace.scrollbars-visible-always.theme-atom-dark-syntax.theme-atom-dark-ui)
     -0:30.3 command-palette:toggle (atom-text-editor.editor.is-focused)
     -0:29.4 core:confirm (atom-text-editor.editor.mini)
     -0:29.3 linter:lint (atom-text-editor.editor.is-focused)
     -0:27.7 command-palette:toggle (atom-text-editor.editor.is-focused)
     -0:26.0 core:move-down (atom-text-editor.editor.mini)
     -0:24.6 core:confirm (atom-text-editor.editor.mini)
     -0:24.5 linter:next-message (atom-text-editor.editor.is-focused)
     -0:14.1 command-palette:toggle (atom-text-editor.editor.is-focused)
  2x -0:12.6 core:move-down (atom-text-editor.editor.mini)
     -0:11.6 core:move-up (atom-text-editor.editor.mini)
     -0:08.8 core:confirm (atom-text-editor.editor.mini)
     -0:08.8 linter:next-message (atom-text-editor.editor.is-focused)
     -0:04.5 pane:split-down (atom-workspace.workspace.scrollbars-visible-always.theme-atom-dark-syntax.theme-atom-dark-ui)
     -0:00.6 linter:next-message (atom-text-editor.editor.is-focused)

Config
{
  "core": {
    "themes": [
      "atom-dark-ui",
      "atom-dark-syntax"
    ],
    "autoHideMenuBar": true
  },
  "linter": {}
}

Installed Packages
# User
advanced-new-file, v0.2.1
browser-refresh, v0.8.3
linter, v0.11.0
linter-php, v0.0.11
minimap, v3.5.6

# Dev
No dev packages

/cc @atom/core

Interesting. I just implemented that command yesterday so it's brand new. Thanks for trying it out :smile:
Does the command work for you at all, or was error an edge case? If this error was an edge case, was there anything unusual about the file you were trying to navigate?

Thanks for reporting, fixed in the next release.

Sorry for late response, I tested it again, seem to be working well now on Windows, will test on Linux later!

Strange.  I just got this error when switching branches.
Atom Version: 1.0.3
System: Mac OS X 10.10.4
Thrown From: linter package, v1.2.4
Stack Trace
Uncaught TypeError: Cannot read property 'getBufferPosition' of undefined
At /opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/q/q.js:128

TypeError: Cannot read property 'getBufferPosition' of undefined
  at TextEditor.module.exports.TextEditor.getCursorBufferPosition (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/src/text-editor.js:1321:34)
  at MessageRegistry.getActiveFileMessagesForActiveRow (/Users/bronson/.atom/packages/linter/lib/messages.coffee:77:12)
  at LinterViews.updateLineMessages (/Users/bronson/.atom/packages/linter/lib/linter-views.coffee:110:38)
  at /Users/bronson/.atom/packages/linter/lib/editor-linter.coffee:23:25
  at Emitter.module.exports.Emitter.emit (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:82:11)
  at TextEditor.module.exports.TextEditor.cursorMoved (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/src/text-editor.js:1591:27)
  at /opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/src/cursor.js:56:31
  at Emitter.module.exports.Emitter.emit (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:82:11)
  at Marker.module.exports.Marker.notifyObservers (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/src/marker.js:270:27)
  at /opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/src/marker.js:65:26
  at Emitter.module.exports.Emitter.emit (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:82:11)
  at Marker.module.exports.Marker.emitChangeEvent (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/text-buffer/lib/marker.js:401:20)
  at MarkerStore.module.exports.MarkerStore.createSnapshot (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/text-buffer/lib/marker-store.js:232:20)
  at TextBuffer.module.exports.TextBuffer.transact (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:762:83)
  at TextBuffer.module.exports.TextBuffer.setTextViaDiff (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:480:19)
  at TextBuffer.module.exports.TextBuffer.reload (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1019:12)
  at /opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1143:26
  at Emitter.module.exports.Emitter.emit (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:82:11)
  at /opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/pathwatcher/lib/file.js:439:40
  at _fulfilled (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/q/q.js:794:54)
  at self.promiseDispatch.done (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/q/q.js:823:30)
  at Promise.promise.promiseDispatch (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/q/q.js:756:13)
  at /opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/q/q.js:564:44
  at flush (/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app.asar/node_modules/q/q.js:110:17)
  at process._tickCallback (node.js:357:13)

Commands

Config
{
  "core": {
    "disabledPackages": [
      "metrics",
      "exception-reporting",
      "wrap-guide",
      "welcome",
      "background-tips",
      "linter-rubocop",
      "package-cop",
      "linter-haml",
      "smart-tab-name",
      "linter-eslint",
      "linter-jscs",
      "linter-jshint",
      "vim-mode",
      "table-edit"
    ],
    "themes": [
      "one-dark-ui",
      "oceanic-reef-syntax"
    ],
    "destroyEmptyPanes": false
  },
  "linter": {
    "subtleLinterErrors": [
      "haml-lint"
    ],
    "lintOnFly": false
  }
}

Installed Packages
# User
atom-ternjs, v0.7.1
color-picker, v2.0.11
cursor-history, v0.4.15
file-icons, v1.6.2
git-log, v0.4.1
highlight-selected, v0.10.1
language-haml, v0.21.0
linter, v1.2.4
linter-coffeelint, v1.0.1
linter-csslint, v0.0.14
linter-erb, v0.1.1
linter-ruby, v0.1.6
oceanic-reef-syntax, v0.6.0
react, v0.12.6
vim-mode-next, v0.57.0
vim-mode-visual-block, v0.2.13
vim-surround, v0.8.0
white-cursor, v0.6.0

# Dev
No dev packages

Just  happened again, seems pretty reliable.  Should this issue be reopened?  Or I can file a new one.


Allow more than 1 TypeByte

I am sure 256 types seems like quite a few implementations, but slowly this is becoming an issue with basecoin aka quark
We define one Tx struct and a TxInner interface that all transactions must implement in every app.  This allows us to very easily marshal and unmarshal both json and binary data, handle nested tx transparently, etc. I am very happy with this.  However.... we currently have 15 tx types in the core modules, and maybe 5 more in planning... plus at least 10 more in implementing elections.  And trying to avoid accidental collisions, rigel and I have been spacing these out a bit.  No real problem so far, but as soon as third-parties start writing modules and defining their own tx types (trackomatron, gaia, basecoin-stake, etc.) the number will get larger and will need to coordinate between multiple authors to avoid collisions. Or have modules that cannot both be installed in the same app due to this issue.
I would like to have 2 type bytes for tx, use the first 12 bits for the modules and the last 4 (last hex digit) for the tx in the repo itself. Maybe even consider 3 bytes... but maybe that is too much.  Anyway, flexibility in our encoding system would be great.
I understand that go-wire is used in many different places in tendermint core, where this limit is not a problem, and they wish to keep 1 byte prefixes, and we must maintain the same binary encoding.
I would propose a system where wire.RegisterInterface maintains the exact same semantics along with the same 1 byte prefix, but there is another function, eg. wire.RegisterLongerInterface(interface{}, prefix int, ...LongerConcreteTypes ) and LongerConcreteTypes allows []byte instead of byte, and asserts that all types have the same length as defined in the call.
This can create and enhanced TypeInfo, that knows how many bytes it should take off for the comparison (as it is registered per interface), and extends ByteToType and TypeToByte.  I would also expand data.Mapper.RegisterImplementation to accept multiple bytes and do the same assertions (all same prefix length)  internally.
In short: func (m Mapper) RegisterImplementation(data interface{}, kind string, b byte) Mapper would become func (m Mapper) RegisterImplementation(data interface{}, kind string, b ...byte) Mapper and drop in compatible with any code that uses it.
If all modules now use this mapper instead of directly calling wire.RegisterInterface, I could change the functionality there directly instead of implementing RegisterLongerInterface

Just noticed that it doesn't appear that kind within RegisterImplementation is used? There to fulfill and interface? I agree that it makes sense to allow for more flexibility by extending the typebytes array. Allowing for layers of typebyte would allow for easier extensibility - aka each zone in a COSMOS hub could have its own typebyte space. It's a bit more clear if we can stick to using the wire.RegisterInterface - We should be able to have a single TB within your proposed LongerConcreteTypes so why not just extend what's already there instead of introducing a whole new interface?

It's used by the json mapper

Please look at the data subdir... not too much and that is the interface I've been porting all code to use.

Is it possible to support sub-types in go-wire yet ? If not, would this be a better approach? It would basically amount to register another interface as a concrete implementation of a type, so you'd need more than one type byte to resolve to a real concrete type

Just cleaning up some open issues: This does not seem true anymore:
https://github.com/tendermint/go-amino#prefix-bytes-to-identify-the-concrete-type


Be able to update the Replicate component at runtime

This might be easier once we have observers, because then I could inspect both the old Replicate and the new Replicate value at the same time, to compute a diff:

clients to which we don't network anymore: send entity despawn
clients that were added to NetworkTarget: send entity spawn + send component insert for every relevant component
per_component_metadata for which we don't replicate anymore: send component remove
per_component_metadata for which we do replicate: send component insert

EDIT:
actually observers won't help with this
Periwink — Today at 2:44 PM
Observers trigger before the actual ECS update; so if I want to update a Component A on entity that as A, the observer would allow me to have access to both the old data (via a Query) and the new data (in the observer trigger)? @James 🦃
Or maybe not, if the ECS change happens first, before the observer commands are executed at the next apply_deferred
James 🦃 — Today at 2:49 PM
No, the observers trigger after an insert and before a remove
The observers run immediately, then don't wait until apply_deferred, but any commands queued by the observer will
You can fetch the inserted component or view the removed component before it is removed but you can't see the value before it's overwritten (although you can implement that behaviour by storing a copy of the value elsewhere and look at that on the next insert)

Should we split up the Replicate component into a bundle of multiple components?

NetworkTarget

Control

Visibility

Hierarchy

Group

TargetEntity

PerComponentNetworkTarget<C>

PerComponentReplicateOnce<C>
(or just PerComponentReplicateMetadata<C>)

it's still relatively ergonomic for the user since they can use the bundle

allows for more modularity when fetching the data that we need

would make things simpler when updating a single sub-set of the component

Sounds good to me, I think it's generally more idiomatic to have small components rather than large ones

Could improve parallelization too


As a visitor, I can sign up to the site.

Create the form to get informations from the usere.
Send informations to the DB
Send a notification the user "Welcome to the origins digital"

Note:Add nimser as a reviewer to this pull request

fixed in #8


Update AUTHENTICATION.md

Updates to console UI description for creating a service account. Added missing general release services to the list.
[closes #472]

:+1:


Add option to select the project within a solution

Currently I have a UWP I want to build from a Branch. Unfortunately in the same solution I have several Xamarin apps, and WPF projects. When I try to build a branch, it fails because it says it cannot find the SDK for some of the WPF projects that I'm building with .net core.
 C:\Program Files\dotnet\sdk\2.2.110\Sdks\Microsoft.NET.Sdk.WindowsDesktop\Sdk not found. Check that a recent enough .NET Core SDK is installed and/or increase the version specified in global.json.
However I just want the UWP project to be built, I don't care about the rest, It would be handy to allow me to select which project to I want to build from a dropdown, otherwise this is unusable as it fails every time I try to build the branch.

Thanks for the suggestion! It looks like this is a duplicate of #296. I recommend voting thumbs up for that one, as it has more visibility.

Sure, that's exactly what I wanted! thanks!


Add Stream Deck+ Support

And the other side of the equation!
This should cover everything necessary to add SD+ bindings to streamdeck-ts and expose it for use everywhere, and should have tests to boot.
Given I put a fair bit of documentation into streamdeck-events rather than here, I tried to keep duplication to a relative minimum while also still keeping this side useful. I'm not too satisfied with the result, but it should be workable especially when combined with type-hinting and official docs (once they're released).

Codecov Report

Merging #26 (bc69565) into main (4000939) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #26   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           10        10
  Lines          143       150    +7
  Branches         7        11    +4
=========================================
+ Hits           143       150    +7

Impacted Files
Coverage Δ

src/Plugin.ts
100.00% <100.00%> (ø)

src/pi/ActionInfo.ts
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

good job. again, thanks a lot for implementing the changes!


"Blueprint" has no attribute "register_blueprint" mypy typing error

When we try to register one blueprint to another blueprint in flask getting an error from mypy:
"Blueprint" has no attribute "register_blueprint" mypy typing error

This shouldn't ideally happen as described in the docs: https://flask.palletsprojects.com/en/2.2.x/blueprints/#nesting-blueprints
Environment:

OS: Ubuntu 22.10
Python version: 3.10.10
Flask version: Flask==2.2.2 Flask-RESTful==0.3.9

Hi @LoopThrough-i-j great to see you reaching out and using Flask. It is a great framework. Are you using the syntax:
app.register_blueprint(<bp_name>)

Also, have you imported Blueprint from flask and created it using:
bp = Blueprint(bp, __name__)

It'll be great to hear an update from you,
Josh

Blueprint.register_blueprint does exist, so if MyPy isn't seeing it then that's an issue with MyPy.

@Optimized-Coder Did you use some AI to write this answer? It makes no sense and feels more like what outsourced first-level tech support would reply to a problem they barely know... In fact, if I paste this issue into ChatGPT I get something more useful than your answer :D

I'm sorry, I'm pretty new to engaging on GitHub. If you have any genuine critical feedback for me it would be very much appreciated @ThiefMaster


OBJ files missing all colours after conversion to UDS

This seems to be an issue with the converter inside of Vault.
The converted OBJ file is stripped of all of its colours and just appears as a white blob.
You then need to turn on edge highlighting just to be able to see any details unfortunately.
The data that I'm working with is LIDAR data that has been meshed inside of CloudCompare and then exported as an OBJ file.
I was able to convert OBJ's to UDS format in Geoverse Convert and they would come through with colours but for some reason the converter in Vault appears to be doing it differently.
The end result looks really bad even with edge highlighting turned on
LIDAR data of a house.zip
LIDAR data of a house-uds version.zip

.

Hi,
Thanks for the thorough bug report! The OBJ you attached has no color or UV information in it:
Created by CloudCompare v2.10-beta
Created 3/28/2019 8:03 AM
v<PHONE_NUMBER>74609375 6705501.862365722656 18.295120239258
v<PHONE_NUMBER>80371094 6705501.866027832031 18.295120239258
...
vn -0.009222226217 0.042012363672 -0.999074518681
vn 0.001016409718 0.041672799736 -0.999130785465
...
g Mesh[32-1-468-146-27.clean] (level 11).part.remaining.clone
f 39//39 38//38 2//2
f 2//2 1//1 39//39
We do support OBJ's with vertex colour information (lines starting with v in the OBJ file will have additional 0-255 numbers after the vertex position), but a texture will give best results (lines starting with f in the OBJ will have a number between the 1st and 2nd / character).
I haven't played with CloudCompare recently enough to offer suggestions on how to export with colour information but at least this is a pointer in the right direction. I'm not sure what went on to get a different result in Geoverse Convert, I wrote the OBJ import on both and neither can get colour information from any other source! :)
Regards
Dave

@CodeWarrior99, we've added native OBJ rendering support in 0.4.0 to handle these small models where lighting is required and there isn't much benefit from converting to UDS (note that I randomly picked a SRID that had a road nearby).

Excellent! :-)
When will the next version be released?

We're just finalising most of it now- this is already in master though.

We are not currently investigating fixing this for conversion to UDS so closing this as its possible to view the OBJ with lighting in Client now.
We will reopen this in future if a model that should be converted to UDS is found and lighting is required.


give a background color to a div

Challenge Name

Issue Description

Browser Information

Browser Name, Version:
Operating System:
Mobile, Desktop, or Tablet:

Your Code

Screenshot

@fordy190 please reopen this thread to add more information about the issue you are experiencing.


FallbackFontTextMeshPro option not working in melonloader

Game: [RJ297937] HolyKnightRicca_v105ja
Melonloader: x64 0.5.2
Autotranslator: MelonMod-IL2CPP-5.0.0
ini file: https://pastebin.com/pWMaDj2D
Error log(melonloader): https://pastebin.com/UQf14tHW
Fallback fontasset bundle: nanumgothicsdf140
Uncensored Mod: MelonLoaderFTHKRTWS
FallbackFontTextMeshPro option works with BepinEx, but not with Melonloader.
I am unable to use BepInEx because the Uncensored mod was developed for Melonloader.
I tried to open the dll file with dnspy. It's a simple mod, but I can't port it because I don't know much about C#.
BepInEx.MelonLoader.Loader didn't work either.
So I would like you to take a look at the problem with MelonLoader.
thank you!

Try this instead.
XUnity.AutoTranslator-MelonMod-IL2CPP-5.0.0.zip

Try this instead. XUnity.AutoTranslator-MelonMod-IL2CPP-5.0.0.zip

It works really well. thank you!


Where to find CMP File Download

Hello,
I am hoping you can point me in the right direction as to how to find the CMP download folder as referenced in step 4. Trying to get this kicked off.

Thanks in advance!

Hi @kdebrino,
Please check the Standard Installation section of the ReadMe document if you want to use the package file as is without any further  customization. Let me know if you need more information. If you want to customize the code then you have to follow the Custom Installation section. In this case you will have to download the entire folder using download option in GitHub. The downloaded folder is the CMP folder that is being referenced in step 4. Thanks.

@kdebrino as Sai mentioned the above NodeJs instructions are for customized deployments where you need to modify the code. If you are looking for the preconfigured / standard package file to load into SharePoint/Teams - that package can be found here in our code source:
https://github.com/OfficeDev/microsoft-teams-apps-champion-management/tree/main/sharepoint/solution
download that file you would then upload and follow the steps in the ReadMe starting here:
https://github.com/OfficeDev/microsoft-teams-apps-champion-management#deploy-your-package-to-sharepoint


feat(airflow): prototype finemapping batch job

New Airflow DAG that calls the susie finemapper step on a list of studyLocus IDs to generate credible sets.
✨ Context
This is an incremental pipeline, so the first 3 tasks involve the operation of generating a list of studyLocus to finemap. Once the difference is computed, we finemap those IDs as a job to Google Batch.

Graph nodes:

get_all_study_locus_ids. Lists the bucket with the clumped study locus IDs and extracts all IDs that we could theoretically finemap based on the filename. A requirement for this step is that clumped study loci are written partitioned by their ID - which is currently not implemented (e.g. gs://genetics-portal-dev-analysis/irene/toy_studdy_locus_alzheimer_partitioned)
get_finemapped_paths. Lists the bucket that contains all credible sets as a result of fine-mapping and extracts the IDs from the filename. Similarly, it is also required that the SLID is part of the filename. This is partially implemented, already. The data is not partitioned, but the ID is used to build the output path.
get_study_loci_to_finemap. Creates a list of IDs based on the difference between get_all_study_locus_ids and get_finemapped_paths.
finemapping_task. The one that interfaces with the Google Batch operator to create one Batch job that runs the Docker container with as many tasks in parallel as studyLoci IDs we have extracted in get_study_loci_to_finemap. The  command run in the container image calls the fine mapping step with the appropriate parameters.

🛠 What does this PR implement

The DAG explained above.
A small change in the logic of SusieFineMapperStep that instead of passing the row of the studyLocus to finemap, it passes the dataframe (containing that one row). This is to prevent incompatibilities between the input data, and the schema (I had the problem that after partitioning the data by SLID and then reading the data, this column was appended at the end)

🙈 Missing

Testing that the logic works after fixing the schema issues. This requires creating a new image.
Fine tuning the resources allocated in the Batch job. This crosses over with the work done by @tskir
Sorting out the input data for this DAG:

First, we need to partitioning the data prior to the finemapping step as required by the get_all_study_locus_ids node. This involves changing ld_based_clumping.py
Then, we have to be mindful that we want to fine map studyLoci from 2 sources: UKBB PPP and GWAS Catalog. So either we run the DAG twice or we put all clumped study loci under the same location.

🚦 Before submitting

[ ] Do these changes cover one single feature (one change at a time)?
[X] Did you read the contributor guideline?
[ ] Did you make sure to update the documentation with your changes?
[X] Did you make sure there is no commented out code in this PR?
[X] Did you follow conventional commits standards in PR title and commit messages?
[X] Did you make sure the branch is up-to-date with the dev branch?
[ ] Did you write any new necessary tests?
[X] Did you make sure the changes pass local tests (make test)?
[X] Did you make sure the changes pass pre-commit rules (e.g poetry run pre-commit run --all-files)?

@tskir feel free to close the PR when it's not useful anymore. The intention from @ireneisdoomed and me was to create a proof-of-concept not to merge these changes

The finemapping DAG has been merged in https://github.com/opentargets/orchestration/pull/10, so I'm now closing this pull request.
Many ideas from it have been very helpful and have been used in my final PR — thank you @ireneisdoomed @d0choa!

@ireneisdoomed I didn't delete the branch in case there's something useful you planned to use there — please delete if not!