text:
ecdsa p-256 and aws kms integration

Implements https://github.com/build-trust/codebase/issues/461.
Replaces #3859.
NB: MPL-2.0 license needs to be allowed (CC: @mrinalwadhwa)
Edit: Removed evercrypt as it pulls in outdated crates cargo-deny is rejecting.

@mergifyio rebase

authors: adrianbenavides twittner

repo: build-trust/ockam


text:
Fix #166

alignment parameter is meant to be forwarded

thanks for catching

source: gharchive/pull-request

repo: buildaworldnet/IrrlichtBAW

license_type: permissive

license_source: bigquery


text:
Missing quotes in git submodule foreach

The sub-command of git submodule foreach is not quoted, which results in a failed working directory preparation with git 2.22.0:
~~~ Preparing working directory
$ cd <builddir>
# Host "github.com" already in list of known hosts at "/var/lib/buildkite-agent/.ssh/known_hosts"
$ git remote set-url origin git@github.com:carologistics/fawkes-robotino.git
$ git submodule foreach --recursive git clean -ffdqx
Entering 'fawkes'
error: unknown switch `f'
usage: git submodule--helper foreach [--quiet] [--recursive] [--] <command>

    -q, --quiet           Suppress output of entering each submodule command
    --recursive           Recurse into nested submodules

fatal: run_command returned non-zero status while recursing in the nested submodules of fawkes
.
⚠ Warning: Checkout failed! exit status 128 (Attempt 1/3 Retrying in 2s)

This occurs on our CentOS 7 buildhost. It seems like this used to work with older git versions (< 2.22.0).
In any case, quoting the command (as suggested by the manpage) should fix this with all versions of git.

+1, we are also facing this. It's an unfortunately consequence of installing both git and buildkite-agent from homebrew (at HEAD), neither of which have versioned taps.

I'll have a look!

source: gharchive/issue

authors: jgavris lox morxa

repo: buildkite/agent

license: mit


text:
Termination policy

The termination policy is currently Default, however I think it should be ClosestToNextInstanceHour- to get the best $ utilisation for when we scale down. The Default policy cares about AZs and launch configurations which probably aren't of concern to ephemeral CI instances

Thanks for the suggestion, that absolutely sounds sensible! If you have a chance could you send through a PR, but if not we'll get to it sometime soon.

authors: mtibben toolmantim

repo: buildkite/elastic-ci-stack-for-aws


text:
API Access Token Code Authorization

[x] Make it work

:shipit:

authors: keithpitt ticky

repo: buildkite/frontend


text:
🛑 GOTO Parking is down

In acb10fd, GOTO Parking (https://gotoparking.ro) was down:

HTTP code: 0
Response time: 0 ms

Resolved: GOTO Parking is back up in e70c6eb.

repo: buligadragos/UpTime

license: MIT

license_source: github-api


text:
🛑 GOTO Parking is down

In 03f4f05, GOTO Parking (https://gotoparking.ro) was down:

HTTP code: 0
Response time: 0 ms

Resolved: GOTO Parking is back up in fa624aa after 9 minutes.


text:
Allow selecting a camera when scanning QR Code

https://github.com/bumi/lightning-browser-extension/issues/195
Can now also be tested from Storybook.

@johnsBeharry do you have a chance to test this?

tried on a few occasions to test this in storybook but I never got it working. should I be testing there or building the extension for this branch?

this is a FF build of the branch: https://wormhole.app/nb0KD#iNMrM9ZY4UDT_RRWQ5to1w

@johnsBeharry is correct. I see that the storybook build on netlify is missing the html5-qrcode.min.js asset.

authors: bumi dylancom johnsBeharry

repo: bumi/lightning-browser-extension


text:
Start adding unit tests for SharedHelpers

Backfilling some unit tests for the Bundler::SharedHelpers module. This PR doesn't add all the unit tests yet as I'd like some feedback on whether I'm on the right track regarding the level of mocking out and the interaction of some of the testee methods with private methods.
Related to discussion at #4195 regarding unit tests.

Awesome!

@RochesterinNYC definitely on the right track! Just let me know if you want this merged now, or you want to continue building on this PR

@segiddins Great! I can wrap up the rest of the unit tests for the SharedHelpers module sometime tonight or tomorrow. I'll keep adding commits to this PR/branch.

Ace!

@homu r+

:pushpin: Commit 6f27c5f has been approved by indirect

:hourglass: Testing commit 6f27c5f with merge 6d29d4b...

:sunny: Test successful - status

:eyes: Test was successful, but fast-forwarding failed: 422 Update is not a fast forward

@homu retry

:hourglass: Testing commit 6f27c5f with merge d8cc3a3...

:broken_heart: Test failed - status

Interesting, what's the difference between the Travis CI build environments that a PR kicks off and the environments that homu uses?

@RochesterinNYC Homu actually builds on Travis, but it builds a merge commit and then fast-forwards. Travis only builds the pull request itself, so it's possible to break master by merging.

Okay, thoughts on how to proceed? Rebase these commits on top of master locally and update the PR? I can try and see if those errors occur locally with the offending ruby and RVM versions as well.

@segiddins any theories about why only 1.9.3 is failing with a frozen string error?
@RochesterinNYC I guess rebase on master and then try running the tests on 1.9.3?

Rebased on master. Running some of the failing specs (like spec/bundler/gem_helper_spec.rb) locally with ruby 1.9.3 all pass successfully. If this isn't flaky behavior of some kind, it seems that it has to be something with the interaction between ruby 1.9.3 and rubygems versions 1.7.2, 1.6.2, 1.5.3?

@RochesterinNYC if you install the latest rubygems with gem update --system, you should then be able to downgrade with gem update --system --version 1.7.2

@RochesterinNYC this is totally not your fault--master was broken. I'll have Homu retry and it should work now.
@homu retry

@homu r+

:pushpin: Commit db93470 has been approved by indirect

:hourglass: Testing commit db93470 with merge 4466cb4...

:sunny: Test successful - status

Gotcha, thanks!

authors: RochesterinNYC homu indirect segiddins

repo: bundler/bundler


text:
Bundler config parseable flag

This PR is continuing on from #4919. This adds an option to bundle config called parseable that prints the value of config without the verbose. Example:
$ bundle config foo --parseable
bar

Closes #4919

bundle config --parseable still isn't parseable

Maybe something like a TSV or CSV? just some sort of structured output. otherwise, using --parseable in those circumstances should raise an exception

bundle outdated has a parseable option ... i don't think it's either TSV or CSV, just w/o headers and maybe fixed-width? Can't recall off-hand, but probably good to go for consistency between the two?

Sounds reasonable!

Ping on this?

Sorry! I've been working on this on and off. Ill give this attention this week.

So i have been continuing to give this some thought and i have come to the conclusion that for bundle config --parseable the output will need to be something on the lines of:
myconfig: local=foo global=bar
myconfig2: local=foo global=bar

A few reasons why:

compatibility and no surprise with the current output of bundle config
1 config per line which works the best for utilities like grep, awk, sed etc

For parseable, would it maybe be better to only print the setting with the highest priority that bundler will actually use?

@segiddins yes absolutely but the current behaviour for bundle config prints each config value separately which i don't want to deviate from ie:
Settings are listed in order of priority. The top value will be used.

foo
Set for your local app (/Users/c/Desktop/Projects/testapp/.bundle/config): "bar2"
Set via BUNDLE_FOO: "bar4"
Set for the current user (/Users/c/.bundle/config): "bar3"

I wanted to keep the behaviour of --parseable in line with the output bundle config and not surprise users with a completely different piece of behaviour on top what's currently there.
For Bundler 2 i was thinking we could drop the "verbosity" of bundle config to make it behave like --parseable and only show the config with the highest priority, ie:
> bundler2 config
foo=bar

Given bundle config --parseable doesn't exist yet, we can choose the best behavior for it, rather than deferring to existing output

@indirect can i just get your thoughts about the past few comments to see if you agree with @segiddins ?

Yeah, I think for machine-readable output the useful thing to print is the actual settings! And since it's a new feature, I'm happy to jump straight to the ideal behavior. 👍

thanks @indirect, @segiddins ill update that behaviour then.

well nothing different from existing behaviour, i have a test for this at https://github.com/bundler/bundler/pull/5306/files#diff-0bbd2388477a861ecd2eb9aed2ff40a7R140

@indirect r?

I think maybe in the interests of consistency (and parsability), every single output from --parsable should be the same format? @colby-swandale @segiddins, how do you feel about always printing key=value, and treating any passed key names as filters on the list that is printed, rather than changing the output? Similarly, I think I would expect setting a new value with --parsable to result in printing key=newvalue, as confirmation that the value was set.

Similarly, I think I would expect setting a new value with --parsable to result in printing key=newvalue, as confirmation that the value was set

this is different from what bundle config does now, but seems reasonable?

every single output from --parsable should be the same format

yeah, I can get behind this

diff --git a/lib/bundler/cli/config.rb b/lib/bundler/cli/config.rb
index 8ad7f12fa..ff031899a 100644
--- a/lib/bundler/cli/config.rb
+++ b/lib/bundler/cli/config.rb
@@ -33,7 +33,12 @@ module Bundler
       end

       if args.empty?
-        return Bundler.ui.info(Bundler.settings[name]) if options[:parseable]
+        if options[:parseable]
+          if value = Bundler.settings[name]
+            Bundler.ui.info("#{name}=#{value}")
+          end
+          return
+        end

         confirm(name)
         return
diff --git a/spec/commands/config_spec.rb b/spec/commands/config_spec.rb
index 030a85ff6..33d43b2a8 100644
--- a/spec/commands/config_spec.rb
+++ b/spec/commands/config_spec.rb
@@ -139,6 +139,7 @@ RSpec.describe ".bundle/config" do

     it "saves with parseable option" do
       bundle "config --global --parseable foo value"
+      expect(out).to eq("")
       run "puts Bundler.settings['foo']"
       expect(out).to eq("value")
     end
@@ -256,14 +257,14 @@ RSpec.describe ".bundle/config" do
       bundle "config foo local"
       bundle "config foo --parseable"

-      expect(out).to eq "local"
+      expect(out).to eq "foo=local"
     end

     it "can print global config" do
       bundle "config --global bar value"
       bundle "config bar --parseable"

-      expect(out).to eq "value"
+      expect(out).to eq "bar=value"
     end

     it "preferes local config over global" do
@@ -271,7 +272,7 @@ RSpec.describe ".bundle/config" do
       bundle "config --global bar value"
       bundle "config bar --parseable"

-      expect(out).to eq "value2"
+      expect(out).to eq "bar=value2"
     end
   end

@indirect I think that does what you want?

Not positive, but the tests make it look like it does? @colby-swandale, feel free to add this to your PR and then show us some example invocations and output!

› dbundler config --parseable foo bar
foo=bar
› dbundler config --parseable foo bar2
foo=bar2
› dbundler config --parseable foo
foo=bar2
› dbundler config --parseable foo1 bar
foo1=bar
› dbundler config --parseable
foo=bar2
foo1=bar
› dbundler config --parseable --delete foo
› dbundler config --parseable foo

looks good to me! 👍  do any of you have an idea of whether or not we should exit > 0 if the user tries to get an unset config? or should we exit 0 with no output?

Exit 0 with no output seems reasonable to me?

i agree, exit 0 with empty output.

@segiddins r?

@bundlerbot r+

authors: chrismo colby-swandale indirect segiddins


text:
Better code coverage

What was the end-user problem that led to this PR?
The problem was that we are using an out of date solution for code coverage and that might cause issues or inaccuracies in the future.
What was your diagnosis of the problem?
My diagnosis was that the codeclimate gem has been deprecated in favor of an external executable.
What is your fix for the problem, implemented in this PR?
My fix is to replace the code coverage setup with a modern one.
Why did you choose this fix out of the possible options?
I chose this fix because it's what codeclimate recommends.

This one should be ready for a review now, in case someone wants to have a look. Not sure what I did but the codeclimate checks got enabled. The regular one about "quality" I would remove it, but the ones about coverage might be interesting to keep?

Ok, so I noticed that our current coverage is wrong and completely misleading. It should be much higher than 73%, which is what the badge currently says.
This is due to most specs in bundler running under subprocesses, and thus not getting coverage because of simplecov not being available there. I fixed this but it is superslow and things time out in Travis. I'm not sure whether the slowness is related to the overhead of simplecov, or to the high number of coverage reports that need to be merged (one per subprocess).
I don't want to spend any more time on this, so I would personally completely remove simplecov until we have a correct solution for tracking coverage because the current situation is just misleading.

@deivid-rodriguez iirc we added the coverage badge as part of our push to implement unit tests. way back in the day, maybe 5 years ago, we only had subprocess integration tests, and that meant we often ran into bugs that could have been caught by unit tests. we used the coverage number to track a lot of added unit tests, covering more and more of the code base with tests that were much faster to run and covered a lot more edge cases than the very slow integration tests.
I don't really have an opinion one way or another about the coverage badge, so I'm fine with removing it now that it has served its purpose to track and encourage adding lots of unit tests that we didn't have before.

I see... it's interesting to see what purpose it served. It's also good that I don't think we're currently showing a coverage badge anywhere right now, so this is only misleading for developers using simplecov locally, not for other users visiting the repo.
I don't have a strong opinion on removing it either. If someone finds the current setup still useful (for example, for observing the increases when adding coverage through tests that don't spawn subprocesses), we can keep it. I can leave this PR there in case future me or anyone else wants to investigate why the setup here makes tests so unbearably slow. Or I can go back to the previous version of the PR that only migrated to the new coverage tool by codeclimate, without attempting to make coverage tracking actually correct.

I'm going to close this and remove coverage tracking for the time being instead. Doing that should make the repository merge easier, since it's one less issue to care about when merging both CIs.

authors: deivid-rodriguez indirect


text:
Как получить nerus.jsonl для тренировки модели?

Собственно вопрос в шапке.
Тривиальным ответом, наверное, было бы: конвертировать из исходника:
spacy convert nerus.conllu -t 'jsonl' > nerus.jsonl
Но, непонятно что делать с токенизатором, т.к. правила токенизации для встроенного spacy токенизатора и nerus.conllu отличаются.
Был бы признателен за ссылку или пример скрипта конвертации nerus.conlluв nerus.jsonl.

Ну появится один процент ошибок из-за неправильной токенизации. Забить на это пока. Теоретически, там есть способ сматчить токенизации, но это надо глубоко копать.

authors: buriy sbushmanov

repo: buriy/spacy-ru


text:
Reply to a comment is open to un-authenticated users

should show a notification like normal comment to a post

Closing this issue, it's been solved already.

repo: busyorg/busy


text:
🛑 take01x.okinawa is down

In efdf075, take01x.okinawa (https://www.take01x.okinawa) was down:

HTTP code: 403
Response time: 2005 ms

Resolved: take01x.okinawa is back up in be674cb.


text:
Support for .Net Standard20

Updated all projects other than the unit test project to .Net Standard 2.0. Note this breaks compatibility with .Net Framework <4.7.
Updated the unit test project to .Net Framework 4.7.1 since UT cannot be done from a netstandard project. All UT is passing.
Had to remove two methods form EmitHelper, please review. Work left: Update version number and release nuget package. Can you help with this?

@benskid thanks for this. Would you mind I add you as a collaborator on NuGet so that you can build and publish an update version?

The changes LGTM btw.

@benskid thanks for this. Would you mind I add you as a collaborator on NuGet so that you can build and publish an update version?

Sure, that'd be fine.

Thanks, what is your nuget email?

bernarddijk@gmail.com
On Wed, May 13, 2020 at 4:24 PM Buu Nguyen notifications@github.com wrote:

Thanks, what is your nuget email?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/buunguyen/fasterflect/pull/11#issuecomment-628225955,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABIV2ZTNPZAML2CGSWOGPYLRRL6XJANCNFSM4M65KWEA
.

Is your NuGet username benskid?
After you build the package and before publishing, would appreciate if you send the PR with all the changes so that the repo is sync'ed.
Please bump up the major version since this is a breaking change.
Thanks again for working on this.

My Nuget username is bernarddijk. Changes are in the commit above.

Thanks. I've just added your account to Nuget.

Also added you as collaborator of this repository.

I've just added your account to Nuget.

Not that I can tell; I tried uploading the updated package but was unable. Can you double check?

I think you have to accept the invitation. There should be an email sent to the address associated with your Nuget.

authors: benskid buunguyen

repo: buunguyen/fasterflect


text:
🛑 PSR Aster 1 is down

In 2dfc261, PSR Aster 1 (https://cloud.tymly.in/status/1059) was down:

HTTP code: 521
Response time: 26042 ms

Resolved: PSR Aster 1 is back up in 3ccd554.

repo: bvenkysubbu/tymlymonitor


text:
🛑 Nitesh Flushing Meadows Block A is down

In 9529216, Nitesh Flushing Meadows Block A (https://cloud.tymly.in/status/1053) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Nitesh Flushing Meadows Block A is back up in 4224d4f.


text:
🛑 Ruchira Lilium v2 is down

In 4331e4a, Ruchira Lilium v2 (https://cloud.tymly.in/status/1048) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ruchira Lilium v2 is back up in d3ef4b1.


text:
🛑 Madhuban Brindavan B Block is down

In 3fd1ba5, Madhuban Brindavan B Block (https://cloud.tymly.in/status/1136) was down:

HTTP code: 521
Response time: 20228 ms

Resolved: Madhuban Brindavan B Block is back up in bee0356.


text:
🛑 Dasta Concerto Basement is down

In c72d66e, Dasta Concerto Basement (https://cloud.tymly.in/status/1138) was down:

HTTP code: 521
Response time: 20250 ms

Resolved: Dasta Concerto Basement is back up in a3a9276.


text:
🛑 Prakruthi Villas Sarjapura is down

In be8221e, Prakruthi Villas Sarjapura (https://cloud.tymly.in/status/1058) was down:

HTTP code: 521
Response time: 230 ms

Resolved: Prakruthi Villas Sarjapura is back up in 86ead1a.


text:
🛑 Prakruthi Villas Sarjapura is down

In 7bb8e99, Prakruthi Villas Sarjapura (https://cloud.tymly.in/status/1058) was down:

HTTP code: 521
Response time: 228 ms

Resolved: Prakruthi Villas Sarjapura is back up in 990166d.


text:
🛑 Trifecta Esplanade B Block is down

In b2c1afd, Trifecta Esplanade B Block (https://cloud.tymly.in/status/1154) was down:

HTTP code: 521
Response time: 236 ms

Resolved: Trifecta Esplanade B Block is back up in 66324f1.


text:
🛑 SBB Touchstone B Block is down

In 2bf9d7a, SBB Touchstone B Block (https://cloud.tymly.in/status/1018) was down:

HTTP code: 521
Response time: 20223 ms

Resolved: SBB Touchstone B Block is back up in 57c8ea3.


text:
🛑 SMD Altezz Block A is down

In 8ebe498, SMD Altezz Block A (https://cloud.tymly.in/status/1175) was down:

HTTP code: 521
Response time: 21016 ms

Resolved: SMD Altezz Block A is back up in 9e9a4d5.


text:
🛑 Casa Gopalan Block B Lift is down

In 214a18f, Casa Gopalan Block B Lift (https://cloud.tymly.in/status/1005) was down:

HTTP code: 521
Response time: 225 ms

Resolved: Casa Gopalan Block B Lift is back up in 87f1b82.


text:
🛑 Trifecta Esplanade C Block is down

In 586915c, Trifecta Esplanade C Block (https://cloud.tymly.in/status/1155) was down:

HTTP code: 521
Response time: 20236 ms

Resolved: Trifecta Esplanade C Block is back up in e5d51eb.


text:
🛑 White Breeze 2 is down

In ca49063, White Breeze 2 (https://cloud.tymly.in/status/1097) was down:

HTTP code: 521
Response time: 251 ms

Resolved: White Breeze 2 is back up in 72dd153.


text:
🛑 Trifecta Esplanade P Block is down

In faae747, Trifecta Esplanade P Block (https://cloud.tymly.in/status/1017) was down:

HTTP code: 521
Response time: 20242 ms

Resolved: Trifecta Esplanade P Block is back up in cb419cd.


text:
🛑 Prakruthi Villas Sarjapura is down

In e6ae24c, Prakruthi Villas Sarjapura (https://cloud.tymly.in/status/1058) was down:

HTTP code: 521
Response time: 207 ms

Resolved: Prakruthi Villas Sarjapura is back up in f45e61a.


text:
🛑 Trifecta Esplanade O Block is down

In 2a5f31c, Trifecta Esplanade O Block (https://cloud.tymly.in/status/1166) was down:

HTTP code: 521
Response time: 20236 ms

Resolved: Trifecta Esplanade O Block is back up in f46f9fd.


text:
🛑 SMD Altezz Block B is down

In af6f0e1, SMD Altezz Block B (https://cloud.tymly.in/status/1176) was down:

HTTP code: 521
Response time: 20232 ms

Resolved: SMD Altezz Block B is back up in 8cb15a4.


text:
🛑 Dasta Concerto Basement is down

In 3f1fc92, Dasta Concerto Basement (https://cloud.tymly.in/status/1138) was down:

HTTP code: 521
Response time: 21648 ms

Resolved: Dasta Concerto Basement is back up in a1016a5.


text:
🛑 Prakruthi Villas Sarjapura is down

In b7242d9, Prakruthi Villas Sarjapura (https://cloud.tymly.in/status/1058) was down:

HTTP code: 521
Response time: 227 ms

Resolved: Prakruthi Villas Sarjapura is back up in 9819e61.


text:
🛑 Trifecta Esplanade N Block is down

In d9f7c66, Trifecta Esplanade N Block (https://cloud.tymly.in/status/1165) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Trifecta Esplanade N Block is back up in 8e113d9.


text:
🛑 Brigade Cosmopolis Clubhouse End is down

In 316efed, Brigade Cosmopolis Clubhouse End (https://cloud.tymly.in/status/1145) was down:

HTTP code: 521
Response time: 20244 ms

Resolved: Brigade Cosmopolis Clubhouse End is back up in cfc403b.


text:
🛑 SBB Touchstone A1 Block is down

In d900031, SBB Touchstone A1 Block (https://cloud.tymly.in/status/1186) was down:

HTTP code: 521
Response time: 20230 ms

Resolved: SBB Touchstone A1 Block is back up in acea08c.


text:
🛑 SMD Altezz Clubhouse is down

In 81d3abe, SMD Altezz Clubhouse (https://cloud.tymly.in/status/1178) was down:

HTTP code: 521
Response time: 227 ms

Resolved: SMD Altezz Clubhouse is back up in ea34313.


text:
🛑 Trifecta Esplanade O Block is down

In 3d47507, Trifecta Esplanade O Block (https://cloud.tymly.in/status/1166) was down:

HTTP code: 521
Response time: 260 ms

Resolved: Trifecta Esplanade O Block is back up in 344b1a4.


text:
🛑 Mahaveer Varna B3 is down

In c403ea7, Mahaveer Varna B3 (https://cloud.tymly.in/status/1086) was down:

HTTP code: 521
Response time: 262 ms

Resolved: Mahaveer Varna B3 is back up in c9dfb2d.


text:
🛑 Trifecta Esplanade Multipurpose Hall is down

In 8a6fc9f, Trifecta Esplanade Multipurpose Hall (https://cloud.tymly.in/status/1169) was down:

HTTP code: 521
Response time: 20246 ms

Resolved: Trifecta Esplanade Multipurpose Hall is back up in 619d2b7.


text:
🛑 Sai Gardens Community Hall is down

In 69ea261, Sai Gardens Community Hall (https://cloud.tymly.in/status/1073) was down:

HTTP code: 521
Response time: 241 ms

Resolved: Sai Gardens Community Hall is back up in 94e149f.


text:
🛑 Wilson Vintage 2 is down

In a9303b2, Wilson Vintage 2 (https://cloud.tymly.in/status/1038) was down:

HTTP code: 521
Response time: 20233 ms

Resolved: Wilson Vintage 2 is back up in d43bc9e.


text:
Duplicate exif values (specifically for Orientation)

Some images, it seems from some older iphones, may contain duplicate exif tags for Orientation, which result in incorrectly rotated images.
The fix seems to be to use the first exif tag found, instead of the last one found.
For example, exiftool shows the correct orientation (1) however, exif-parser shows Orientation 6 for this image:
https://s3.amazonaws.com/dev-sgs-source-images/WNYREIS/B/4/B471754/orig-2-12_Plum_Creek-Ellicottville-NY-14731.jpeg

Great, thank you for this. Could you modify the check to use hasOwnProperty though please?

authors: bwindels kminkler

repo: bwindels/exif-parser


text:
H6078 39% Brightness

What issue do you have? Please be as thorough and explicit as possible.
When I set 100% brightness on my H6078 lamp in Govee app, Homekit says 39% via Hoobs Log.
Details of your setup.

Do you use (1) Homebridge UI-X (2) Homebridge CLI or (3) HOOBS?
Hoobs
Which version of Homebridge/HOOBS do you have?
Hoobs 4.3.0
Homebridge 1.6.0
Which platform do you run Homebridge/HOOBS on (e.g. Raspberry Pi/Windows/HOOBS Box)? Please also mention your version of Node.js/NPM if known.
Hoobs box
Which version of this plugin (homebridge-govee) do you have? Has the issue started since upgrading from a previous version?
10.3.0
Which Govee devices do you have that are causing issues? Please include product models if applicable.
H6078

Please paste any relevant logs below.

1/17/2024, 5:20:19 PMHue Bridge NewGovee[Floor Lamp] current colour [4600K / 217M].
1/17/2024, 5:20:25 PMHue Bridge NewGovee[Floor Lamp] current brightness [20%].
1/17/2024, 5:20:30 PMHue Bridge NewGovee[Floor Lamp] current brightness [39%].

https://github.com/bwp91/homebridge-govee/wiki/Common-Errors

Thank you. Problem solved.


text:
fix: dark theme

Types of Changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

[ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
[ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] My change requires a change to the documentation
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] All new and existing tests passed

Description
[Place a meaningful description here.]

:tada: This PR is included in version 6.13.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: bylapidist/components


text:
Fix user hook issues #384 #385

Execute AfterTestCaseUserHook independent from user hook
The execution of AfterTestCaseUserHook was dependent of the result of
the user hook. If the user hook failed for some reasons the
AfterTestCaseUserHook was never executed. This has been fixed that
AfterTestCaseUserHook is always executed independent of the user hook
result.

Remove unused ExecuteUserHook return value
After 38133d6 (Execute AfterTestCaseUserHook independent from user hook,
2023-01-24) the return value of ExecuteUserHook is no longer used in the
code. As such that it is removed completely from this function.

Skip test case end user hook if test case skipped
The user hooks for test case begin and end are now only then executed if
the test case itself is planed for execution.

Fix #384
Fix #385

Review:
In 		case IUTF_TEST_CASE_BEGIN_CONST: we still have
			if(!skip)
				TestCaseBegin(name)
				ExecuteUserHook(name, userHook, procWin, HOOK_LEVEL_TEST_CASE)
			endif

which I think is also something we want to fix as TestCaseBegin should also always be executed.

@t-b

which I think is also something we want to fix as TestCaseBegin should also always be executed.

This could be part of a new issue. TestCaseBegin is executing the following things:

Create new unique temp datafolder
log to output that a test case is started

I don't think that we need this for skipped test cases (especially the log output).

@Garados007 Thanks, makes sense.


text:
Support bindings wrapper crates that can be used in component implementation crates

This is a continuation of #75, which exposes the use case. Quoting @peterhuene here:
          For the feature request, I think it would be along the lines of:

Allow component metadata in lib packages that aren't cdylib; only generate bindings.
Do not attempt to componentize the output of such packages (i.e. there is no .wasm output).
Ensure that linking in multiple custom sections containing wit-bindgen metadata sourced from those rlibs is properly combined when componentizing the final component (i.e. the cdylib or bin package that link the rlibs).

Originally posted by @peterhuene in https://github.com/bytecodealliance/cargo-component/issues/75#issuecomment-1532045573

Adding in my use case here. I have a need to make a library that wraps some wasi:http functionality for use in multiple (Rust) components. Specifically I need to implement a replacement http-connector for an SDK I would like to use that is not by default not functoinal in wasm/wasi. At the moment I can't see any way of doing that beyond making my library a kind of no-op component. It would be ideal if I could somehow import the wasi:http functions into my library without having to jump through the build hoops of having a stubbed component for it.

I have a use case which I think is hitting this same problem. I would like to implement the same component from several crates but share utility code between them. Having the bindings redefined in each crate makes the types impossible to share (I think) so I need them in a separate crate that all the others can import.
For what it's worth I was able to make that work with a bit of hand tweaking:
I created a shared_bindings crate in my workspace using cargo component new --lib shared_bindings, setup the correct .wit file and generated the bindings with cargo component build then modified the lib.rs to simply export the bindings:
#[allow(warnings)]
mod bindings;

pub use bindings::*;

And modified bindings.rs to make the export! macro public as well as change the Cargo.toml file to make the crate a regular rlib. I was then able to create my implementation crates with cargo component new --lib as usual but instead of declaring the bindings module from the local bindings.rs I imported the shared_bindings crate and used those definitions. cargo component --build works and creates usable wasm files, at least in my fairly simple test case.
Not particularly ergonomic as is but it seems to indicate that the changes to the tooling needed to support this are pretty minimal.

authors: alec-deason bnjbvr landonxjames

repo: bytecodealliance/cargo-component


text:
Segmentation fault on module instance attempting an invalid free(3)

Host configuration
$ uname -a
Linux xavier-midokura 5.14.0-1059-oem #67-Ubuntu SMP Mon Mar 13 14:22:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:        22.04
Codename:       jammy

$ /opt/wasi-sdk-20.0/bin/clang --version
clang version 16.0.0
Target: wasm32-unknown-wasi
Thread model: posix
InstalledDir: /opt/wasi-sdk-20.0/bin

Commit
b5022015fce7dcc97f4ad00997b09448769a7f89
Description
The example attached below shows how an invalid call to free(3) raises a segmentation fault on the host runtime:
#include <stdlib.h>
#include <stdint.h>

int main()
{
    free((void *)(intptr_t)(void *)1);
    return EXIT_SUCCESS;
}

The project was configured and built with wasm-micro-runtime's default options:
$ cmake -B build
$ cmake --build build/ -j$(nproc --all)

$ gdb --args ./build/test build/badfree.wasm
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./build/test...
(No debugging symbols found in ./build/test)
(gdb) start
Temporary breakpoint 1 at 0x9e08
Starting program: /home/xavier/badfree/build/test build/badfree.wasm
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
c
Temporary breakpoint 1, 0x000055555555de08 in main ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00005555555876b5 in wasm_interp_call_func_bytecode ()

Notes

The segmentation fault goes away if the invalid call to free(3) is removed.
The segmentation fault goes away if wasm-micro-runtime is configured with -DWAMR_BUILD_FAST_INTERP=0.
Whereas only a minimal reproducible example is attached on this ticket, we suspect similar issues are causing our proprietary application, which makes use of AOT modules and XIP, to also raise a segmentation fault and crash.

Tarball
badfree.tar.gz

$ gdb --args ./build/test build/badfree.wasm

can you share this badfree.wasm binary?

can you share this badfree.wasm binary?

The build system already builds badfree.wasm from badfree.c, but I will provide it here anyway. GitHub does not allow uploading .wasm files, so I had to create a tarball for it:
badfree-wasm.tar.gz

ah, i haven't noticed your tarball contains the embedder and build framework.
does it crash if you run it w/o gdb?
it's normal for wamr to trap SEGV.

does it crash if you run it w/o gdb?

No, it keeps running. It does crash on our proprietary application, but we still need to investigate more whether wasm-micro-runtime is responsible for this.

it's normal for wamr to trap SEGV.

Could you please provide a rationale? As I explained above, removing the invalid call to free(3) fixes the SEGV. I also tested with:

wamr traps SEGV to detect out-of-range access to linear memory and translate it to a wasm-level trap.
you can disable the optimization with WAMR_DISABLE_HW_BOUND_CHECK=1 if you want.
or, maybe you might want to change the debugger behavior. on lldb, you can use process handle to configure how to handle signals. i guess gdb has an equivalent.

#include <stdlib.h>
#include <stdint.h>

int main()
{
    int *a = malloc(1);
    free(a);
    return 0;
}

And:
#include <stdlib.h>
#include <stdint.h>

int main()
{
    free(NULL);
    return 0;
}

None of these raised a SEGV.

because they don't perform out-of-range accesses in the first place?

repo: bytecodealliance/wasm-micro-runtime


text:
Kill Recipes With Fire 🔥

(Really a meta-issue about the meta-crate!)
Nobody likes Recipes. They were supposed to contain factored-out fields of the encodings. But they're mostly one indirection layer that's hard to understand, that needs to be explained to newcomers, and doesn't solve the factoring out problem ideally. For instance, if you want to use one recipe, but just one register allocation constraint differs from the one you're looking at, you'll need to duplicate it and change the one constraint. Other things that are always unclear are whether an instruction/ISA predicate should be attached to an Encoding or to the underlying Recipe.
Let's kill recipes with fire. There's been discussions about this, and a general agreement that it's the right thing to do: it'll make the code easier to understand, more straightforward, and it'll be more pleasant for contributors in general.
The general plan is backed by the following idea:

take a subset of related fields in the Recipe
put them in the Encoding instead
rinse and repeat step 1 until there's nothing anymore in the Recipe
???
fun and profit

I've thought about this, and I think the following groups can be done in chunks, so they can serve as divides of the work that's needed here:

[ ] On x86, have the REX byte emission be a runtime decision in the binemit code, rather than a different encoding. That's bytecodealliance/wasmtime#1130.

[ ] Once that's done, replace x86's Template by helper functions that take an Encoding and tweak it to return a new encoding.

[ ] Move ISA and instruction predicates over to Encoding (This is likely to make legalization slightly faster, since the ISel interpreter is able to deduplicate tests for a given pair of (ISA, instruction) predicates attached to several encodings.)

[ ] Then we can simplify code in the ISel interpreter to not store and check recipe predicates.

[ ] Move register allocation constraints over to Encoding; these are operands_in/operands_out right now, giving constraints to Value inputs and outputs of a given Instruction.
[ ] Move binemit code + size computation information over to Encoding (base_size/compute_size/branch_range). Note (I think) we don't need to move the format field, because an Encoding is attached to an Instruction that has its own format. (Because of recipes, one could attach different formats to the Instruction / Encoding, causing a runtime error in the build script. Good riddance!)

[ ] Create an enum for binemit functions, so they can still be shared across Encodings.
[ ] Use enums instead of plain function pointers for compute_size, to avoid indirect calls in the codegen crate.
[ ] (Bonus) Find a way so binemit function bodies are compiled as part of the meta crate itself (macro?).

[ ] Move clobbers_flags to the Encoding.

Some of these items might not be doable as I expect; I tried to imagine what the could would ideally look like, but the reality of how things are in Cranelift may have us go down a different road.
Each step will imply some work in the codegen crate too, to make sure it's still working properly, as well as opportunities for simplifications. I haven't put items for each simplification, because it's somewhat unclear in general what these could be, but they may exist. It'd be nice that each step belonged to its own PR (substeps can go in commits), to avoid boiling the ocean at once ;)

The new backend framework doesn't use recipes.

Indeed; we might as well close this one now!

authors: bjorn3 bnjbvr cfallin

repo: bytecodealliance/wasmtime


text:
Cannot install python wasmtime on Alpine OS docker container

Cannot install python wasmtime on Alpine OS docker container
I think this has something to do with this: https://github.com/docker-library/docs/issues/904
Getting
ERROR: Could not find a version that satisfies the requirement wasmtime (from versions: none)
ERROR: No matching distributions found for wasmtime

Thanks for the report! At this time we only support glibc binary releases, and to install on Alpine you'll need to compile from source against musl.

If it helps as well, here's an example of how to build it in alpine:
FROM alpine

# Install build tools
RUN apk add musl-dev g++ curl git

# Install nightly Rust
ENV CARGO_HOME=/cargo RUSTUP_HOME=/rustup PATH=$PATH:/cargo/bin
RUN curl https://sh.rustup.rs | sh -s -- -y --default-toolchain=nightly

# Download and build wasmtime, note that we configure the musl target for
# dynamic linkage here instead of the default static.
RUN git clone https://github.com/bytecodealliance/wasmtime --recursive
WORKDIR /wasmtime
ENV RUSTFLAGS=-Ctarget-feature=-crt-static
RUN cargo fetch
RUN cargo build --release

# Download python and such to build the python extension
RUN apk add python3
RUN pip3 install setuptools wheel setuptools-rust
RUN cd crates/misc/py && python3 setup.py bdist_wheel

Thanks for the tip!

I think this can be closed. If not at least it should be moved to https://github.com/bytecodealliance/wasmtime-py.

Indeed yes I think the wasmtime-py bits have changed enough that this is no longer relevant as-is.

@alexcrichton is this answer still true?  I had opened https://github.com/bytecodealliance/wasmtime-dotnet/issues/82 this morning, but further investigation revealed it was not an issue specific to the dotnet build as I can reproduce the same behavior with python.

That is probably the same kind of error. However it is something that needs to be separately fixed for both. For example by adding a new build for musl based systems.

Yes the wasmtime-py extension and the Wasmtime repository do not have precompiled artifacts for musl, only for glibc.

authors: alexcrichton bjorn3 sharksforarms willhausman


text:
x64: Add non-SSE4.1 lowerings of ceil/trunc/floor/nearest

This commit adds lowerings that work with SSE2 for CLIF ceil, trunc, floor, and nearest instructions over vectors. To get these working insertlane for float vectors was also implemented for non-SSE4.1 instructions as well.
Note that the goal of these lowerings is not speed but rather "it works", so the decompose-to-call-libcalls logic for vector is probably horrendously slow but should at least be correct.

I'll also note that this doesn't enable the runtest for insertlane yet because there are other lowerings that use SSE4.1 instructions but a future commit will enable the insertlane test for testing without SSE4.1

Curious - is this just for testing or are there important users that only have SSE2? Even low-power x86(32/64) CPUs have had SSE4 for a very long time, and the standard standard was written with SSE4 in mind, web implementations don't support anything lower. In case someone would try to accelerate their code using instructions in this PR on SSE2 machine they are likely to get surprised.

Just for testing and completeness. We occasionally get reports about users getting an error message that their machine didn't support SSE4.2 which was the basline required by Wasmtime originally. Part of this is on Wasmtime since we require SSE4.2 even if the module doesn't actually use simd instructions and that error could probably be improved by first detecting SIMD and then requiring SSE4.2 or something like that.
Otherwise though I was basically just curious if it was even possible to take the requirement from SSE4.2 to SSE2. I wanted to learn x64 a bit more and the various instructions and it ended up not being too bad and it fits well in the instruction selection framework that Cranelift has, so I figured I'd land it.
My guess though is that this'll only be here for compatibility in niche cases. I definitely have no plans myself to use work like this to shape future standards or anything like that, I think that the SSE4.2 baseline is quite reasonable and well thought out.

@penzn FWIW, the current discussion on this and Alex's work were spawned by a downstream user trying to run Wasmtime on a Penryn-era (Core 2) machine a month or so ago, so these users do still exist, even if rarely (I'm not finding the issue at the moment, but all the related ones are linked from #3810, and we've had pretty extensive discussions on that cluster of issues over the past 1.5 years). It's also just nice to be able to say that we support our full feature set on any x86_64 machine (i.e. only SSE2), and dynamically detect the presence of better options (almost always switch to our SSE4.2 lowerings when available), rather than the other way around where we have a dynamically-detected error path or a "hole" in our support matrix. Wasm is all about portability, after all!

Some instructions were added only because 4.1/4.2 support is assumed. Here is one example, also see notes from the meeting that approved it. On the other hand adding fallbacks makes sense.
The tricky part of SIMD is that it needs to be fast as well as correct, you probably don't want to get into a situation when someone would accelerate their code using SIMD operations only to find out it got slower (probably even worse if compiler would quietly do it for them). Performance is pretty hard to specify precisely, criteria for adding instructions was something along the lines of "no slowdown, speedup for at least one platform" (i.e. swizzle).

Right, and that came up in earlier discussions here too. From my perspective at least, it makes sense to tune the feature for newer hardware (and we do), but it kind of also sucks to just abandon users with old hardware completely. Given the choice between "user with 2007 laptop cannot run Wasmtime at all" and "user with 2007 laptop can run Wasmtime, but it's slow just like everything else on this machine" I think we'll take the latter :-)

authors: alexcrichton cfallin penzn


text:
Feature: Sum of total recieved and expected.

Could we get a sum total of received/expected so we can get total efficiency?
Cheers
ooc

I require this too so I'll take this

Done:
https://github.com/c00w/bitHopper/pull/468
c00w I couldn't find it from backend though but I solved it using javascript which should actually be even more lightweight since totals get calculated on the client side even though it shouldn't really matter.
I guess eventually this should be rewritten to use backend though for optimization but right now it is very fast and works well.

This can be closed now

Thanks sdogi!

authors: organofcorti sdogi


text:
Feat/setup ubuntu

Summary

use fish 3.4.1 and update PATH manipulation method with fish_add_path
split common functions into another file
etc..

Links
fish

fish-shell/fish-shell: The user-friendly command line shell.
Documentation - fish-docs-jp
Tutorial — fish-shell 3.4.1 documentation
fishで「パスを通す」ための最終解答
fish_add_path - add to the path — fish-shell 3.4.1 documentation

others

webinstall.dev
jethrokuan/fzf: Ef-🐟-ient fish keybindings for fzf

Sorry, this PR is only for my forked project, No offense.


text:
Provider has no field or method NewSession

I created a fork of libdns/route53 in order to test some of the recent bug fixes (https://github.com/libdns/route53/issues/7, https://github.com/libdns/route53/pull/12) and I ran across this error:
/go/pkg/mod/github.com/eth-limo/caddy-dns-route53@v1.1.5/route53.go:35:10: p.NewSession undefined (type *Provider has no field or method NewSession)

For testing purposes I pinned libdns/route53 to v1.2.1-0.20220707195619-cc1414081972 which includes an upgrade to the AWS SDK and a few other fixes.
I'm building Caddy with the following command:
go get github.com/caddyserver/xcaddy/cmd/xcaddy && \
    xcaddy build v2.5.1 \
      --with github.com/eth-limo/caddy-dns-route53@v1.1.5

I'm assuming this will be an issue once this project upgrades libdns/route53 to v1.2.1.
Thanks!

@eth-limo checkout the upgrade branch. I'm still testing it out.

@eth-limo tested the upgrade branch and was able to generate certificates. I'll make a release and close related issues.

authors: aymanbagabas eth-limo


text:
Program no longer works?

Hi! I don't really know how to make a proper GitHub issue, but when trying to use the program, these just get spammed in the console it opens up:
(node:22036) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:23824) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open 'C:\Users\MYUSERNAME\Appdata\Local\osu!\Songs\143397 Natsume Chiaki - Hanairo Biyori\[bold:0,size:20]なつめ千秋 花色日和'
The gif never gets synced up to the music. Is this a problem on my end or does this need fixing on the developer end?

Thanks for the report! Sometimes that happens when the game updates. If you could grab the new .exe here and replace it in the folder

Thanks! Works perfectly now!


text:
Navigate grid using cursor keys. Is it posible?

Can I use the cursor keys to navigate the grid by highlighting the current cell or row?. Thank you

Hi @valientegaston!
No, because the highlight is for mouse hover only. I believe that if the highlight continued even without any mouse hover, it would be the selection concept (which I still need to create). The two could coexist at the same time. The cursor moves the selection and applies the scroll when necessary.
Once I implement the selection, you can use it as a highlight of course.
I just don't know if I'll get it before my vacation ok? :stuck_out_tongue_winking_eye:

Hi! I really appreciate the speed of your response. Thank you so much!
When you say "selection" do you mean marking a set of cells that belong or not to the same row, to later copy the content, or do you mean a highlight to know which cell I'm currently standing on in the grid?
Can a cell take a "focus"? Basically I need to navigate the grid by each cell, using the arrow keys. I have also not found a way to select a specific cell with the mouse.
I love this grid, and I want to use it to replace another one in a project, that's why I want to know with the limitations that I can find.
Thank you!

Selection could be by row or by cell. I thought about being per row only first.
So when clicking on a row, it would have the status selected and could have a different color. The mouse hover would highlight the row (selected or not).
The selection could be single or multiple (holding CTRL or SHIFT).
And the model would have a method to get the selected rows.
Currently, the grid can already have focus because it captures page down/up events. I would have to add the up/down arrows as well. And in the future, sideways arrows because of per-cell selection.
The idea is that this grid makes everything possible in the universe :stuck_out_tongue_winking_eye:
But since I keep other packages too, it takes a certain amount of time :wink:

thank you!

when can we expect selection row or cell by keyboard keys (arrow up/down/left/right)
This is very useful for desktop or web

Im waiting for it too :)

authors: caduandrade selvam920 valientegaston


text:
Add basic github workflow for automated testing

To add github workflows for automated testing with unittests + formating etc

@theo-barfoot : As discussed earlier, feel free to make a PR to activate Github Actions.
I would suggest staring from the example here:
https://github.com/rbialon/flake8-annotations#example-usage
This would also address #8

I had now setup a basic github CI workflow on the main branch.
However, there are no GPU/CUDA based tests. I will look into setting this up and add the jax and cupy tests during automated testing.
@tvercaut Do I also need to run Black in my github workflow? Or is flake8 sufficient here?

Looks good to. It would be an overkill for such a repo to set up our own GPU-enabled CI runners.
flake8 is sufficient now.

authors: masadcv theo-barfoot tvercaut


text:
fix(nirvana): export Server.Builder

What this PR does / why we need it:
Add your description
Which issue(s) this PR fixes (optional, close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
/cc @kdada
Release note:

NONE

/lgtm

authors: kdada yejiayu

repo: caicloud/nirvana


text:
GH1693: Fix key not used when setting process environment variable

fixes #1693

@devlead will merge once CI's finish.

@devlead your changes have been merged, thanks for your contribution 👍

repo: cake-build/cake


text:
🛑 XMR Asia Servers is down

In 8ccf462, XMR Asia Servers ($XMR_ASIA) was down:

HTTP code: 0
Response time: 0 ms

Resolved: XMR Asia Servers is back up in 3c47555 after 8 minutes.

repo: cake-tech/upptime-cakewallet


text:
Missing Postgres types

The Postgres adapter supports some DBMS specific types, such as interval, but not all. For example, timestamp with time zone and its shorthand, timestamptz are missing.

Do you want to make a PR to add them?
The prio so far was usually the ones that are agnostic across the DBs, but that doesn't mean we couldn't add also more specific ones.

No, I completely gave up using the API methods. All migrations are just execute() statements in up() and down() configurations. Phinx will never support the full feature set of Postgres, and simply adding a few types doesn't even begin to bring it closer to that lofty goal. Moreover, there are some highly questionable defaults when using the API, such as assuming everything should have an autonumber column, which is actually an anti-pattern of database design. I don't need to go on, I'm sure you get my point.

authors: Bilge dereuromark

repo: cakephp/phinx


text:
Is there any ETA for compability with Minecraft 1.18?

I would like to have this mod available for Minecraft 1.18. I don't want to add pressure as I know it's developed in your free time, it's just that I would like to know an estimated time.

Updated just now. Should be available on CurseForge soon.

authors: PhoneixS cakewhip

repo: cakewhip/ezpas


text:
Feature/static dispatch

This is the final result of what I think is the solution for static dispatching.  It has a few compromises, from what I can tell.

The function versions for a safe function are marked safe for each architecture, even though they are not.  I don't particularly like this, but it allows static dispatch to inline correctly.  They are marked with #[doc(hidden)] and given names that are unlikely to be shadowed, so unless a user seeks out the implementation details I don't think it's likely for this to cause problems.
The dynamically dispatched function doesn't inline perfectly.  This results in an extra jump instruction after the indirect function call.  I believe this is due to the functions now being marked safe and the compiler avoiding speculative execution of instruction set extensions.
Inlining recursion now requires using #[static_dispatch].  Personally I think it's more consistent this way, anyway.

I think these compromises are worth it in exchange for being able to statically dispatch and inline nested functions.  @TethysSvensson I'm curious what your opinion is.  I'm comfortable with the implementation if you just want to take a look with cargo expand/asm.

I'm sorry I missed this and didn't reply. I know this is already merged, but I'll take a look know if it's any consolation.

I again haven't actually looked at how the proc_macro code works, just what it outputs.
I think what it outputs makes a lot of sense. I agree that it is sad that we cannot make the function unsafe, but also agree that it doesn't matter too much in practice.
I do not currently have time to go into detail about what the assembly output looks like, but perhaps I'll come back and give this crate another look at some point.

Thanks for taking a look, I appreciate a second set of eyes!

authors: TethysSvensson calebzulawski

repo: calebzulawski/multiversion


text:
Google Fonts? / Fonts in general

Does minimal use any google fonts or anything coming from an external source? if so, How can I upload and link the fonts on my webserver so to avoid google fonts calling google?In Germany, the DSGVO (GDPR in German) is very strict and might cause expensive problems, if a website is using google fonts not locally integrated.
Or can I just leave google fonts out and use some other means of fonts?
How can I change the fonts size? it is a bit too small, I think: www.beck24.be

https://github.com/calintat/minimal/pull/96
Although resources are pulled from other providers.

Have you figured out how to enlarge the font size? Thanks

authors: CameronNemo JialiangTan illupino

repo: calintat/minimal


text:
[Dialog] option to make dialog non cancellable

There should be an option so that escape doesn't cancel the dialog.

Thanks @bryanlarsen. It looks like we just need to listen to the modal prop during esc key down.

That would work for me.   I assumed that there would be people who want a modal={true} and still cancel via escape, but if there isn't, that would be simpler.

Fixed with #1187

authors: bryanlarsen hai-cea

repo: callemall/material-ui


text:
Fix a potential error in

An unrecognisable error will occur if you pass a text node as a child to <Card> element.
For example:
<Card>
  <CardTitle />
  Test
<Card>

I was thinking about adding a warning as well. Should I use console.warn?

What is the warning exactly?

Something like You can only use one of the following elements as children of <Card>: <CardTitle>, <CardHeader>, ...

You should probably either use <CardText> or <CardMedia> which won't change much about the Test text's layout

@TrySpace I know what I should use. This PR actually adds that warning and fixes a potential problem with incorrect usage.

@louy I agree with this change. Can you squash down to one commit and change if (!currentChild) { for if (!currentChild || !currentChild.props) { instead?

@oliviertassinari done

@louy Ok, thanks :+1:

authors: TrySpace louy oliviertassinari


text:
How does it differ from create-react-native-app

How does this project differs from : https://github.com/react-community/create-react-native-app
Other than using webpack ? (which is cool btw, not saying haul is useless!)
Using webpack and its ecosystem, opens up a whole world of possibilities.
Thanks :)!

I would also like to know benefits of using this. Since the read me did not tell the benefits and I don't want to break my current project :)

From the readme it looks like haul supportts symlinking modules which the normal packager can't

What is the benefit or use case for that?

@henrikra you often want to develop a module independently along side your app and use it as a dependency from within your app. The usual way is to npm link so that npm picks up your local dev version. you can't do that in RN since the packager does't support it.

Haul is an alternative to the React Native CLI tools which you use to perform actions like bundling JavaScript files for packaging or running a development server.
Haul is based on Webpack, so you have access to the entire Webpack ecosystem and can use any webpack loaders or plugins you need. It also doesn't depend on watchman which is a pain to setup on Windows and have to compile from source on Linux, so hopefully it'll have better cross-platform story. Not using watchman means you can use symlinks, import files outside of your project root etc.
Create React Native App is a framework based on Expo to make development easier. It uses React Native packager internally but that's an implementation detail, and maybe someday we can make it use Haul. But that won't affect your workflow. It solves a completely different purpose.

Amazing, Thanks ! Looking forward to use it.

It would be good to add some from @satya164 comment to the readme. From reading the current readme it wasn't clear to me why I'd want to use Haul.

I agree.

Anyone up for sending pull request?

authors: f0rr0 grabbou henrikra lyahdav satya164 wilomgfx

repo: callstack-io/haul


text:
Examples of manual link the library

Hi,
I tried to use react-native link to link the library. Since I'm integrating react native to an existing app, I'm getting errors. Can you show in the docs that about manual integration steps for iOS and Android?
Thanks.

@littleV For now, refer to official React-Native linking guide. I'll try to add a guide this week.

@Trancever  pls

Closed, as in 2024 auto-linker is a main approach to link the library

authors: Trancever cenaHara littleV retyui

repo: callstack/react-native-image-editor


text:
ReactSlider crash on Android release version

This issue was originally created by @ssg-luke as facebook/react-native#9979.

Issue Description
Hard crash randomly and unexpectedly on Android release version only (debug is fine, iOS is fine on both debug and release) when hiding and displaying sliders based on a state variable.
Steps to Reproduce / Code Snippets
We have a number of photo filters in our app which are selected by <TouchableOpacity> components and some have a slider to adjust the blur or brightness etc. These sliders are completely separate from each other and are displayed based on a string stored in the components state called filter.
Here is one such slider from render():
{filter === 'gamify' && (            <View style={styles.filterSlider}>               <Text>How retro do you want to go?</Text>               <Slider value={this.state.pixelSize}                       minimumValue={1}                       maximumValue={5}                       onValueChange={value => this.setState({pixelSize: value})} />             </View>)}
Expected Results
No crash when hiding and displaying sliders
Stack Trace
java.lang.NullPointerException: Attempt to write to field 'java.util.ArrayList android.animation.AnimatorSet$Node.nodeDependents' on a null object reference
http://pastebin.com/270Wg6Pu
Additional Information

React Native version: 0.33
Platform(s) (iOS, Android, or both?): Android (Release only)
Operating System (macOS, Linux, or Windows?): Mac OSX

any update on this?

@cinder92 still exist
E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.ptrocki, PID: 25728
    java.lang.IllegalStateException: Circular dependencies cannot exist in AnimatorSet
        at android.animation.AnimatorSet.sortNodes(AnimatorSet.java:922)
        at android.animation.AnimatorSet.start(AnimatorSet.java:540)
        at android.animation.AnimatorSet.start(AnimatorSet.java:586)
        at android.graphics.drawable.AnimatedVectorDrawable.start(AnimatedVectorDrawable.java:599)
        at android.graphics.drawable.AnimatedStateListDrawable$AnimatedVectorDrawableTransition.start(AnimatedStateListDrawable.java:339)
        at android.graphics.drawable.AnimatedStateListDrawable.selectTransition(AnimatedStateListDrawable.java:226)
        at android.graphics.drawable.AnimatedStateListDrawable.onStateChange(AnimatedStateListDrawable.java:146)
        at android.graphics.drawable.Drawable.setState(Drawable.java:685)
        at android.widget.AbsSeekBar.drawableStateChanged(AbsSeekBar.java:378)
        at android.support.v7.widget.AppCompatSeekBar.drawableStateChanged(AppCompatSeekBar.java:61)
        at android.view.View.refreshDrawableState(View.java:17433)
        at android.view.View.setPressed(View.java:8045)
        at android.widget.AbsSeekBar.onTouchEvent(AbsSeekBar.java:595)
        at android.view.View.dispatchTouchEvent(View.java:9490)
        at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2666)
        at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2318)
        at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2666)
        at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2318)
        at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2666)
        at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2318)
        at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2666)
        at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2318)
        at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2666)
        at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2318)
        at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2666)
        at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2318)
        at com.android.internal.policy.PhoneWindow$DecorView.superDispatchTouchEvent(PhoneWindow.java:2454)
        at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1773)
        at android.app.Activity.dispatchTouchEvent(Activity.java:2798)
        at com.android.internal.policy.PhoneWindow$DecorView.dispatchTouchEvent(PhoneWindow.java:2415)
        at android.view.View.dispatchPointerEvent(View.java:9721)
        at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:4738)
        at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:4596)
        at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4101)
        at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:4154)
        at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:4120)
        at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:4266)
        at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:4128)
        at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:4323)
        at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4101)
        at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:4154)
        at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:4120)
        at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:4128)
        at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4101)
        at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:6555)
        at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:6529)
        at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:6472)
        at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:6727)
        at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:185)
        at android.view.InputEventReceiver.nativeConsumeBatchedInputEvents(Native Method)
    	at android.view.InputEventReceiver.consumeBatchedInputEvents(Inpu

I also have a similar bug with react-native 0.57.8.  I use another slider (https://github.com/jeanregisser/react-native-slider) instead of the slider of React Native component, and It does work!

According to Crashlytics, I just had this NullPointerException on Android 6.0 and Huawei Y6II

I also have a similar bug with react-native 0.61.5.   any update on this?
java.lang.NullPointerException: Attempt to write to field 'java.util.ArrayList android.animation.AnimatorSet$Node.nodeDependents' on a null object reference
	at android.animation.AnimatorSet.clone(AnimatorSet.java:700)
	at android.animation.AnimatorSet.clone(AnimatorSet.java:51)
	at android.animation.Animator$AnimatorConstantState.newInstance(Animator.java:562)
	at android.animation.Animator$AnimatorConstantState.newInstance(Animator.java:543)
	at android.content.res.ConstantState.newInstance(ConstantState.java:51)
	at android.content.res.ConstantState.newInstance(ConstantState.java:59)
	at android.animation.AnimatorInflater.loadAnimator(AnimatorInflater.java:133)
	at android.graphics.drawable.AnimatedVectorDrawable$AnimatedVectorDrawableState$PendingAnimator.newInstance(AnimatedVectorDrawable.java:567)
	at android.graphics.drawable.AnimatedVectorDrawable$AnimatedVectorDrawableState.inflatePendingAnimators(AnimatedVectorDrawable.java:545)
	at android.graphics.drawable.AnimatedVectorDrawable.applyTheme(AnimatedVectorDrawable.java:377)
	at android.graphics.drawable.DrawableContainer$DrawableContainerState.applyTheme(DrawableContainer.java:865)
	at android.graphics.drawable.DrawableContainer.applyTheme(DrawableContainer.java:577)
	at android.graphics.drawable.StateListDrawable.applyTheme(StateListDrawable.java:370)
	at android.graphics.drawable.AnimatedStateListDrawable.applyTheme(AnimatedStateListDrawable.java:391)
	at android.content.res.Resources.loadDrawable(Resources.java:2615)
	at android.content.res.VivoResources.loadDrawable(VivoResources.java:220)
	at android.content.res.TypedArray.getDrawable(TypedArray.java:870)
	at android.widget.AbsSeekBar.<init>(AbsSeekBar.java:95)
	at android.widget.SeekBar.<init>(SeekBar.java:85)
	at android.widget.SeekBar.<init>(SeekBar.java:81)
	at androidx.appcompat.widget.AppCompatSeekBar.<init>(AppCompatSeekBar.java:47)
	at com.reactnativecommunity.slider.ReactSlider.<init>(ReactSlider.java:68)
	at com.reactnativecommunity.slider.ReactSliderManager.createViewInstance(ReactSliderManager.java:129)
	at com.reactnativecommunity.slider.ReactSliderManager.createViewInstance(ReactSliderManager.java:40)
	at com.facebook.react.uimanager.ViewManager.createViewInstance(ViewManager.java:139)
	at com.facebook.react.uimanager.ViewManager.createView(ViewManager.java:82)
	at com.facebook.react.uimanager.NativeViewHierarchyManager.createView(NativeViewHierarchyManager.java:269)
	at com.facebook.react.uimanager.UIViewOperationQueue$CreateViewOperation.execute(UIViewOperationQueue.java:179)
	at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.dispatchPendingNonBatchedOperations(UIViewOperationQueue.java:972)
	at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:943)
	at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:28)
	at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:174)
	at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:84)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:890)
	at android.view.Choreographer.doCallbacks(Choreographer.java:704)
	at android.view.Choreographer.doFrame(Choreographer.java:637)
	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:878)
	at android.os.Handler.handleCallback(Handler.java:739)
	at android.os.Handler.dispatchMessage(Handler.java:95)
	at android.os.Looper.loop(Looper.java:148)
	at android.app.ActivityThread.main(ActivityThread.java:5619)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:853)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:737)

I believe the crash is caused by the custom Yoga measure implementation here:
https://github.com/callstack/react-native-slider/blob/45c2a5438f0d7e2dd586a663c4043e795d6c1761/src/android/src/main/java/com/reactnativecommunity/slider/ReactSliderManager.java#L69
That code runs on the Yoga layout thread, but it allocates a ReactSlider view. Since ReactSlider extends Android SeekBar, the constructor runs animation and drawable code on different thread than the main thread. I suspect this low-level Android view code is not thread-safe, and not designed to be run on a thread that is not the main thread.
To prevent this code from executing, I changed the style for our <ReactSlider> to include a specific width and height. This prevents Yoga from needing to measure the view. The crash no longer happens for our app.
const style = { height: 40, width: "100%" }

<ReactSlider style={style} ... />

Hope this helps!

authors: BAE86AEC1946B6AB60CCD7452DC811F0 MBach Sugarya cinder92 cpojer newyankeecodeshop ptrocki

repo: callstack/react-native-slider


text:
Is "realm" usable with Repack

Ask your Question
Hi everyone,
I have problem when using realm package
It's work well when "react-native start" and got error when run "react-native webpack-start"

After I added this is config, it's got new error

Anyone can help me? Please

Thank @jbroma so much.
I tried but got an error, project is very simple
Please help me on this demo project: https://github.com/decisionnguyen/demo

@decisionnguyen
realm$: new URL('./node_modules/realm/index.react-native.js', import.meta.url)           .pathname,

You are super hero <3 <3 <3 @dagouzhi

authors: dagouzhi decisionnguyen

repo: callstack/repack


text:
feat: add knowledge to agent

We separate knowledge from workflow description to avoid tasks/descriptions interfering with agent. This could possibly be something else in the future, like a method that gets it from the database/something.
This is just demonstration, as alternative to #105. I am still not sure about this.

I have a feeling this would be done better with tools, but I guess we can try this for now!

repo: callstackincubator/fabrice-ai


text:
When do train_unet, Why don't you use pretrained weight of tokens?

First and foremost, I'd like to express my profound gratitude for the outstanding paper and the code implementation. I have one point of curiosity.
In attempting train_unet, isn't it the case that the initial weights of each category token pretrained in train_token are not used?
In the code, train_unet is executed with split="train". Given this, just like when running train_token, wouldn't the initial weights of the concept_token in the text_encoder be initialized identically to the initial weights of the meta_token?
Since all parameters of the text_encoder are frozen during train_unet, wouldn't this mean that the unet is fine-tuned with the initial weights of both the meta_token and concept_token being the same?
In the Loss formula (5) mentioned in the paper, it is depicted as in the linked image. This Loss seems to utilize f* (pretrained initial weight), hence my query.

Thank you always for your hard work.

Thanks for your correction, we have introduced this bug when reimplementing the code. the initial weights of both the meta_token and concept_token are needed in training. To fix this bug, we change line 199 in base.py from
if self.test_mode and self.load_token_path is not None:
    text_encoder = self.load_embeddings(text_encoder)

into
if self.test_mode or self.load_token_path is not None:
    text_encoder = self.load_embeddings(text_encoder)

to make sure self.self.load_embeddings is called when load_token_path is not None.

authors: callsys seilk

repo: callsys/GenPromp


text:
Proposal: change colour handling code to scale with the max activation in a prompt.

Currently, the background color logic sets all activations>1 to the maximally orange colour like so:
https://github.com/callummcdougall/sae_vis/blob/2740c0047e78df7e56d7bcf707c909ac18e71c1f/sae_vis/html_fns.py#L156-L157
Wouldn't scaling the colours from 0 to the max activation in a prompt be generally better? Specifically, scale the feat_acts by
bg_values = np.maximum(feat_acts, 0) / max(1, np.max(feat_acts))

...so that we don't apply scaling to the cases where the max activation in the prompt is less than 1.0, which would be distracting as well as error when nothing fires in the prompt.

Yep, this seems v reasonable, I'll add this to the list of planned sae-vis changes (got a few fun ones planned on the flight back this weekend!)

Done (on next push)

authors: ArthurConmy callummcdougall


text:
Tutorial is hostile to novices

In multiple places throughout calmmjs and lenses' Readme it says: "If you're new to lenses, read the partial.lens tutorial/docs".
However, the tutorial is extremely hostile to novices:

Let's work with the following sample JSON object:

Ok

First we import libraries

Ok

and compose a parameterized lens for accessing texts:

What?

What do you mean by compose? (I know what it means in functional programming. Lens is a new concept to me, are we on the same page?)
What is a parametrized lens? (how does it differ from regular lens? partial lens? what is a lens?)

Take a moment to read through the above definition line by line.

I would if I:

could understand what each line does
could understand what the end result is going to do

The purpose of the L.prop(...) parts is probably obvious.

No, it's not
Then the tutorial goes on to querying the data, dealing with missing data, etc.

Exercises
Take out one (or more) L.define(...), L.normalize(...), L.valueOr(...) or L.removable(...) part(s) from the lens composition and try to predict what happens when you rerun the examples with the modified lens composition. Verify your reasoning by actually rerunning the examples.

The "tutorial" basically assumes that the novice:

is already intimately familiar with lenses
is already intimately familiar with what L.define etc. do
and really isn't a tutorial but a "here's how one uses partial.lenses"

The tutorial should be split into:
1: explaining what lens are and how they can be used? The explanation should not rely on reference. Current description goes like this:

Lenses are basically a bidirectional composable abstraction for updating selected elements of immutable data structures

Which is gibberish to a novice.
2: step by step example building of the final textIn lens explaining each step and what it does
3: more advanced examples, shorthands, multiple values, decomposition etc.

Thanks for the feedback!
Unfortunately I'm not a novice.  I've been programming roughly daily since about 1990 and I started to get into functional programming in 2001 by writing a simple compiler for a simple ML style language in OCaml.  So, it is not always easy for me to see where novices may have problems.  For example, I recently realized that the term isomorphism is not generally familiar to programmers, so nowadays when I mention the term I tend to explain it in more detail. I assure you, however, that the intention is not be hostile to novices.

What do you mean by compose? (I know what it means in functional programming. Lens is a new concept to me, are we on the same page?)

Yes, composing lenses can be like composing functions.  There are multiple ways to define lenses and optics in general.  In this library optics are a kind of lifted functions that return computations.

What is a parametrized lens? (how does it differ from regular lens? partial lens? what is a lens?)

A function that returns a lens.  Lenses are a kind of DSL embedded into JavaScript for defining data querying and manipulation functions.   Embedded DSLs inherit the mechanisms of the host language.  To create parameterized expressions in JavaScript one uses functions.
A total function is one that always gives a defined result for every possible input (value in the domain of the function).  A partial function is one that may not always give a defined result for all inputs.  Consider a function to return the first element of an array.  Such a function cannot be total unless the input is restricted to arrays that have at least one element.  In partial lenses the idea is that in case the input does not match the domain of the operation, then the input is treated as being undefined.

Take a moment to read through the above definition line by line.

I would if I:

could understand what each line does

Note that the idea with the suggestion is not that the reader would understand everything, but to encourage the reader to spend a moment to look at the definition so that it is easier to understand the references in later sections.

could understand what the end result is going to do

The goal is to compose a lens to access texts.

No, it's not

Check.

The tutorial should be [...]

Writing documentation takes a lot of time.  If you have specific ideas of how the documentation should be like then please take the time to make it so. PRs are welcome and people can also provide documentation, such as blog posts, outside of the library per se.

2: step by step example building of the final textIn lens explaining each step and what it does
3: more advanced examples, shorthands, multiple values, decomposition etc.

Yes, although more is not always better and my time is limited.  But again, I welcome people to both contribute documentation (PRs) and write documentation outside of the library per se (and PR to link to such documentation).

FYI, I just enabled the wiki.  Everyone should feel free to ask questions there and write examples.  Also note the gitter channel where questions on lenses are on topic.

I'll try to post more coherent thoughts! Thanks!

It would also be awesome if you incorporated your response into the tutorial :)

It would also be awesome if you incorporated your response into the tutorial :)

Working on it...

More novice friendly now?

I read it last night, and all I can say: it's AWESOME!
Thanks!

Thanks!
I'll close this issue, but anyone should feel free to open new issues if something is unclear in the documentation.

authors: dmitriid polytypic


text:
Use window.addEventListener instead of addEventListener

Having addEventListener dangle as a global is not ideal.
Please use window.addEventListener to provide more context to static analysis tooling.

do you have a specific issue that it is causing

My static analysis tooling expects all access to global functions via window. I can fix that but it would be a hack on my side.
Having to inject only window as a global when executing this in a different context than browser makes things a lot cleaner than having to inject all the window globals in the to VM container as well.
Also, when looking at the code and you see just addEventListener you don't know what object you are registering events on so you have to see if addEventListener is declared elsewhere in the file before knowing its the window one.

this the one?

And this one: https://github.com/calvinmetcalf/catiline/blob/e4ca4fb9bece9dae72f1b48659c5f0117799a178/src/nextTick.js#L24

authors: cadorn calvinmetcalf

repo: calvinmetcalf/catiline


text:
How to change password?

Hi,
I tried by db.removeCrypto(); and then db.crypto() with different password, but without luck, how can I do it properly?

Remove crypto and add crypto add the crypto pouch plugin to the database not encrypting the documents, you'd need to probably create a new database and add encryption with the new password then replicate between then.

authors: calvinmetcalf panpiotrs

repo: calvinmetcalf/crypto-pouch


text:
Generate compact control

Currently, the systolic array generator naively generates a seq of par to enable the compute and data movement groups. However, this means that for the same systolic array, as the size of the input data increase, the control FSM gets massive. This is stupid.
The compiler should instead generate a while loop to represent the steady state of the computation (enable all PEs) and have some cleanup/startup control for flushing/filling the systolic array.
I bet if we do this, we'll have a smaller resource footprint than the Dahlia generated designs.

That sounds cool. Ideally, down the road, this could even mean that a fixed-size systolic array could process variable data sizes (i.e., with a run-time-specified loop bound).

This was done thanks to @calebmkim's effort on the static paper!

authors: rachitnigam sampsyo

repo: calyxir/calyx


text:
1688 dev isochroneagent upgrade kingslynn flood

Create isochrone for kingslynn, fix segmentization route problem
Create unreachable area population

Due to the length of time taken for the query to run, I am worried that this will not be scalable

authors: ShinZert Ushcode

repo: cambridge-cares/TheWorldAvatar


text:
New data table from ErikRosolowsky

Data table added by ErikRosolowsky at 2015-05-31T19_42_15.398837

@keflavich This step is still manual right?

Nope, this one is totally automatic.  Though we still haven't come up with a mechanism for indicating the column <-> column mapping; it would be good to include that here (in the comments) if you could

Column Mappings:

Galaxy -> IDs
RAD_PC -> Radius (pc)
SIGV_KMS -> Vel Disp (km/s)
MLUM_MSUN - > Surf Density (M_sun/pc^2)

@e-koch we now do have a mechanism for storing that metadata.  Could you merge this and/or resubmit so the metadata JSON file gets included?

authors: SirArthurTheSubmitter e-koch keflavich

repo: camelot-project/uploads


text:
Removed internal IP address

Hi there! I was browsing through this really intriguing implementation against Kronos (thanks for open sourcing this code and showing what's possible against the Kronos API) and noticed that there may be an internal IP address listed in your configs.
d
I figured while I was here I'd remove in favor of a more generic address and add a comment. Feel free to reject / close if it's not going to work for you.
Thanks again and have a good one.

Unfortunately this isn't likely to be merged, as the project owner has been inactive on GitHub since March 2016.

authors: Stevoisiak sephcoster

repo: cameronbwhite/TimeCardView


text:
Plugins menu shows, despite no plug-ins registered

Describe the Bug

Given I got no plug-ins installed
I don't need to see the plug-ins menu

This is a regression from v2.x.
Screenshot

Environment

OS: Linux
Camunda Modeler Version: v3.0.0-beta.2

Closed via 15ffba6.

authors: nikku pinussilvestrus

repo: camunda/camunda-modeler


text:
Make a new release with the 1.0.1

[ ] Update the version number to 1.0.1
[ ] Make a new tag v1.0.1
[ ] Make a new release with new .jar
[ ] Upload new version to Cytoscape App store

Instructions
https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository

@thepritam The release should be named the name same as the tag "v1.0.1" not "New Realease" and you should add the v1.0.1 .jar. There is a place to upload binary files when you draft the release.


text:
Correct ot-ctl command in README

The following command should be updated to use 'openthread-border-router.ot-ctl,' and it would be helpful to also include a link to the OTBR snap or wiki:
https://github.com/canonical/chip-tool-snap/blob/33cc5bfa860015b17f3e908ef703b722e52fd01e/README.md?plain=1#L59C8-L59C14

The command is correct. The ot-ctl used there isn't exposed from the OpenThread Border Router snap.
I have nevertheless created a PR to add some explanation and links: #43

authors: MonicaisHer farshidtz

repo: canonical/chip-tool-snap


text:
Restart grafana after updating dashboards

This ensures that dashboard changes are picked up by grafana.
Fixes #303

Did not apply this patch directly, but I tried /charm/bin/pebble restart grafana will force refresh the dashboard.

Hi @samuelallan72, thank you for your contribution! There seems to be a reload API that might update the dashboards without going through the whole Grafana restart: https://grafana.com/docs/grafana/latest/developers/http_api/admin/#reload-provisioning-configurations
Could you have a look if that doesn't fix your issue in a better way?

Hi @mmkay , could you take another look at this? Thanks :)

Hey @samuelallan72 - I've rebased the branch to newest main and integration tests seem to be failing in the PR. At first sight it looks like there might be errors around the restart timing so this might require a deeper look. We have the issue in our team's minds so will likely get back to it in near future.

Closing because this appears to have been fixed elsewhere. :)  See https://github.com/canonical/grafana-k8s-operator/issues/303

authors: chanchiwai-ray mmkay samuelallan72


text:
feat: add container filesystem mocking guidance

This PR addresses the method to mock container virtual filesystem and provides a simple code snippet that can be copy-pasted easily.

I have some feature requests for the operator framework related to this issue that might change the API of the testing module, could we hold this until that is fulfilled?

I have some feature requests for the operator framework related to this issue that might change the API of the testing module, could we hold this until that is fulfilled?

That sounds like a good idea. Closing :)

repo: canonical/is-charms-contributing-guide


text:
jhack lobotomy

lobotomy command.
Helpful when you have to endure an event storm.
Idea: (temporary) disable event processing for a charm. Juju will know nothing, but the charm will ignore all events and be effectively dead.
Usage:

Lobotomy replaces the dispatch script with one that does nothing except put a juju-log that says that the event has been skipped.
Lobotomy can be applied and lifted in batches to whole applications o entire models.

Interesting idea! A couple of thoughts/questions:

Can you give an example of when in practice would this be useful? It seems to me that by the time you know you're getting an "event storm" it's probably too late.
The name is creative but I don't think a good analogy: an actual lobotomy is brutal and irreversible, this is non-destructive and easily reversible. In terms of medical analogies, a "vasectomy" is about stopping the flow of something and is much easier to reverse, but we probably shouldn't go there. :-) I couldn't think of a nice terse way to say "temporary stop the flow of events", but what keeping it boring and self-explanatory and using jhack charm disable-events / jhack charm enable-events?

storm

in some cases you know that you're about to get an event storm you don't want. For example, you want to remove a charm that has 100 relations, and you don't care about all those broken/departed events, you just want the charm to go.
A user came to me with a juju 2.9->3 migration scenario, where they needed to suspend event processing because model migration apparently involves breaking all cross-model relations and re-creating them on the new juju3 model. And they didn't want that to happen as you 'know' that the new model and the old one will be topologically identical and the events will effectively be for nothing and cause unnecessary workload restarts and downtime.

authors: PietroPasotti benhoyt

repo: canonical/jhack


text:
Add sync-tiers config option

Description
This PR adds a config option to the charm called "sync-tiers" which will enable the sync tiers functionality.

Merging since the integration test is expected to fail.

Just a heads up that the integration test will fail because we haven't yet promoted the latest/edge changes to the stable track.


text:
KU-52 Make the build-rocks job multiarch aware

Updates the build-rocks job to be aware of the potential for a rockcraft.yaml to have multiple platforms.  It doesn't actually try to build those images yet appropriately on the correct architecture, but it makes it possible to distinctly identify those images when the canonical/craft-actions/rockcraft-pack grows the ability to build specific architectures

I think the issue lies with the rockcraft, as it should generate a single multi-architecture rock file (multi-architecture OCI image archive), rather than creating multiple rock files, each for a different architecture. And, this multi-architecture rock file can be uploaded to the container registry as a single multi-architecture image.

@weiiwang01, that's not my understanding of how oci-archives work.
A "multiarch" image doesn't exist.  In order to create a multi-arch image, one must create the images uniquely -- this will result in 2 or more rock files each compiled for an architecture.

Each image should be individually pushed to the registry with a tag like repo/myimage:ver-arch
an oci-manifest is created named repo/myimage:ver which references like a pointer to the correct images

These changes allow this job to create the .rock files and push them as repo/myimage:ver-arch (part 1)
As of now, charmhub does not support uploading a multiarch manifest -- it only supports images.
I understand if you want to reject this PR -- I'll end up building multiarch images to and pushing ghcr.io in other ways if so

@weiiwang01, that's not my understanding of how oci-archives work.
A "multiarch" image doesn't exist. In order to create a multi-arch image, one must create the images uniquely -- this will result in 2 or more rock files each compiled for an architecture.

Each image should be individually pushed to the registry with a tag like repo/myimage:ver-arch
an oci-manifest is created named repo/myimage:ver which references like a pointer to the correct images

These changes allow this job to create the .rock files and push them as repo/myimage:ver-arch (part 1)
As of now, charmhub does not support uploading a multiarch manifest -- it only supports images.
I understand if you want to reject this PR -- I'll end up building multiarch images to and pushing ghcr.io in other ways if so

Yes, there's technically no multi-arch image, but rock file is a OCI image archive file which can contain multiple manifests.
For example, I can download all architecture of the alpine:latest images into one single oct image archive.
$ skopeo --insecure-policy copy --multi-arch all  docker://alpine:latest oci-archive:test.tar
$ 7z e -so test.tar blobs/sha256/0dfdeba6179a9c669d90362960cf052454ea8f28acbfa8338ad98c2cdb91bc42 | jq | grep architecture
        "architecture": "amd64",
        "architecture": "arm",
        "architecture": "arm",
        "architecture": "arm64",
        "architecture": "386",
        "architecture": "ppc64le",
        "architecture": "s390x",
...

And I can upload all architecture of the oct image archive to a local registry:
$ skopeo --insecure-policy copy --multi-arch all --dest-tls-verify=false oci-archive:test.tar docker://localhost:32000/test:test
Getting image list signatures
Copying 7 of 7 images in list
Copying image sha256:0deab21fa3beed803ec512c91e2a49182a7d76d91495591d73e41f479a426756 (1/7)
Getting image source signatures
Copying blob 661ff4d9561e done
Copying config 7ffe15c5a6 done
Writing manifest to image destination
Storing signatures
Copying image sha256:cb93cf714ba92964b24117e4b5c5b5f13b9cf72e51152376c54c209e6b34b54f (2/7)
Getting image source signatures
Copying blob 0803c38384d9 done
Copying config 0d6528cc39 done
Writing manifest to image destination
Storing signatures
...

I suppose we can achieve the same result with rockcraft packing all the architecture into the same oci iamge archive. And before upload the image to charmhub, we can just use something like docker manifest inspect to get the correct image sha256 for the architecture we want.

@weiiwang01 it's cool that the oci-archive does let you store multiple images and a manifest inside it.  I wasn't aware of this
Am I wrong to assert that rockcraft doesn't currently support building on any arch other than the current running platform?  It seems that it would take an arm machine to build an arm image.  How would rockcraft resolve all these back into a single .rock file?

@weiiwang01 it's cool that the oci-archive does let you store multiple images and a manifest inside it. I wasn't aware of this
Am I wrong to assert that rockcraft doesn't currently support building on any arch other than the current running platform? It seems that it would take an arm machine to build an arm image. How would rockcraft resolve all these back into a single .rock file?

Indeed, atm, rockcraft would produce a separate oci-archive per arch. It is also true that there's no support for emulation (by design) so the target arch must be compatible with the build host.
Analogously to other craft tools, Rockcraft should, eventually, have the remote-build capability. Most of that feature shall rely on LP providing support for rockcraft builds. The rockcraft-specific bit of that feature implies exactly what you mentioned: being able to generate a multi-arch OCI manifest from a list of manifest, and packing all the different OCI archives into a single one. This isn't super trivial because the OCI Image spec isn't too consistent about this, i.e. the image index will point to an OCI manifest (application/vnd.oci.image.manifest.v1+json), if it is a single-arch image, but it will point to another index (`application/vnd.oci.image.index.v1+json) if it is a multi-arch image - so rockcraft will need to manipulate these manifest and index files with basis on the required platforms.

