Having a +server.js file caused 405

Describe the bug
I had an on-going issue with meta-tags not rendering on social platforms, as well as possible indexing problems.
One of my pages was returning 405- even though there was nothing unusual about it.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">

<meta http-equiv="content-type" content="text/html; charset=utf-8">

GET method not allowed

For example:
https://colorschemer.com/schemes returns 405
https://colorschemer.com/schemes/red worked fine
I was using  Facebook debugger to test changes
I ended up trying different deployment solutions, going in circles with configurations, and playing with rendering options. In the end, the problem was just the presence of the +server.js file
Directory structure was:

/schemes

[slug]
+server.js
layout, page,  etc

The file had
// export const prerender = true;
// export const ssr = true;

I would try uncommenting one at at time, but ultimately, just removing it fixed the problem
Reproduction
Put an empty +server.js file, deploy and test with Facebook debugger
Logs
No response
System Info
Netlify build

Severity
annoyance
Additional Information
No response

I'd argue that the current behavior is correct, if perhaps not useful. If you have a +server file, it's expected to export methods for all of the HTTP verbs you want to support - and if you don't export any methods, the endpoint doesn't support any verbs. I'm marking this as something to possibly consider for SvelteKit 3.0.

We could add a warning, something like "you didn't add any verbs, are you sure this is correct?" - not sure how you would be able to silence it though (or would you even want to? In which situation would this be the wanted behavior?)

If there is no export, maybe it should ignore it, otherwise, an empty export can do it?
It did confuse me for days as other pages worked fine. I had assumed that the settings for server.js would apply to sub-directories but it does not look to be the case

I was trapped is this for days.
When having an +server.js with only a POST method in it. The +page.svelte work just fine if the request has an accept header.
If not it return 405 method not allowed.

I'm seeing the same issue. It's not clear to me from the docs how to fix this:

and if you don't export any methods, the endpoint doesn't support any verbs

Why is this needed if regular browser-based requests work alright? What is the minimal +server.js that just does "what the routes do"?


Feature: Add trademark for MLU-OPS repository.

Thanks for your contribution and we appreciate it a lot. :rocket::rocket:
1. Motivation
Add trademark for MLU-OPS.
2. Modification
modified:   .github/ISSUE_TEMPLATE/feature_request.md
modified:   .github/pull_request_template.md
modified:   CONTRIBUTION.md
modified:   README.md
modified:   docs/GTest-User-Guide-zh.md
modified:   docs/Gencase-User-Guide-zh.md
modified:   docs/MLU-OPS-Accuracy-Acceptance-Standard.md
modified:   docs/MLU-OPS-Compile-Develop-And-Test.md
modified:   docs/MLU-OPS-How-To-Use-CNNL-API.md
modified:   docs/MLU-OPS-OpList.md
modified:   docs/MLU-OPS-Operator-Design-Doc-Template.md
modified:   docs/MLU-OPS-Operator-Development-Process.md
modified:   docs/MLU-OPS-Performance-Acceptance-Standard.md
modified:   docs/MLU-OPS-Test-Report-Template.md
modified:   docs/Pull-Request.md
modified:   docs/user_guide/11_env_var/index.rst
modified:   docs/MLU-OPS-LOGO.png

3. Test Report
No test.

精度文档最大单点误差和综合单点误差需要修改


[Feature]: expose expect.*

🚀 Feature Proposal
The following should be available in typescript

expect.extend(matchers)
expect.anything()
expect.any(constructor)
expect.arrayContaining(array)
expect.assertions(number)
expect.closeTo(number, numDigits?)
expect.hasAssertions()
expect.not.arrayContaining(array)
expect.not.objectContaining(object)
expect.not.stringContaining(string)
expect.not.stringMatching(string | regexp)
expect.objectContaining(object)
expect.stringContaining(string)
expect.stringMatching(string | regexp)
expect.addSnapshotSerializer(serializer)

Motivation
expect.* is not currently exposed in typescript, and if there's a way of accessing these they're not documented.
Example
No response

Hi, we don’t maintain the type definition of Jest APIs. You should request this to Jest repo instead.


Add libswoc to ATS for core and plugins.

libswoc, "Solid Wall of C++", is a library built on top of existing ATS C++ utilities and classes. It was intended as a platform for upgrading ATS core functinality from the start. It is now time to bring it back to ATS and begin replacing old legacy code with more robust, more powerful, and more performant versions. In addtion this will make the library available to plugins so that they too can use these improvements. In particular, this exports the IP networking support that's long been available in the core but plugins have been required to copy or re-implement.
While we will for a time run with both the old and libswoc versions, I will be working to replace and then KIWF the old versions.
In addition to code improvements, the documentation has been extensively revised (when not written from scratch). Unit test and examples should make it much easier for core and plugin developers to use these features.
libswoc repo - https://github.com/solidwallofcode/libswoc
libswoc documentation - http://docs.solidwallofcode.com/libswoc

[approve ci debian]

Approved


Thanos store OOM

Thanos, Prometheus and Golang version used:
Thanos: 0.6.0
Prometheus: 2.10.0
Object Storage Provider: S3
What happened:
Thanos Store won't start.  It runs for 2 mins and crashes with OOM.  Increased the memory to 64 GB and will still fail.  Compactor is running and generating index.cache.json files.
Bucket size: 202.4 GiB.  Total Objects: 4952
Biggest index.cache.json: 3.2 GiB

--index-cache-size=20GB
--chunk-pool-size=40GB

Hi, any reason you are running such an old version? Please try the master and/or 0.8.1 and see if it is still reproducible.

Same issue with v0.8.1.

Indeed. Using the same version here.
# thanos --version
thanos, version 0.8.1 (branch: HEAD, revision: bd8278859b2321aaaa7514edde764816cc039d34)
  build user:       root@2227d9a2fdb1
  build date:       20191014-12:03:55
  go version:       go1.13.1

Total objects is a little over 8000.
Running on a VM, I had to go from 2GB --> 4GB --> 8GB --> 16GB of memory before the OOM-killer was not an issue anymore!
Now thanos store is using 12.3GB of RAM.

Same issue with 0.9.0. I wonder what the relations between Bucket size, Total Objects,--index-cache-size and --chunk-pool-size are - as to how to come up with a formula indicating the proper memory requirements. Even if it's only an estimate.

Same issue with 0.9.0. I wonder what the relations between Bucket size, Total Objects,--index-cache-size and --chunk-pool-size are - as to how to come up with a formula indicating the proper memory requirements. Even if it's only an estimate.

we're having the same issue, it'd be really useful if the documentation would contains some informations about ball park values to set.

Things seem to have gotten a bit worse with v0.9.0...
I upgraded at 14:13CET and this is what Grafana shows:

Thanos Store behaves a bit like "The Very Hungry Caterpillar" when it comes to memory usage... 🥴

@bwplotka the result is amazing after applied this feature flag. Does it has some side-effects for performance?

Nothing we have seen or any user reported. Theoretically queries might be
insignificantly slower and a slight more CPU cycles are needed as well disk
lookups, but not much more.
Label APIs might be bit slower, and we need this to fix this:
https://github.com/thanos-io/thanos/issues/1811
On Wed, 25 Mar 2020 at 15:01, Maria Kotlyarevskaya<EMAIL_ADDRESS>wrote:

@bwplotka https://github.com/bwplotka the result is amazing after
applied this feature flag. Does it has some side-effects for performance?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/thanos-io/thanos/issues/1750#issuecomment-603890337,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABVA3O33CR6QA2YHD3UP4S3RJIMEZANCNFSM4JOHMXJA
.


StackOverflowError Occur when customizing AuthenticationProvider

Describe the bug
I meet a StackOverflowError when implements my own AuthenticationProvider
To Reproduce
Throw an OAuth2AuthenticationException(OAuth2ErrorCodes.INVALID_CLIENT);  in authenticate() method
jdk version: 17
spring-oauth2-authorization-server version: 1.2.2
springboot version: 3.2.3
Expected behavior
Authentication Error repsonse
Sample
java.lang.StackOverflowError: null
at org.springframework.aop.support.AopUtils.isEqualsMethod(AopUtils.java:159) ~[spring-aop-6.1.4.jar:6.1.4]
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:172) ~[spring-aop-6.1.4.jar:6.1.4]
at jdk.proxy2/jdk.proxy2.$Proxy71.authenticate(Unknown Source) ~[na:na]

@hundanLi we generally ask that you provide a sample or test that reproduces your issue for issues with customizations like you are describing. Please provide a minimal sample or a test that reproduces the issue so we can look into this issue further.


Errors in fracfact_opt

Hi @relf,
first of all thank you for keeping pyDOE up-to-date! I have an issue with the function fracfact_opt https://github.com/relf/pyDOE3/blob/766e8103f2fadf6e0926568291d5509f2198311f/pyDOE3/doe_factorial.py#L374
complaining about n_aliases being a float instead of an int
https://github.com/relf/pyDOE3/blob/766e8103f2fadf6e0926568291d5509f2198311f/pyDOE3/doe_factorial.py#L421
and hashing the numpy arrays gives me an error here: https://github.com/relf/pyDOE3/blob/766e8103f2fadf6e0926568291d5509f2198311f/pyDOE3/doe_factorial.py#L506
Not sure what the best solution for hashing is. Maybe just contrast.tobytes()?
I use python 3.11.9 and numpy 1.26.4.

Hi, could you provide the code which shows the issue?

Sorry, forgot to mention it: You can try pretty much anything e.g. fracfact_opt(4, 1)

Actually, I think this function was just never used/tested with Python3.


Name of mode7 for pin P8_7

Hi,
in bone.js entry "TIMER4" aka P8_7:
mode7 is named "mmc1_sdcd" but I believe that should be "gpio2_2" instead.
(hewball on<EMAIL_ADDRESS>originally noticed that.)

The name was reported by the old 3.2 kernel for mode 7 due to its use on the pre-defined MMC1 interface. I guess this is largely legacy now, but I'm not so sure it is all that helpful to fix either.

I think it would be very helpful if you consider that the bone.js script was and for many people still is an easy to read and accurate documentation of the beaglebone pins.
Also, some helper utilities (inkluding one of my own) use bone.js to display interactive documentation for the beaglebone.

Since this is the main GPIO function, to act as MMC1 card detect, I'm not sure I can simply remove that name.  Would adding it after a slash (/) work?