@weiiwang01 it's cool that the oci-archive does let you store multiple images and a manifest inside it. I wasn't aware of this
Am I wrong to assert that rockcraft doesn't currently support building on any arch other than the current running platform? It seems that it would take an arm machine to build an arm image. How would rockcraft resolve all these back into a single .rock file?

Indeed, atm, rockcraft would produce a separate oci-archive per arch. It is also true that there's no support for emulation (by design) so the target arch must be compatible with the build host.
Analogously to other craft tools, Rockcraft should, eventually, have the remote-build capability. Most of that feature shall rely on LP providing support for rockcraft builds. The rockcraft-specific bit of that feature implies exactly what you mentioned: being able to generate a multi-arch OCI manifest from a list of manifest, and packing all the different OCI archives into a single one. This isn't super trivial because the OCI Image spec isn't too consistent about this, i.e. the image index will point to an OCI manifest (application/vnd.oci.image.manifest.v1+json), if it is a single-arch image, but it will point to another index (`application/vnd.oci.image.index.v1+json) if it is a multi-arch image - so rockcraft will need to manipulate these manifest and index files with basis on the required platforms.

Yes, I believe we can write a script within the operator-workflows to merge multiple single-arch rock images into a multi-arch rock image (is a multi-architecture OCI image archive also a rock file? is there criteria an OCI image archive must meet to be qualified as a "rock" ?). And We can then use the merged multi-architecture 'rock' in all subsequent workflows. The merging while not trivial, is not overly complicated either.

is a multi-architecture OCI image archive also a rock file?

yes. The rock's specification only addresses the single-arch manifest and image configuration, not the OCI's index files

I'm closing this but let's not end the discussion of how rockcraft will build multiarch images.  I have saved this work in https://github.com/canonical/cilium-rocks/pull/4

authors: addyess cjdcordeiro weiiwang01

repo: canonical/operator-workflows


text:
test-branch/execute-job/wrong-commit-sha-on-pr/03d82615-ff81-4f89-8fb6-b1d90b1a9943

PR for testing 244ad8c58a7c61e69ecc0d10e4badd88277c783c

/canonical/self-hosted-runners/run-workflows 931ad21dd9ace68aaa0a7d341e94de96ad93fa6b

repo: canonical/repo-policy-compliance-tests


text:
test-branch/execute-job/wrong-comment-on-pr/4f25a281-ba97-4fe2-988c-142d1820e2e5

PR for testing adfcda82b1b0343be81b38ddbd0c26393ef44a51

comment 1