Adjusted to meet this request per https://github.com/jadonk/bonescript/commit/034e55e389bab6fbad7bfe857c5a2f2e81ede347.


function get_harmonic_equations does not take into account hyperbolic sine

Hi,
While solving a set of differential equations:
free_eq = [m1*(d(x1,t,2)) + k1x1 + (k2/alpha)sinh(alpha(x1-x2)), m2(d(x2,t,2)) - (k2/alpha)sinh(alpha(x1-x2))]
The function get_harmonic_equations basically ignores the hyperbolic sine as we can see below:
A set of 4 harmonic equations
Variables: u1(T), v1(T), u2(T), v2(T)
Parameters: k1, ω, m1, k2, alpha, F, m2
Harmonic ansatz:
x1(t) = u1cos(ωt) + v1sin(ωt)
x2(t) = u2cos(ωt) + v2sin(ωt)
Harmonic equations:
k1u1(T) + (2//1)m1ωDifferential(T)(v1(T)) - F - m1*(ω^2)*u1(T) ~ 0
k1v1(T) - m1(ω^2)v1(T) - (2//1)m1ωDifferential(T)(u1(T)) ~ 0
(2//1)m2ωDifferential(T)(v2(T)) - m2(ω^2)*u2(T) ~ 0
(-2//1)m2ωDifferential(T)(u2(T)) - m2(ω^2)*v2(T) ~ 0
I had to linearize sinh to get the correct answer haha.

Thanks for your inquiry Emanuel!
Currently, we only support nonlinear polynomial equations, since those are the ones for which homotopic continuation techniques are developed (to the best of our knowledge). You can find more information in out preprint https://arxiv.org/abs/2202.00571 and https://www.juliahomotopycontinuation.org. We could add a warning to prevent nonlinear non polynomial systems to be input.
Have you tried to get converged results by adding successive higher powers of sinh(x)? That would be a really interesting example too!


Reduce 'sequence-id' complexity

This is issue is related to Equipment #17.
In addition please see the following document: https://wiki.opennetworking.org/download/attachments/265093121/proposal-sequence-id.0.3.docx?api=v2
In order to reduce complexity and dependencies between between different sequence-id values related to the same Equipment object. the UML:Comment (yang:description) should be changed for Holder_Pac::sequenceId and Connector_Pac::sequenceId.
The target is that the sequence-id values of Holders and Connectors can overlap even of the same Equipment object.
The following examples is allowed:

Equipment::uuid = "1234"

Holder::sequenceId = 1
Holder::sequenceId = 2
Holder::sequenceId = 4
Connector::sequenceId= 0
Connector::sequenceId= 1
Connector::sequenceId= 2

1st remark:
Maybe it make sense to add following aspect:
All devices of one device type shall be sequenced identically.
2nd remark:
There is an typo in the second sentence: The 'sequence'd'

1st remark: Maybe it make sense to add following aspect: All devices of one device type shall be sequenced identically.
[sko] I would like to avoid such statement, because we need to deal with the situation that the implementation based on the SoftwarePackageVersion of the device and/or of the SoftwareVersion of the Mediator.

2nd remark: There is an typo in the second sentence: The 'sequence'd'
[sko] yep - and sorry - this typo in in the comment for Connector_Pac and Holder_Pac

@openBackhaul: I'm not allwwed to edit the Proposal Text  Could you please do so - Thanks!!! :)

Proposal to the 5G-xhaul call on 27th of July 2022:
Change Holder_Pac::sequenceId comment
from
"All instances of Holder in the Equipment::containedHolder attribute shall be identifiable by a locally unique sequence ID. Gaps in the sequence would be legal. Sequence IDs at the different layers of Holders and the Connector shall compose to a unique address of the resource (for instance .<IP_ADDRESS>). The same resource shall be identifiable by the same sequence ID at all devices of the same device type."
to
"All instances of Holder in the Equipment::containedHolder attribute shall be identifiable by a unique 'sequenceId'. The 'sequenceId' should be unique for the list of Holder objects of the Equipment object. Gaps in the sequence would be legal."
Change _Connector_Pac::sequenceId comment
from
All instances of Connector in the Equipment::connector attribute shall be identifiable by a locally unique sequence ID. Gaps in the sequence would be legal. Sequence IDs at the different layers of Holders and the Connector shall compose to a unique address of the resource (for instance .<IP_ADDRESS>). The same resource shall be identifiable by the same sequence ID at all devices of the same device type."
to
All instances of Connector in the Equipment::connector attribute shall be identifiable by a locally unique 'sequenceId'. The 'sequenceId' should be unique for the list of Connector objects of the Equipment object. Gaps in the sequence would be legal."

Has been updated and published in EquipmentAugment_1.0.0-tsi.240104.1330+yang.1.zip


Setup Project (DB Included)

Create db schema
Create backed project base + models (liquibase for migrations)
Create sql scripts for jpa / hibernate
Create frontend solution

Believe it's done, check it out

Hey @daverbk ! Looks great but let's add some enhancements here:

Let's reduce boilerplate code by adding Lombok to the project. We can use @Entity, @Builder, @Getter, @Setter, @NoArgsConstructor and @AllArgsConstructor annotations.

I guess we don't need a separate entity for Role. Let's simply create a Enum like this

I guess it'll be better to simply use Repositories and Services, not DAOs and DaoImpls. Like this

And a method in a Service:

We have to add JWT tokens but we can skip this part for now and do it in a separate issue

I recommend you to check out this article which can be useful for current issue https://habr.com/ru/articles/784508/
It's a bit of advanced level, but anyway we will have to implement something like this in the project

@Elovard , thanks for the review!
the three first are fixed the fourth is left for the #4 / #5
the pr - https://github.com/daverbk/evolve/pull/3


Invalid Account Data for Instruction

failed to send transaction: Transaction simulation failed: Error processing Instruction 1: invalid account data for instruction
Its showing during deployment to devnet.

If you made sure you've built successfully before you deploy, can you please share your wallet address and the program id on devnet(if it exists)?

Sorry, Probably not passing the correct params. Didn't mean to keep it open for so long. Yatzee 💯


cleanup ci

cmake, as a cross-platform build system, can be used along with the same config/build command among all platforms and let variable like BUILD_SHARED_LIBS be deternimated inside cmake file.
- cmake -H. -BBuild
- cmake --build Build -j 10

As for the job number, things like j$(nproc) used in https://github.com/Equilibrium-Games/Acid/commit/b7ce821a6a2b2d4bc441b724fabe1bbd9b9c6b8d not must be fastest:

https://travis-ci.org/Equilibrium-Games/Acid/builds/506937129
https://travis-ci.com/FirstLoveLife/Acid/builds/104652475

-j 10 is not bad when being used in travis ci

wip

give up


bool type support (resolves #39)

This is a change for requested feature here #39

When contributing to this repository, please first discuss the change you wish to make via issue.

Issue for this already created, no one mentioned that starts it so I decided to fix this one as for me it seems to be important thing to parse.

[x] Ensure your PR is up-to-date with the master branch.
[x] Ensure all unit tests and integration tests are passing
Covered all possible scenarios it may happen with bool, but open for suggestions :)
[x] Ensure changes are covered by unit tests where possible
[x] Ensure changes to the package's public API are covered in the documentation
Covered Example_* in tests, changed README for bool example
[x] Remove superfluous changes to keep the diff as small as possible

My bad, I was running tests agains encode/decode for places I was touching but not for Marshal. Let me fix it

@werber, left two little nitpick suggested changes, but everything looks good! Can you rebase on master and fix the merge conflicts?

@werber, left two little nitpick suggested changes, but everything looks good! Can you rebase on master and fix the merge conflicts?

Great, will make it till eod

Merged #42 instead of this PR. Closing.


Invalid static compression directory

The following warning is observed in the Windows Application event log when an hwc process is started:
The directory specified for caching compressed content C:\Users\vagrant\tmp\IIS Temporary Compressed Files\AppPool8023 is invalid.  Static compression is being disabled.

This definitely happens locally outside Cloud Foundry, but I'm pretty certain I've seen this warning on a Windows cell before.

Thanks @sneal; we'll investigate.


No WPS support ?

Would be awesome to see any form of WPS brute force/pixie attacks implemented

Would be awesome to see any form of WPS brute force/pixie attacks implemented

100% agree it would be nice. It's theoretically possible but wouldn't be very practical I think due to the hardware just not being enough for this use case.

Yh fair enough , I'm looking at trying to port over WPS features I'll fork and push if I manage it gets it working :)

Yh fair enough , I'm looking at trying to port over WPS features I'll fork and push if I manage it gets it working :)

Sounds good to me!

https://github.com/espressif/esp-idf hopefully I can start here has WPS support


ERR_SSL_PROTOCOL_ERROR on secure site access

Describe the bug
I am unable to access a popular forum since 116 version updates of  Kiwi Browser. When I try I always get ERR_SSL_PROTOCOL_ERROR.
With version 112 or any other updated Chromium browser (Chrome, Brave...) there is no problem.
To Reproduce
Try to access to https://www.htcmania.com
Expected behavior
The site should open normally.
Screenshots

Smartphone (please complete the following information):

Device: Pixel 7a; Samsung Galaxy Tab S6 Lite
Android Version : A13 on both systems
Kiwi Browser Version: 116.*

Additional context
I've come back to 112 playstore version and paused automatic updates. I'm checking every new update from dev-apk releases.

Solved with pre-release<PHONE_NUMBER> version.


[freeglut] Upgrade to version 3.2.1

Related issue: #8315
There are no features of this port need to test.

/azp run

/azp run


Android out of memory crash with GPU

I have built and tested the demo app on Android running on the CPU and everything works fine. But when I try to run it on the GPU I have an out-of-memory crash. But if I use the int8 model files there is no crash and the app works. This is what I am getting from the Android logcat:
Use GPU
<sharedmem_gpuobj_alloc:2713>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
<gsl_memory_alloc_pure:2297>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
vkAllocateMemory failed -2
Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x108 in tid 19589 (Thread-4), pid 19252 (fsa.sherpa.ncnn)

Which version of sherpa-ncnn and which model are you using?
Can you try sherpa-ncnn <= v1.4.1

I am using the latest version and model - sherpa-ncnn-streaming-zipformer-20M-2023-02-17
And there is no crash with model int8 - sherpa-ncnn-conv-emformer-transducer-2022-12-06

sherpa-ncnn-streaming-zipformer-20M-2023-02-17

there is no int8 model for the above model. Do you generate int8 models by yourself?

The int8 model is - sherpa-ncnn-conv-emformer-transducer-2022-12-06

Can you try sherpa-ncnn <= v1.4.1

Or you can try tomorrow the latest master of sherpa-ncnn. I am fixing it.

Tried with tag v1.4.1 and I still have the crash

I've tested the new version 2.0 with the new model and I can confirm that it works.


minimize bindings

Minimizes JS => C++ transitions AO-15210

remove all Metadata construction and manipulation
remove all Event construction and manipulation
Event::send() is the only function exposed by the Event module

constructs oboe_metadata_t from JS Buffer and oboe_event_t from JS Event on the fly.

Reporter::sendStatus() and Reporter::sendReport() replaced by Event::send()
Settings::getTraceSettings() no longer returns metadata

@dschnabel @prettycoder - whatever you care to look at in this will be appreciated. i'm requesting both reviews because there is a mix of C++ and JavaScript as well as the interfaces between them. and with maia's recent fun with C i thought she might be wanting to look at some more stuff. but both your options as to what you want to look at - thanks.

it could be covered by testing once i have a way to get the metrics that oboe sends. there is no way to do so with the existing test setup.
thanks for the review.


Update Gruntfile.js

It's just a test

Please don't use public repositories for testing or learning git.


Polish framework

Adjust runner code, move some MapRunner's code to RunnerBase.
Optimize operator pool。

Codecov Report

Merging #303 (dece9d8) into main (ac277d9) will increase coverage by 0.11%.
The diff coverage is 97.24%.

@@            Coverage Diff             @@
##             main     #303      +/-   ##
==========================================
+ Coverage   70.42%   70.53%   +0.11%
==========================================
  Files         209      209
  Lines        7573     7595      +22
  Branches      781     1010     +229
==========================================
+ Hits         5333     5357      +24
+ Misses       1987     1982       -5
- Partials      253      256       +3

Impacted Files
Coverage Δ

towhee/engine/operator_runner/map_runner.py
100.00% <ø> (+2.43%)
:arrow_up:

towhee/tests/engine/test_engine.py
97.10% <ø> (ø)

towhee/engine/thread_pool_task_executor.py
82.97% <75.00%> (-1.47%)
:arrow_down:

towhee/engine/graph_context.py
92.98% <80.00%> (+0.38%)
:arrow_up:

towhee/engine/operator_pool.py
97.91% <97.56%> (-2.09%)
:arrow_down:

towhee/engine/operator_runner/filter_runner.py
85.71% <100.00%> (ø)

towhee/engine/operator_runner/flatmap_runner.py
75.00% <100.00%> (ø)

towhee/engine/operator_runner/generator_runner.py
75.00% <100.00%> (ø)

towhee/engine/operator_runner/runner_base.py
97.05% <100.00%> (+1.64%)
:arrow_up:

towhee/engine/operator_runner/window_runner.py
68.42% <100.00%> (ø)

... and 6 more

Continue to review full report at Codecov.

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

/lgtm


Add nana examples

http://qpcr4vir.github.io/nana-doxy/html/examples.html
https://github.com/qPCR4vir/nana-demo

Please send the examples to the https://github.com/qPCR4vir/nana-demo, thank you for the pull request.


fix: wrong typing

The type of the check argument function must be a generic, otherwise the type you use for your own custom function would need to be unknown, and that's what is currently happening:
function customValidator(value: string) {
 ...
}

z.custom(customValidator)
// this throws an error saying that the customValidator function `value` argument must be of type unknown.

After inserting the generic, everything works fine!

Fixed in b2ed20cd703321466fbf499986245c42eae02900 but thanks!


Users with Yarn 3 installed will get an error

Describe the bug
Getting a report that users who installed yarn through corepack, which installs yarn@3 (unlike brew install yarn), get an error when spinning up a new Ignite app.
We need to support Yarn 3 (which is possible) out of the box with Ignite.
Ignite version
latest
Additional info
no

Closing so @morganick can file a better description of this issue


Issue Regarding Sparse Reconstruction

Hai ,
Issue is : While trying on my dataset which is 360 Deg images, The output Sparse is not reconstructing well.
Image Specifications:
Camera : Insta360 ONE X2
Dataset : Phoenix
Image type : JPEG
Image size : 4096 * 2048
Image size in mb : 1.5 to 2 mb
Dataset Details
Dataset Phoenix : 303 Images
Sample Dataset image :

Output Reconstruction: (While trying Vocab Tree Matching , Exhaustive Matching without POS.txt=> Output Sparse size formed is 8.2 MB )

Please , Can i know How can we improve this

Are there are any specific things to be considered when the running of SphereSfm , Please mention them ,
Can i know what things did you considered here in the dataset (Like camera side and other )

Thanks ! Hope reply from you ,..

You should share the used command lines first. The main difference is the camera parameter setting from the command line listed in this repo README.

Hope this helps you to answer my query !

I cannot find the issue from the commands. The most possible reason maybe the overlap degree of recorded images.
If possible, you can share your dataset for test.

Haii @json87 ,
So Is there a way to tweak parameters at each stage So I get good results for my failed cases !
Like,
Feature Extraction
Feature Matching
Mapper

Eg : Increasing features or make some changes in some parameters , Will it may enhance my sparse Reconstruction
As i am getting very poor sparse reconstruction to my data ! (or) What parameters that tweaked and considered by you are only the best ??

Thanks , Hoping a good reply !

For indoor scenes, I think the feature matching step is the key issue since there are not enough matches can be found or there are too many false matches in these scenes.

Okay @json87
This dataset is actually indoor dataset like a floor in building , So I tried like Spatial,Sequential,Exhaustive too , In all cases the SphereSfm is failing ! I tried to tweak parameters still no improvement !
So

Can i know what may be a reason why it may failing !
Can we improve anyway any suggestion , to make improvement
or This SphereSfm works good for only outdoor scenes well ,than compared to indoor scenes with more objects ??

Hope these answers will help me !!

You could consider using learned features or matching methods instead of SIFT.

Hai @json87
So My dataset is of full dark places and contains full of white walls where usually there is no features at that place but still there will some features like doors and some other objects !
So in this case i considered number of features to 100,000 and considering SIFT disp and changed some params !! Even though spatial,Exhaustive,Sequential Matching failed here !!
When considering maximum resolution 6720*3360 , Even though features and matches got increased the reconstruction is not forming well !!
So please can you suggest me some ideas or suggestions how can i finally sparse in these cases??


Ratikant rout/issue1-Final Solution

@Ratikant-rout
you have changed 4 files ,please change only 1
please refork and redo
I am closing this pr


A work around for black screen on window start in macOS Mojave (10.14)

When running a flutter-rs application on macOS Mojave (10.14), a black screen is what we get initially until the window is moved or resized, this problem is reported at glfw/glfw#1334 and doesn't affect previous version of macOS.
This pull request contains a work around for this issue which is automatically moving (and moving back) the window with 1px. (the work around should not affect the code in other platforms)

Hi, btwael. Thank you for your PR. Could you please use if cfg!(target_os = "macos") to apply that operation to mac only. Also add yourself to the list in AUTHORS file.

Hey @gliheng, it's done!


Adding depencies to Swift for TensorFlow Project

Hello,
I am attempting to add Vapor as a dependecy to a Project that uses the Swift for TensorFlow Development Snapshot. I am using this starter project
my Package.swift is as follows:
// swift-tools-version:4.0

import PackageDescription

let package = Package(
    name: "STSProject",
    products: [
        .library(
            name: "STSLibrary",
            type: .dynamic,
            targets: ["STSLibrary"]
        )
    ],
    dependencies: [
	.package(url: "https://github.com/vapor/vapor.git", from: "3.0.0"),
    ],
    targets: [
        .target(
            name: "STSLibrary",
            dependencies: ["Vapor"]),
        .target(
            name: "STSApplication",
            dependencies: ["STSLibrary"]),
        .testTarget(
            name: "STSLibraryTests",
            dependencies: ["STSLibrary"]),
    ]
)

Upon building the project I get the following error:
Command /Library/Developer/Toolchains/swift-tensorflow-DEVELOPMENT-2018-04-26-a.xctoolchain/usr/bin/swiftc failed with exit code 1
I can confirm that I get the same error is present in a Non-STS starter project
This issue seems to be isolated to the version of Swift/Swift Tools being used, which is the Development Snapshot for TensorFlow. This might be a low priority, just thought I should raise the issue here. If more context is needed please let me know.
Thank you

Thanks for reporting this!
Do you get any more information than swiftc failed with exit code 1 or is that it?

Inside Xcode that is all I get...however,  I do get a stack trace
swift: /home/danielzheng/swift-build/llvm/include/llvm/ADT/Optional.h:160: T &&llvm::Optionalswift::ProtocolConformanceRef::operator*() && [T = swift::ProtocolConformanceRef]: Assertion `hasVal' failed.
/usr/bin/swift[0x4176bb4]
/usr/bin/swift[0x4176ef6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7fdada316390]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7fdad450c428]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fdad450e02a]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dbd7)[0x7fdad4504bd7]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dc82)[0x7fdad4504c82]
/usr/bin/swift[0xc9fa55]
/usr/bin/swift[0xc9b016]
/usr/bin/swift[0xc57ae6]
/usr/bin/swift[0xcfb05b]
/usr/bin/swift[0xcfb01e]
/usr/bin/swift[0xc5861b]
/usr/bin/swift[0xc5927a]
/usr/bin/swift[0xc5990d]
/usr/bin/swift[0x4df88b]
/usr/bin/swift[0x4dc72c]
/usr/bin/swift[0x48ce4d]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fdad44f7830]
/usr/bin/swift[0x48a6a9]
Stack dump:
0.	Program arguments: /usr/bin/swift -frontend -c /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Body/HTTPBody.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Body/HTTPBodyRepresentable.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Body/HTTPBodyStorage.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Body/HTTPChunkedStream.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Codable/HTTPMessageCoder.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Cookies/HTTPCookieValue.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Cookies/HTTPCookies.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Exports.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Message/Forwarded.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Message/HTTPHeaderName.swift -primary-file /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Message/HTTPHeaders.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Message/HTTPMessage.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Message/HTTPRequest.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Message/HTTPResponse.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Message/MediaTypePreference.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Message/URL+HTTP.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Responder/HTTPClient.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Responder/HTTPClientProtocolUpgrader.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Responder/HTTPScheme.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Responder/HTTPServer.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Responder/HTTPServerResponder.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Utilities/HTTPError.swift /usr/src/.build/checkouts/http.git--6395925384975507283/Sources/HTTP/Utilities/RFC1123.swift -target x86_64-unknown-linux -disable-objc-interop -sdk / -I /usr/src/.build/x86_64-unknown-linux/debug -I /usr/src/.build/checkouts/swift-nio.git-1342414282460985892/Sources/CNIOZlib/include -I /usr/src/.build/checkouts/swift-nio.git-1342414282460985892/Sources/CNIOHTTPParser/include -I /usr/src/.build/checkouts/swift-nio-ssl.git-2065011541152755093/Sources/CNIOOpenSSL/include -I /usr/src/.build/checkouts/swift-nio.git-1342414282460985892/Sources/CNIOSHA1/include -I /usr/src/.build/checkouts/swift-nio.git-1342414282460985892/Sources/CNIOAtomics/include -I /usr/src/.build/checkouts/swift-nio.git-1342414282460985892/Sources/CNIODarwin/include -I /usr/src/.build/checkouts/swift-nio.git-1342414282460985892/Sources/CNIOLinux/include -enable-testing -g -module-cache-path /usr/src/.build/x86_64-unknown-linux/debug/ModuleCache -swift-version 4 -O -D SWIFT_PACKAGE -Xcc -fmodule-map-file=/usr/src/.build/x86_64-unknown-linux/debug/CNIOZlib.build/module.modulemap -Xcc -fmodule-map-file=/usr/src/.build/x86_64-unknown-linux/debug/CNIOHTTPParser.build/module.modulemap -Xcc -fmodule-map-file=/usr/src/.build/x86_64-unknown-linux/debug/CNIOOpenSSL.build/module.modulemap -Xcc -fmodule-map-file=/usr/src/.build/checkouts/swift-nio-ssl-support.git-5105221570662870380/module.modulemap -Xcc -fmodule-map-file=/usr/src/.build/x86_64-unknown-linux/debug/CNIOSHA1.build/module.modulemap -Xcc -fmodule-map-file=/usr/src/.build/x86_64-unknown-linux/debug/CNIOAtomics.build/module.modulemap -Xcc -fmodule-map-file=/usr/src/.build/x86_64-unknown-linux/debug/CNIODarwin.build/module.modulemap -Xcc -fmodule-map-file=/usr/src/.build/x86_64-unknown-linux/debug/CNIOLinux.build/module.modulemap -Xcc -fmodule-map-file=/usr/src/.build/checkouts/swift-nio-zlib-support.git--6584705840855703064/module.modulemap -emit-module-doc-path /usr/src/.build/x86_64-unknown-linux/debug/HTTP.build/HTTPHeaders~partial.swiftdoc -parse-as-library -module-name HTTP -emit-module-path /usr/src/.build/x86_64-unknown-linux/debug/HTTP.build/HTTPHeaders~partial.swiftmodule -emit-dependencies-path /usr/src/.build/x86_64-unknown-linux/debug/HTTP.build/HTTPHeaders.d -emit-reference-dependencies-path /usr/src/.build/x86_64-unknown-linux/debug/HTTP.build/HTTPHeaders.swiftdeps -num-threads 6 -o /usr/src/.build/x86_64-unknown-linux/debug/HTTP.build/Message/HTTPHeaders.swift.o
:0: error: unable to execute command: Aborted
:0: error: compile command failed due to signal 6 (use -v to see invocation)
error: terminated(1): /usr/bin/swift-build-tool -f /usr/src/.build/debug.yaml main output:

Ah, that's right.
In this mailing list thread, Ray pointed out the same error.
The Assertion failed: (hasVal) error was not introduced by us and has been fixed upstream. When we pull from upstream again, the error should be fixed.

:0: error: fatal error encountered during compilation; please file a bug report with your project and the crash log
:0: note: unsupported relocation with subtraction expression, symbol '_$S3NIO6SocketCMn' can not be undefined in a subtraction expression
error: terminated(1): /Library/Developer/Toolchains/swift-tensorflow-DEVELOPMENT-2018-04-26-a.xctoolchain/usr/bin/swift-build-tool -f /Users/stevenprichard/Developer/Swift/swift-tensorflow-starter/.build/debug.yaml main output:

There are two likely reasons for such errors:

S4TF is lagging behind upstream Swift: our last sync was 3/12, which is nearly two months ago. Either bugs were patched in upstream Swift, or the code you're trying to compile is using newly supported features which haven't been merged.

This case is much more likely for errors regarding code we haven't changed.

The fact that we currently enable optimizations is causing new errors.

Anyhow, we can hone in on the cause after we merge again within 2-3 weeks.

Is there anything I can do in the mean time to get the upstream changes?

It's quite difficult, unfortunately.
The best thing to do is to merge from upstream, but that merge is probably 100k+ line diff. We definitely care about upstreaming, but our priority at the moment is setting up CI and infrastructure for switching to GitHub-first development. After switching to GitHub, many things (including merging from upstream and accepting PRs) become much simpler.
If you can narrow down the specific changes from upstream that fix your bug, I would be happy to patch it in. It may be really difficult though, so I wouldn't recommend it. You could also attempt to rewrite the source code of library producing the error, but that is probably difficult too.
My best advice is to wait for us to merge, sorry. I promise it will come!

Yea that's fair. Just wanted to talk about what options there could be. Waiting it is... 👍

We've fully switched to GitHub for development!
Development happens on the "tensorflow" branch of apple/swift: https://github.com/apple/swift/tree/tensorflow
We're working on merging from upstream as a medium priority task (1-2 weeks until first merge is done). Merging will happen in chunks, the first merge will bring us to 05-02.

I believe the compilation errors may be fixed with the latest prebuilt packages.
The 6/29 packages are synced with swift-4.2-DEVELOPMENT-SNAPSHOT-2018-06-19-a.
Please reopen this issue if you still encounter errors!


Preparation for ACG Tools: Skyhook

[x] Deploy Opendata dev instance
[x] Enable Skyhook at Opendata dev instance
[x] Disable HTCondor job submittion (Skyhook works only on k8s for now)
[x] Test simple pipeline: Skyhook/coffea
[ ] Deploy Servicex and enable cephfs support (instead of minio)
[ ] Test simple pipeline: ServiceX/Skyhook/coffea

Related to https://github.com/iris-hep/analysis-grand-challenge/issues/2

Upgraded Skyhook version https://github.com/unlhcc/red-kube/commit/c4575ec8b0cc09333554b6b034d644af3da7fa19

Test Skyhook instance is available @ https://coffea-opendata-prod.casa

Test Skyhook instance is available @ https://coffea-opendata-prod.casa

We managed almost to run a simple example https://github.com/CoffeaTeam/coffea/blob/master/binder/nanoevents_pq.ipynb
Connected issue: https://github.com/CoffeaTeam/coffea/issues/634

For proper testing ServiceX/Skyhook integration, we need to have resolved next issue:
https://github.com/ssl-hep/ServiceX_frontend/issues/215

Thanks to Jayjeet https://github.com/CoffeaTeam/coffea/pull/635 now we should be able to run https://github.com/CoffeaTeam/coffea/blob/master/binder/nanoevents_pq.ipynb (we are looking forward to test it in a new coffea release)

The finished and as a result the test demo featuring ServiceX/Skyhook/coffea functionality was shown at AGCTools  2022 workshop.


fix: Update generate sbom action version

Updated version of GHA advanced-security/sbom-generator-action since the old version no longer exists.

Turns out there are two GitHub actions with a very similar name from this same org. Turns out we are still using the latest version of their GHA so I'm going to close this PR.


Lighten ANTLR dependencies

Matching similar changes in cfparser/cfparser#79.
antlr4-runtime and antlr-runtime actually come with cfparser, but some of the classes here also depend on these, so let's keep them in the POM.
Otherwise, the full antlr4 package isn't needed and we can slash 10MB of dependencies from the final package this way, by keeping just the runtime dependencies.

Good work.


[Container Cert] Container certification should support accessing images in private repo

Both Crane and Podman support reading the credentials from the config.json file.


Compute auxiliary data hashes in Tx building

Ok, let’s merge this with the auxiliary data hashes first. We’ll do another PR for the script data hashes. But first we can standardize a little bit the encoding format, by getting closer to what hardware wallets expects.


Memory Leaks

When running a few days, RepoZ shows that it leaks memory by holding a huge amount of the following objects:

Microsoft.CSharp.RuntimeBinder.Semantics.SYMTBL+Key
Microsoft.CSharp.RuntimeBinder.Semantics.LocalVariableSymbol
Microsoft.CSharp.RuntimeBinder.Semantics.CONSTVAL
Microsoft.CSharp.RuntimeBinder.Semantics.EXPRCONSTANT
Microsoft.CSharp.RuntimeBinder.Semantics.EXPRCLASS
Microsoft.CSharp.RuntimeBinder.Semantics.EXPRTYPEOF
Microsoft.CSharp.RuntimeBinder.Semantics.EXPRLIST
Microsoft.CSharp.RuntimeBinder.Semantics.MethWithInst
Microsoft.CSharp.RuntimeBinder.Semantics.CMemberLookupResults
Microsoft.CSharp.RuntimeBinder.Semantics.EXPRMEMGRP
Microsoft.CSharp.RuntimeBinder.Semantics.EXPRCALL
Microsoft.CSharp.RuntimeBinder.Semantics.EXPRWRAP
Microsoft.CSharp.RuntimeBinder.Semantics.AggregateDeclaration
Microsoft.CSharp.RuntimeBinder.Semantics.Scope

This seems to be very close to a question on StackOverflow:
https://stackoverflow.com/questions/33080252/memory-overflow-having-an-increasing-number-of-microsoft-csharp-runtimebinder-s/34123315

Sorry, after such a long time to see this article, he solved my problem, thank you very much
Finally, I would like to ask, what is the DMP software in the article?
Can you tell me if you can?
Thank you very much

Sorry, after such a long time to see this article, he solved my problem, thank you very much
Finally, I would like to ask, what is the DMP software in the article?
Can you tell me if you can?
Thank you very much

Hey @wturi, sure.
This is ANTS Memory Profiler, It's not free but I can really recommend it anyways.
Not really related but if you look for a .NET performance profiler, I'd recommend the free Codetrack.


azp: unrecognized parameters are not reported

Consider the following:
# pipeline.yml

steps:
- template: steps.yml
  parameters:
    speltWrong: true

# stages.yml
parameters:
- name: spelledWrong
  type: string
  default: ''

steps:
- script: exit 0

Should report an error message: steps.yml (Line 2, Col: 1): Unexpected parameter 'speltWrong'
But no error messages are reported.

I opened the PR before I created the bugs. There is an exception, it just doesn't report the name of the missing parameter.


Promise interface documentation does not explain what happens when onResolve() is called multiple times

It seems the docblock documentation is remiss not to mention how implementations should handle onResolve being called multiple times. Specifically, it should state whether the $onResolved callback replaces any previous callbacks or stacks them to be called together.

Fixed, thanks!


nodePackages.joplin: fix Darwin build

Motivation for this change
Fixes https://github.com/NixOS/nixpkgs/issues/98539.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 120490 run on x86_64-darwin 1

1 package built:

joplin

Result of nixpkgs-review pr 120490 run on x86_64-linux 1


[feature] add possibility to run one plugin several times in one stage

Use case:

Run some scripts, run phpunit, run some shell scripts
run mess detector with different settings for src/ and tests/
run several composer commands (can be done with shell, but must find composer binary manually)
run phpunit with different environment settings (maybe better create a separate project for this?)

Suggestion for implementation: allow a space and some id after the plugin name:
setup:
  composer install: {}
  composer myCommand:
    action: "myCustomCommand"
tests:
test:
  php_mess_detector:
    path: 'src'
    allowed_warnings: 0
  php_mess_detector:
    path: 'tests'
    allowed_warnings: -1

This will be simple for some plugins. But it may be hard for some collecting output (phpunit, ...), maybe forbid those.

Thank you for the idea @SimonHeimberg! It will be very hard to implement... Most likely it will not be done soon)

Calling one plugin several times in one stage is very simple. In fact, it can already be done now for internal plugins:
tests:
   composer:
       action: validate
    Composer:
        action: outdated
    composer_:
        action: install --dry-run --no-suggests
    composer _:
        ...

This is good enough for me. I use it to run several composer commands, and to run shell several times, without stopping the next shell command from running, but still return failure. (plugins/shell.md does not mention that shell commands stop on first failure, but this is how it works.)
A first step in the desired direction is done in this branch:
https://github.com/SimonHeimberg/php-censor/commits/multiCallInStage
It works like this:
tests:
   shell:
       - echo 1; false
    shell - e2:
        - echo 2

I do not see a good way how to prevent unsupported plugins to run several times (or at least warn about). How should this plugins be recognized? A manual created list? Implement some interface? Parse its source?
Plugins working without any problems:

when only creating log output (and pass/fail in summary):
Plugins: composer, shell, env, security_checker, any notifications, ...
Plugins creating wrong results:
when creating data for the plot. Only the number of the last instance is plotted. Building the sum instead of overwriting would not be very hard.
The list of errors is correct.
Plugins: PhpCodeSniffer, PhpCpd, PhpParallelLint, ...
when creating separate data to display. Only the data of the last instance is kept. At least harder to keep all data, any unsure if helpful.
(The list of errors is correct.)
Plugins: PhpUnit, Codeception, PhpLoc, PhpTalLint


(HARP-10414): Delays new labels until map movement finishes

Signed-off-by: Frauke Fritz<EMAIL_ADDRESS>Thank you for contributing to harp.gl!
Before requesting a pull request, please remember to check the following documents:

contribution guidelines
coding style

If you are adding new functionality we would highly appreciate if you can describe what is the capability you are adding and even better if you can add some examples. Please also remember to add tests for it.
CI Check
Our bots will check whether your PR can be directly integrated into the mainline. We have some internal integration tests running on the background, our bots will inform you of the next steps and someone from our team will take a look and help if needed!
And please do not forget to sign-off your commit! You can read more about DCO here. But, in short, you just need to use git commit -s or append --signoff when you are committing to the repo.
Happy contributing!

Codecov Report

Merging #1577 into master will decrease coverage by 0.02%.
The diff coverage is 40.00%.

@@            Coverage Diff             @@
##           master    #1577      +/-   ##
==========================================
- Coverage   60.75%   60.73%   -0.03%
==========================================
  Files         271      271
  Lines       24555    24571      +16
  Branches     5514     5519       +5
==========================================
+ Hits        14918    14922       +4
- Misses       9637     9649      +12

Impacted Files
Coverage Δ

@here/harp-mapview/lib/MapView.ts
63.80% <0.00%> (-0.19%)
:arrow_down:

...here/harp-mapview/lib/text/TextElementsRenderer.ts
68.71% <42.85%> (-0.60%)
:arrow_down:

...rp-mapview/lib/text/TextElementsRendererOptions.ts
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


script::Builder::push_slice is not beginner friendly.

Pushing a script into a Script is a very common step that we need to do in wrapper segwit. sh(wsh), sh(wpkh). Here is how I had to do it in rust-miniscript.
+use bitcoin::script::{PushBytes, PushBytesBuf};
+use core::convert::TryFrom;
 use bitcoin::{script, Address, Network, ScriptBuf};

-                script::Builder::new()
-                    .push_script(&witness_script.to_v0_p2wsh())
-                    .into_script()
+                let push_bytes = PushBytesBuf::try_from(witness_script.into_bytes())
+                    .expect("Witness script is not too large");
+                script::Builder::new().push_slice(&push_bytes).into_script()
             }
             ShInner::Wpkh(ref wpkh) => {
                 let redeem_script = wpkh.script_pubkey();
-                script::Builder::new()
-                    .push_script(&redeem_script)
-                    .into_script()
+                let push_bytes: &PushBytes =
+                    <&PushBytes>::try_from(redeem_script.as_bytes()).unwrap();
+                script::Builder::new().push_slice(&push_bytes).into_script()

Doing a wintess_script.as_bytes().try_into().unwrap() does not work as rust still requires us to specify the exact that we want to try_into.
multiple impls satisfying _: TryFrom<&[u8]>found in the following crates:bitcoin, core: ...
Importing a new type and reading it's documentation is a nice thing to do, but only to find out that we only fail when the total script size can exceed 2**32 which is exceedingly high. I propose we add the following methods that are more beginner friendly.

// We handle creating the pushbytes internally.
pub fn try_push_slice<S: AsRef<[u8]>>(sl: S) -> Result<Builder, Builder>;

pub fn push_slice_unchecked<S: AsRef<[u8]>>(sl: S) -> Builder;

Does not require the user to understand the inner workings of what pushbytes is and how it actually works. cc @Kixunil

In general, people should check the length upfront (also you shouldn't need to allocate BuchBytesBuf in your example) which is statically known in majority of cases. script-in-script is one of the rare exceptions and we should take a look into supporting it more directly.
That being said, I like try_push_slice. I'm not sure what's the idea behind push_slice_unchecked just to panic? People can use unwrap for it already. Breaking invariants instead doesn't sound great.

also you shouldn't need to allocate BuchBytesBuf in your example

PushBytesBuf would take ownership of already allocated vector without doing any more allocations. I just highlighted a few ways to do it.

script-in-script is one of the rare exceptions and we should take a look into supporting it more directly.

We also need this for creating ScriptSig for legacy signatures or legacy multi-sig which also has the type ScriptBuf.

That being said, I like try_push_slice. I'm not sure what's the idea behind push_slice_unchecked just to panic?

Yeah, I don't like push_slice_unchecked anymore. I think we should support try_push_slice.

legacy signatures or legacy multi-sig

Aren't those already statically known to be short? If yes it should be probably struct ScriptSig(PushBytesBuf) with conversion traits.

unwrap which will almost certainly be the case for most applications.

I hope not, these may come from inputs which would create a DoS vulnerability.

If yes it should be probably struct ScriptSig(PushBytesBuf) with conversion traits.

We need some sort of builder to iteratively constructed the ScriptBuf for legacy multi-sig. Yes, but in theory all of them are known to be small. We could also have push_ecdsa_sig(&EcdsaSig), push_witness_script(&WScriptHash) for some legacy functions.

I hope not, these may come from inputs which would create a DoS vulnerability.

True that. I certainly hope that applications that take script fragments input from untrusted parties are already something very weird :)
Relatedly, we can also improve the 2^32 limit in PushBytes. Code form bitcoin core. It appears that all vectors can atmost have 2^25 elements.
/**
 * The maximum size of a serialized object in bytes or number of elements
 * (for eg vectors) when the size is encoded as CompactSize.
 */
static constexpr uint64_t MAX_SIZE = 0x02000000;

/** Maximum amount of memory (in bytes) to allocate at once when deserializing vectors. */
static const unsigned int MAX_VECTOR_ALLOCATE = 5000000;

You already can push EcdsaSig: script.push_slice(ecdsa_sig.serialize()), same with WScriptHash: script.push_slice(wscript_hash)
MAX_VECTOR_ALLOCATE looks unrelated?

Note that ecdsa_sig returns a Vector. Not something of fixed size.
The current implementations for PushBytes are for arrays of fixed size uptil 73. Which does not help if the we are trying to serialize a vector. For converting from vectors, we need to go via PushBytes.

MAX_VECTOR_ALLOCATE looks unrelated?

Oops, extra copy paste :( . Editted away from previous comment.

Note that ecdsa_sig returns a Vector

It doesn't I added SerializedSignature specifically to support this use case (also not allocating is nice), that's also why it impls AsRef<PushBytes> since it's guaranteed to be up to 73 bytes and commonly pushed into script.

SerializedSignature specifically to support this us

Nice :) . Resolves 90% of the issue.
Still keeping this issue open for pushing ScriptBufs. If you are okay, I can add the try_push_slice method.

same with WScriptHash: script.push_slice(wscript_hash)

I intended  push_witness_script(&WScriptHash)  to compute the ScriptBuf::new_v0_p2wsh (OP_PUSHBYTES32  <WSCRIPT_HASH> OP_EQUAL ) and push that as slice. I can manually also push opcodes, but would like to avoid that.

Sure, feel free to add try_push_slice with appropriate documentation noting that many uses pushing common objects into script already work with push_slice.
Why would you ever push witness script rather than call ScriptBuf::new_v0_p2wsh? Witness script must not have anything before or after itself, so it looks more like a footgun.

Same use case. sh(wsh). The scriptsig needs to be script.push_slice(&ScriptBuf::new_v0_p2wsh(...))

Ah, I see. Feel free to add it too with doc where it's used and when to use the other one.

I think we should support sh(wsh) directly with a dedicated method. Then hopefully there are no more "sane" use cases for try_push_slice.
Then I think we should document Builder::push_slice to point at all the dedicated pushing methods that users might want instead of this method.


Improves relative paths for react-router

Improves relative paths for react-router

Thanks! Awesome!


Updated Readme with all contributors shown as image

Updated Readme.md to show contributors as image. Image link was generated on contrib.rocks

Merged !!
Thanks @vijayh1907 !


32/64 bytes key length

What is the best approach to support key length of 32 or 64 bytes?

Currently we support 128-bits and 256-bits keys. This means 16 and 32 bytes keys.
To add support for 64bytes there should be some code in native to choose the appropriate OpenSSL primitives, besides declaring the new format as ID=3 in CryptoConfig.
You already can use 32 byte keys. Support for 64 bytes can be added to the wishlist and added later. I wouldn't recommend sending a pull request right now because we are preparing a native code overhaul, which will benefit C++ and other languages.


Getting error on DndProvider methods

If I invoke the on methods, I get ReanimatedError: [Reanimated] Tried to synchronously call a non-worklet function on the UI thread.
<DndProvider onDragEnd={(e) => console.log('drag', e)} onBegin={(e) => console.log('begin', e)}>

</DndProvider>

If I don't invoke those method, no error.

These method must be flagged as worklet with the "worklet" tag since they run on the UI thread by default, you can still use runOnJS there if you need to run on the JS thread (eg. setState, etc.).

const onDragEnd = (e) => {
  "worklet";
  console.log('drag', e);
}

return <DndProvider onDragEnd={onDragEnd}>

</DndProvider>


Removed php7 from allowed_failure

Since PHP 7 was released, i think it shouldn't be allowed to fail on Travis.

:+1:

Duplicate #131

I don't saw your PR. Sorry.
So this can be closed.


Cut inner ring from outer ring when edge is colinear

@springmeyer says that when mapnik-vt clips a polygon with a hole along a line that cuts through both the inner and outer ring, it turns it into a single ring with the hole cut out instead of two rings with a colinear edge, and that tippecanoe should do this too.

For what it's worth, geojson-vt doesn't do this, and leaves both rings on the edge, so if this is a requirement, it probably needs to do it too.
Example donut and as clipped by geojson-vt and (current) tippecanoe: https://gist.github.com/ericfischer/ea8e7c6545390871a705
cc @mourner @jakepruitt

@ericfischer do you mean there should be no degenerate edges at the top and the bottom in the example? This is what full clipping with StrictlySimple would do, although I don't think this is required for Earcut tessellation. "Artifacts" like this are not harmful and often expected on clipping algorithms like Sutherland-Hodgeman.

@mourner I am satisfied with the current (Sutherland-Hodgeman) behavior but got the impression from @springmeyer that StrictlySimple-style clipping to remove the degenerate edges was now required. @springmeyer can you clarify?

@ericfischer I mean, for guaranteed valid polygons, you have to run StrictlySimple-style clipping post-processing on all tiles. There's no point doing something specifically for the case above without addressing any other possible artifacts (mainly caused by simplification).

OK. But is strict simplicity for polygons now required, or isn't it?

@ericfischer it will be if we want to rip the benefits of much faster tessellation on both GL JS and GL Native.

Thanks @mourner. I'm changing tippecanoe now to use Clipper instead of my own clipping implementation.

Hmm. I am using Clipper with StrictlySimple now, and getting exactly the same result back: an outer polygon and inner hole, not two outer rings. I wonder how mapnik is seeing anything different.

Hmm. I am using Clipper with StrictlySimple now, and getting exactly the same result back: an outer polygon and inner hole, not two outer rings. I wonder how mapnik is seeing anything different.

Okay, then perhaps I'm wrong. Let's lean on @jakepruitt to confirm exactly what mapnik-vt is producing.

Doing another StrictlySimple after simplifying and scaling produces two outer rings.


[stable/kube-state-metrics] allow configuring collectors

kube-state-metrics has a collector for each kind of Kubernetes resource
it collects metrics from. Each of those collectors directly influences
the RBAC requirements for the Pods. Additionally due to the nature of
how kube-state-metrics is versioned and released it is not easy to
determine which collectors are using "alpha" APIs, which are not
necessarily enabled in a cluster, but kube-state-metrics by default has
all collectors enabled so individual collectors should be able to be disabled.
@mgoodness
I have a couple more improvements to the chart, mainly regarding that the official image is now hosted on quay.io, adding a readiness probe to the deployment as well as introduce the addon-resizer like the example upstream manifests. Let me know whether you want me to include these improvements in this PR or follow-up PRs.
Let me know whether you already want a version bump with these changes or wait for the additional changes I suggested above and which (major/minor/patch) we should be bumping.

Rebased and resolved conflicts.

/ok-to-test

Sorry for the delay.

It's somewhat outdated, but for the proposed version it is up to date, so I would suggest we move forward with this for now and add better support for the newer versions.

/lgtm


Module pattern

Added a new index.js file with every component to allow developers to import components like import SampleComponent from '../SampleComponent'; instead of  import SampleComponent from '../SampleComponent/SampleComponent';
This pattern allows us to make modules of the components in future.

@deveshjadon98 Please do not commit package-lock.json files with this PR.

Adding it to gitignore

@deveshjadon98 package-lock.json is needed in the repo, we cannot git ignore it. You just have to remove the package-lock.json files from the commits, leave gitignore as it is.
If you need help on how to do this, feel free to ask me.

@anantoghosh sure, i will make sure to not commit package-lock.json.

Changes done, please check.

@skyshader yes i have, i tried using SampleComponent in App it worked fine.

Reverted  this since it breaks the build.
@deveshjadon98 please check once before acknowledging for future PRs.


Firehose dies with cannot link new blocks to chain after a reconnection

Network: BSC Test net
Firehose version: v1.3.1
Geth: bsc-v1.1.18-fh2.1-2
Steps to repeat: start syncing, sync some blocks and press ctrl-c or terminate process abruptly(I'm running merger, firehose, reader-node, relayer, combined-index-builder) all in one process.
Restart ./fireeth -c config.yaml start(maybe several times) and watch it die with cannot link new blocks to chain after a reconnection
sometimes it also enters infinite loop spamming console with millions of 2023-01-18T09:41:07.186+0400 INFO (reader.sub.relayer) not pushing block to a closed subscription
I think firehose should be able to restart gracefully even after abrupt termination(and it fails to do so even when doing graceful shutdown via ctrl+c)
edit: on yet another restart with the same state it started to complain on this 2023-01-18T09:43:46.926+0400 WARN (bstream) too many consecutive unlinkable blocks {"block": "#136834 (06ce4bb2b6c54d9c)", "consecutive_unlinkable_blocks": 24300, "last_block_sent": "#112408 (444c547f0115596d)"}
in the result it seems that local state is corrupted and I cannot continue syncing data... is there any way to repair it?
config file
start:
  args:
  # Define Firehose components that will be used for this setup
  - merger
  - firehose
  - reader-node
  - relayer
  - combined-index-builder
  flags:
    # Prevent creation of file for logging (logs from previous sessions are not visible with this setting)
    log-to-file: false

    # Ethereum is the default chain, its id is 1. Update these flags for different chains such as Binance
    common-chain-id: "97"
    common-network-id: "97"
    # Update the reader-node-path to reference the geth binary for the chain and OS being targeted
    reader-node-path: ../geth/geth_linux
    # Update the reader-code-arguments for the chain being targeted
    # Find specific values in the Firehose Ethereum Setup Documentation
    reader-node-arguments: "+--maxpeers 500 --cache 4096 --snapshot=false  --bootnodes=enode://69a90b35164ef862185d9f4d2c5eff79b92acd1360574c0edf36044055dc766d87285a820233ae5700e11c9ba06ce1cf23c1c68a4556121109776ce2a3990bba@<IP_ADDRESS>:30311,enode://330d768f6de90e7825f0ea6fe59611ce9d50712e73547306846a9304663f9912bf1611037f7f90f21606242ded7fb476c7285cb7cd792836b8c0c5ef0365855c@<IP_ADDRESS>:30311,enode://df1e8eb59e42cad3c4551b2a53e31a7e55a2fdde1287babd1e94b0836550b489ba16c40932e4dacb16cba346bd442c432265a299c4aca63ee7bb0f832b9f45eb@<IP_ADDRESS>:30311,enode://0bd566a7fd136ecd19414a601bfdc530d5de161e3014033951dd603e72b1a8959eb5b70b06c87a5a75cbf45e4055c387d2a842bd6b1bd8b5041b3a61bab615cf@<IP_ADDRESS>:30311,enode://604ed87d813c2b884ff1dc3095afeab18331f3cc361e8fb604159e844905dfa6e4c627306231d48f46a2edceffcd069264a89d99cdbf861a04e8d3d8d7282e8a@<IP_ADDRESS>:30311,enode://4d358eca87c44230a49ceaca123c89c7e77232aeae745c3a4917e607b909c4a14034b3a742960a378c3f250e0e67391276e80c7beee7770071e13f33a5b0606a@<IP_ADDRESS>:30311"
    reader-node-log-to-zap: false
    reader-node-bootstrap-data-url: ../geth/testnet/genesis.json

    firehose-grpc-listen-addr: ":9000"
    substreams-enabled: true
    substreams-sub-request-parallel-jobs: 10
    substreams-partial-mode-enabled: true
    substreams-rpc-endpoints: "$BSC_SUBSTREAMS_RPC_ENDPOINT"
    substreams-sub-request-block-range-size: 100
    substreams-stores-save-interval: 100

example log:https://pastebin.com/w3Rn2k8r

I am facing same issue

Maybe upgrade to latest?

Firehose version: v1.3.7
Geth: bsc-v1.1.20-fh2.2-2

I'm having the same issue with firehose-eth
In my case, running sync for some time, up to about 1M block, then it suddenly fails but unclear why.
2023-04-03T17:58:54.814Z INFO (reader) reader read statistics {"block_rate": "0 blocks/min (0 total)", "trx_rate": "0 trxs/min (0 total)", "last_block": "Block <empty>", "block_average_parse_time": "0ms/block (over 1min)"}
INFO [04-03|17:58:55.418] Downloader queue stats                   receiptTasks=0 blockTasks=362 itemSize=231.00B throttle=8192
INFO [04-03|17:58:55.490] Imported new chain segment               blocks=1 txs=7 mgas=0.187 elapsed=72.482ms mgasps=2.580 number=956,745 hash=6e5ab3..d27e48 age=7y3mo4d dirty=30.65KiB
INFO [04-03|17:58:55.490] Unindexed transactions                   blocks=1 txs=0 tail=955,746 elapsed="112.742µs"
2023-04-03T17:58:55.491Z INFO (relayer.src.13010) realtime gate passed {"delta": "62745h1m34.491879003s"}
2023-04-03T17:58:55.491Z INFO (bstream) loading blocks in ForkableHub from one-block-files {"start_block": 956500, "head_block": "#956745 (6e5ab310d4cf79b38f086b029ccc69589974d6bb07f82afd1117d7ed25d27e48)"}
INFO [04-03|17:58:55.894] Imported new chain segment               blocks=21 txs=638 mgas=14.810 elapsed=253.664ms   mgasps=58.385 number=956,766 hash=e18bf6..d26fab age=7y3mo4d dirty=1.17MiB
INFO [04-03|17:58:55.895] Unindexed transactions                   blocks=21 txs=25  tail=955,767 elapsed="703.993µs"
INFO [04-03|17:58:56.662] Imported new chain segment               blocks=172 txs=595 mgas=24.863 elapsed=764.909ms   mgasps=32.505 number=956,938 hash=1af45a..29ddbe age=7y3mo4d dirty=2.80MiB
INFO [04-03|17:58:56.697] Unindexed transactions                   blocks=172 txs=342 tail=955,939 elapsed=34.972ms
2023-04-03T17:58:56.844Z INFO (index-builder) reading from blocks store: file does not (yet?) exist, retrying in {"filename": "/mnt/ebs/firehome/sf-data/storage/merged-blocks/0000956500.dbin.zst", "base_filename": "0000956500", "retry_delay": "4s"}
2023-04-03T17:58:56.888Z INFO (reader.sub.relayer) reach max buffer size for subcription, closing channel {"capacity": 200}
2023-04-03T17:58:56.890Z INFO (reader.sub.relayer) not pushing block to a closed subscription
2023-04-03T17:58:56.896Z INFO (reader.sub.relayer) not pushing block to a closed subscription
2023-04-03T17:58:56.901Z INFO (reader.sub.relayer) not pushing block to a closed subscription
2023-04-03T17:58:56.904Z INFO (reader.sub.relayer) not pushing block to a closed subscription
.... (repeating logs)....
2023-04-03T17:58:58.635Z INFO (reader.sub.relayer) not pushing block to a closed subscription
2023-04-03T17:58:58.637Z INFO (reader) unsubscribed {"new_length": 0}
2023-04-03T17:58:58.644Z INFO (relayer.src.13010) source shutting down {"endpoint_url": ":13010", "error": "EOF"}
2023-04-03T17:58:58.837Z INFO (relayer) new source factory created
2023-04-03T17:58:58.838Z INFO (relayer.src.13010) starting block source consumption {"endpoint_url": ":13010"}
2023-04-03T17:58:58.838Z INFO (relayer.src.13010) block stream source reading messages {"endpoint_url": ":13010"}
2023-04-03T17:58:58.839Z INFO (reader.sub.relayer) receive block request {"trace_id": "7770c4af8f65cd39e1a028b7ebc439a0", "request": {"requester":"relayer"}}
2023-04-03T17:58:58.839Z INFO (reader.sub.relayer) sending burst {"busrt_size": 0}
2023-04-03T17:58:58.839Z INFO (reader) subscribed {"new_length": 1, "subscriber": "relayer"}
2023-04-03T17:58:58.852Z INFO (relayer.src.13010) realtime gate passed {"delta": "62741h53m19.852322575s"}
2023-04-03T17:58:58.866Z WARN (bstream) too many consecutive unlinkable blocks {"block": "#957418 (db0c8e4907f8a2ffd67b51a0279a14391f7d244157daa07094b3c59f27e9e52e)"}
2023-04-03T17:58:58.866Z ERRO (relayer) unable to process block, shutting down source
2023-04-03T17:58:58.866Z INFO (bstream) reconnecting hub after disconnection. expecting to reconnect and get blocks linking to headnum within delay {"delay": "1m0s", "current_head_block_num": 956954, "error": "too many consecutive unlinkable blocks"}
....
2023-04-03T17:58:58.869Z INFO (relayer) closing block stream server
2023-04-03T17:58:58.870Z ERRO (fireeth)
################################################################
Fatal error in app relayer:

cannot link new blocks to chain after a reconnection
###############################################################
...
2023-04-03T17:58:59.553Z ERRO (derr) dfuse {"error": "cannot link new blocks to chain after a reconnection"}
....

Setup my firehose-eth on AWS using this documentation: https://github.com/streamingfast/firehose-docs/blob/master/firehose-setup/ethereum/local-deployment.md
here are my versions:
/
[ec2-user@ip-10-0-21-115 firehome]$ ./geth_linux version
INFO [04-03|18:03:13.902] Initializing firehose
INFO [04-03|18:03:13.909] Firehose initialized                     enabled=false sync_instrumentation_enabled=true mining_enabled=false block_progress_enabled=false compaction_disabled=false archive_blocks_to_keep=0 genesis_provenance="Geth Default" firehose_version=2.0 geth_version=1.10.23-fh2 chain_variant=geth
Geth
Version: 1.10.23-fh2
Git Commit: e7f3686b2f8955a0824140c98f88c4e3c94f9741
Architecture: amd64
Go Version: go1.17.12
Operating System: linux
GOPATH=
GOROOT=go
[ec2-user@ip-10-0-21-115 firehome]$ ./firehose --version
-bash: ./firehose: No such file or directory
[ec2-user@ip-10-0-21-115 firehome]$ ./fireeth --version
fireeth version refs/tags/v1.0.0 (Commit 42f870c, Built 2022-09-02T17:05Z)/
not really sure what this error is and how to properly handle it. if I try simply restarting the process, it usually fails with same error but about 1/5 times it does not fail and is able to pickup where it left off and continue processing. but in these cases it fails with same error about 30min later
any idea how I can address this issue ?

Versions you are using for fireeth and Firehose instrumented geth are outdated, please use the latest version for both (so https://github.com/streamingfast/firehose-ethereum/releases/tag/v1.3.7 for fireeth and https://github.com/streamingfast/go-ethereum/releases/tag/geth-v1.11.5-fh2.2 for Firehose instrumented geth).

Note that a Beacon Client is required for Ethereum Mainnet/Goerli to sync properly.

Please retry with latest version and let us know how it goes.

Looking better now @maoueh after updating latest versions, syncing the beacon client, and getting the fireeth instance to sync with the beacon client. Up to 1.4M blocks and counting. Thanks again for your help here and on Discord @maoueh :)

fireeth version 1.4.10 (Commit 5b548fb, Built 2023-07-27T17:49:35Z)
geth_linux version 1.12.0-fh2-dd3c6c2b

Ctrl-C during chain sync always corrupts (with "cannot link new blocks to chain after a reconnection" and  "too many consecutive unlinkable blocks") and I have to purge and start over. Not expected because the docs say:
Tip: To terminate the Firehose processing and connection to the Ethereum network press the Control + C keys.

The Firehose sync process will shut down gracefully and continue where it left off upon the next restart.

Why firehose process are you terminating? Only the reader? What is your config?

./fireeth -c config.yaml start

start:
  args:
  - merger
  - firehose
  - reader-node
  - relayer
  - combined-index-builder
  flags:
    log-to-file: false
    common-chain-id: "5"
    common-network-id: "5"
    reader-node-path: /usr/local/bin/geth_linux
    reader-node-arguments: "+--goerli --datadir /home/ethereum-goerli-firehose --cache 8192 --maxpeers 100 --metrics --metrics.port 6061 --port=30303 --http.port=8545 --ws.port=8546 --snapshot=true --txlookuplimit=1000"
    reader-node-log-to-zap: false


Using Megatron Train GPT3

Hello, there was an error when I used the Sophia optimizer to train GPT3 with Megatron. The error point is that grad cannot be substituted into the optimizer with require_grad = True state to calculate the second derivative. Do you know how to solve this problem?
 File "/root/miniconda3/envs/torch18/lib/python3.7/site-packages/torch/autograd/__init__.py", line 277, in grad allow_unused, accumulate_grad=False)  # Calls into the C++ engine to run the backward pass RuntimeError: element 0 of tensors does not require grad and does not have a grad_fn.

class HutchinsonEstimator(HessianEstimator):
    def estimate(self, p, grad):
        u = torch.randn_like(grad)
        grad_dot_u = torch.sum(grad * u)
        print(f"grad_dot_u requires grad: {grad_dot_u.requires_grad}")   #  -> False

        # ↓  RuntimeError: element 0 of tensors does not require grad and does not have a grad_fn.
        hessian_vector_product = torch.autograd.grad(
            grad_dot_u, p, retain_graph=True)[0]
        return u * hessian_vector_product

This problem same like #7 .

See possible fix here: https://github.com/kyegomez/Sophia/issues/7#issuecomment-1570667990

Hello @Kingsleyandher , I meet the same question, is your problem solved?


(Feature) Add options to select gas price

Closes #283 and #390.

@fvictorio merge conflicts need to be fixed here

Done.

I agree, but I'd propose something a little different.
First, the global settings should be in a separate card. Right now they appear in the first card (the first tier) and don't show up in the following tiers. I would create a separate card with the global settings (wallet address, whitelisting, min cap and gas price). This card would appear at the top, and then there would be a new card for each tier added.
I think that would be cleaner: all the tiers would have the inputs in the same position. And having the global settings visually separated make their intention clearer.
Also, I wouldn't hide the Min cap when whitelist is enabled, I would disable it, but that's a personal preference.
What do you think?

First, the global settings should be in a separate card.

Good idea

Also, I wouldn't hide the Min cap when whitelist is enabled, I would disable it, but that's a personal preference.

Good idea

@igorbarinov Agree with these points. @fvictorio Could we visually emphasize disabling? By changing background of the input, for example.

@vbaranov Sure!

This should be ready for review. I left the prices at 5/10/15 Gwei.

Franco, by the way, can we deploy it on stage? or I'm supposed to review it on a local machine?
what is the best way to do the review of UI behavior

I always test things locally, but it would be good to have a better process for this. What do you think of something like this?

PRs are reviewed locally by devs.
If they are approved, they got merged to stage, since that branch is already integrated with the CI.
Then someone is in charge of testing things in stage, and if everything works there, stage is merged in master. That would be our deploy to production.

It would mean that things get to production more slowly, but it would be safer. If we do this, though, we should add a "stage" column in waffle, I think.
Thoughts?

It works. Suggest adding Custom Gas Price ;-)

@youtweakit good idea.
@fvictorio I hope we can set up an oracle for gas price on mainnet (very volatile gas price at the moment) using this code https://github.com/oraclesorg/ico-wizard/issues/393#issuecomment-350508366
Although, let add users to specify custom gas price

About staging I agree that we need it only for external testing
or if we can make CD for it, e.g. every PR will be deployed on a stage server. Let me see if we have this functionality in Netlify.

Nice, Netlify deploys all previews automatically

I added hooks to GitHub. Netlify should inform on build preview

Nice, that will be very useful.

This is ready for review. I tested it a little in Netlify's deploy preview, it's great to have that.

https://clever-bartik-1e0c01.netlify.com/ - works fine! Great tweak ;-) will use this build for our pre sale project. Thanks!

@fvictorio @igorbarinov changes are approved. Let me clarify: we won't change scheme of merging. Anyone can check deploy preview in Netlify before merging. I will merge it to master, right?

@vbaranov Yes, I agree.


Potential bugs or improper implementation of dynamic NTK.

Thanks for your introduction of dynamic NTK and logN attention to make Qwen support long sequence inference. I have several questions about the implementation of dynamic NTK.

Qwen-7B caches the ntk value in attention while 14B caches it in RoPE,  both way may face two problems in inference.

For static batching inference, if there is an outlier long sequence in the batch (e.g. bs=8, 7 prompts with length 0.5k, while an outlier one 4k), the ntk value for this batch will all use the longest one with padding, which may cause error on RoPE.
For continuous batching inference, it's hard to follow this ntk cache type since the batch is dynamic. In VLLM, they directly set this ntk value as a param provided by the user in the inference request. (A better way to cover this case is to maintain an ntk value for each request)

The NTK value formula of Qwen is $2^{\lfloor{log_2(\frac{full\ seq\ len}{long\ seq\ len\ threshold})+1}\rfloor}-1$, I wonder what if the decode length exceeds the floor of $log_2$ (e.g. the prompt length is 2k, while decoding to a position more than 4k, the ntk rope for 4k+ pos will have error).

关于static batching inference，现在的实现是为batch里的每条样本按实际长度计算ntk，所以不会有啥问题。其它问题我们再一块看看吧


metainfo: Use appstreamcli to validate, rather than appstream-util

appstream-util comes from libappstream-glib, which is outdated and
unmaintained. appstreamcli is the more modern replacement, and it comes
from libappstream.
It implements more up to date validation rules, in particular it has
raised the maximum length of screenshot captions from 50 characters to a
more manageable 100 characters.
The downside is that it more strictly validates
<compulsory_for_desktop>, and rejects ‘endless’ because it’s not
officially registered as a desktop ID. Work around that for now by
temporarily removing that element from the XML during validation. In the
long term, we need to register the ID:
https://github.com/ximion/appstream/pull/522.
Signed-off-by: Philip Withnall<EMAIL_ADDRESS>

This should fix failures like this one: https://github.com/endlessm/endless-key-flatpak/actions/runs/6109528108/job/16580732377?pr=32
One outstanding question: before we standardise endless as a desktop ID forever, should we consider changing the capitalisation to Endless while we still can? It would be a bit disruptive in the OS, but easier to change now than after it’s standardised.
Confusingly, some software which uses the desktop ID (which pops up as $XDG_CURRENT_DESKTOP) does case-insensitive comparisons on it, but other software does case-sensitive ones. The consensus seems to be that it is case-sensitive.

Thanks. I just opened #34 to track this. I'll take a look at the upstream stuff.

Looks like the CI flatpak build is actually building the main branch every time, not the branch from the PR. I’ll see if I can change that.

Looking at the other examples, it certainly seems that like it should be capitalized. Hmm, that would be pretty disruptive to Endless OS. We could stage all the OS parts at once (although I don't know what all of them are), but what about Flatpaks? I was worried about our external appstream, but it doesn't use <compulsory_for_desktop>. The only case of that I've found is from the Kolibri flatpak.
You'd probably have to go spelunking to find all the places that the desktop ID is used. This search is pretty enlightening, though.

Looking at those search results:

There don’t seem to be too many problem areas
A load of the old hardware reports suggest that at some point in the past it was capitalised as Endless anyway, so there could already be problems with this in the wild

I’m tempted to JFDI. I’d file a GitHub issue about it but I’m not really sure which project to file it under, given that the desktop is defined in our Debian packaging for gnome-session, which lives entirely in OBS. Should I use Phabricator once more?

I’m tempted to JFDI. I’d file a GitHub issue about it but I’m not really sure which project to file it under, given that the desktop is defined in our Debian packaging for gnome-session, which lives entirely in OBS. Should I use Phabricator once more?

I think phabricator is the most appropriate for OS issues. It has all of our history and I'm pretty sure Will declared that Github was not for OS issues at the time the Github experiment was started.
The other thing you could do is just add compulsory_for_desktop with both the lower case and capitalized names. We'd probably need that in the Kolibri flatpak, too. Then we can work on the desktop ID in parallel.

I’m tempted to JFDI. I’d file a GitHub issue about it but I’m not really sure which project to file it under, given that the desktop is defined in our Debian packaging for gnome-session, which lives entirely in OBS. Should I use Phabricator once more?

I think phabricator is the most appropriate for OS issues. It has all of our history and I'm pretty sure Will declared that Github was not for OS issues at the time the Github experiment was started.

I opened https://phabricator.endlessm.com/T34910, let’s continue discussion of this there.

Necro-commenting: Is Endless Key truly compulsory? I think that this flag, in effect, disables the "uninstall" action for the app in GNOME Software?

Necro-commenting: Is Endless Key truly compulsory? I think that this flag, in effect, disables the "uninstall" action for the app in GNOME Software?

It is since eos-kolibri-system-helper is part of the OS and the way it works is to run the org.endlessos.Key flatpak from the host.

Right, but that service gracefully gets disabled if the Flatpak is not present:
https://github.com/endlessm/eos-kolibri/blob/master/data/systemd/dbus-org.learningequality.Kolibri.Daemon.service.in#L3

Ah, true. @dylanmccall might know more of the history there.

Yep, it is completely safe and reasonable to uninstall the app. The only issue on Endless OS is people might be confused to find that Kolibri's data persists (under /var/lib/kolibri). I think that's the reason why we did the compulsory_for bit in the first place. It isn't a good solution - a good solution involves a bunch of work in GNOME Software - but it's what we have.
We were doing the same at https://github.com/learningequality/kolibri-installer-gnome/blob/master/data/metainfo/org.learningequality.Kolibri.metainfo.xml.in.in#L206 for some reason, too, via this PR: https://github.com/learningequality/kolibri-installer-gnome/pull/63. Unfortunately there's no hint there of the context, but I think I'm remembering correctly here.

On Mon, 30 Oct 2023, 6:13 pm Dylan McCall, @.***> wrote:

Yep, it is completely safe and reasonable to uninstall the app. The only
issue on Endless OS is people might be confused to find that Kolibri's
data persists (under /var/lib/kolibri). I think that's the reason why
we did the compulsory_for bit in the first place. It isn't a good
solution - a good solution involves a bunch of work in GNOME Software - but
it's what we have.

Great point!


Resolves #2825

Move WhatIf note in cmdlet description
NOTE: The WhatIf switch does not work with this cmdlet.

Docs Build status updates of commit 54cbd7d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset/winserver2012-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (winserver2012-ps)

docset/winserver2012r2-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (winserver2012r2-ps)

docset/winserver2016-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (WindowsServer2016-ps)

docset/winserver2019-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (WindowsServer2019-ps)

docset/winserver2022-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (WindowsServer2022-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Please use the Alert box format for notes like this.

@sdwheeler I have been advised in the past not to use this syntax as it does not render in PowerShell. Should I start using it?

Should I start using it?

Yes, the Alert boxes are the preferred format.

Docs Build status updates of commit a626788:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset/winserver2012-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (winserver2012-ps)

docset/winserver2012r2-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (winserver2012r2-ps)

docset/winserver2016-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (WindowsServer2016-ps)

docset/winserver2019-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (WindowsServer2019-ps)

docset/winserver2022-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (WindowsServer2022-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit dd6d4eb:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset/winserver2012-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (winserver2012-ps)

docset/winserver2012r2-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (winserver2012r2-ps)

docset/winserver2016-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (WindowsServer2016-ps)

docset/winserver2019-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (WindowsServer2019-ps)

docset/winserver2022-ps/smbshare/New-SmbShare.md
:white_check_mark:Succeeded
View (WindowsServer2022-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

@tiburd
PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Home, schedule, event cells

Updates the home and schedule pages, countdown appearance, and event cells.

Added BannerViewController
Updated constraints

Looks great Sophia, good job with the constraint fixes!


Add native error codes to exceptions

Thanks for bringing this pull request back to my attention.
I checked the native layer and the returned error codes are not very informative as they are almost always "-1". Check this: https://github.com/frankpapenmeier/webcam-capture-driver-native/blob/master/src/jni/com_github_sarxos_webcam_ds_nativeapi_NativeWebcamDevice.cpp
Thus I am not sure whether adding the error codes to the Java layers has any benefits.

Ok closing it then :)