text:
Process Proposal Following Gap Analysis

Following the 19th December 2019 deadline of the milestone there was a gap analysis that happened on an issue as well as on a two W3C Solid Community Group calls in both timezones. The minutes for the 20200102_1600CET and 20200109_1000CET were recorded for reference.
In this pull request, I have started to incorporate the suggestions from the conversations into a process proposal.
I'm still working on including a few more details but will publish the work so far so we can co-create and include any suggestions along the way.

Can we first list problems before discussing solutions?
I.e., what are the things that are not working today?
For lack of problems, we cannot evaluate whether the proposed changes tackle them.
Suggestion: create an issue per problem.

@RubenVerborgh the problems have been discussed in the four CG calls we've had, I don't know if we should reiterate. Personally, my thread pool is quite full, so I would be hesitant to engage more than we've done on the calls.

I don't know if we should reiterate.

Yes.

For lack of problems, we cannot evaluate whether the proposed changes tackle them.

Not asking to discuss or negotiate, just list.

Most work is being done through the github issues, PRs, etc.
Some participants having discussed something in a couple of calls, without bringing (at least summaries of) those discussions here, does not seem to fit with the collaborative community ethos that I believe remains a goal of this work.
I think this is the third, maybe the fourth, significant re-work of the Solid Process in the past year or so. Each round has been a fairly wholesale rip-and-replace of the previous structure, including a restructuring of the github repositories in use.
Sometimes such a wholesale process replacement is warranted, but usually that's after a given process has been tried for a reasonably long window of time -- more than a few months! -- and after a fair number of incremental changes have been applied to fix areas of weakness discovered while working with that version -- which weaknesses are usually nameable, if not describable in detail, especially when they're severe enough to warrant a wholesale process replacement.
I'm hoping for a clear list of the issues which were raised in those calls, and for an equally clear list of which element(s) of this PR address each issue -- as well as which, if any, elements of this PR are distinct from those directed issue fixes.

Can we first list problems before discussing solutions?
I.e., what are the things that are not working today?
For lack of problems, we cannot evaluate whether the proposed changes tackle them.
Suggestion: create an issue per problem.

I have to agree with @RubenVerborgh and @TallTed - it's not clear to me how the large body of changes proposed here map to specific or broad problems. IMO - the only fair way to have reasonable discussion and evaluation of these changes are individual pulls - each of which are focused on addressing a specific / stated problem or need (which ideally would be tied to a reported issue).
My proposal is that we move away from this single pull into smaller individual pulls, each with a stated problem and proposed solution.

Check links in my first message for a list of problems associated with the gap analysis that have been raised in the last few W3C Community Group calls that @kjetilk mentioned.
Important to note that 1 of 44 items were closed in the last milestone. The project board shows that although items were not closed they were advanced to some extent. Activity in the Specification repo opened some months ago has been remarkably low. There have been weekly  W3C Solid Community Group, Editor, and Panellist calls but not all the members listed in the editor and panel roles have been attending these calls.

@RubenVerborgh the problems have been discussed in the four CG calls we've had, I don't know if we should reiterate. Personally, my thread pool is quite full, so I would be hesitant to engage more than we've done on the calls.

@kjetilk I'm not sure it's fair to ask for review but not stipulate the reasoning behind the changes. We spent several months refining the process and getting community consensus on it. The timing of the community calls are such that 50% of them are at 4AM EST / 1AM PST for those in the US, and the ones related to this occurred when many were either still away on a holiday break (myself included), or digging out of things that came up during it. The minutes I have reviewed at https://www.w3.org/community/solid/wiki/Meetings include a lot of topics for discussion but very little in the way of decisions that were reached for each one, or why. From the participants listed these were also very lightly attended meetings.

Important to note that 1 of 44 items were closed in the last milestone. The project board shows that although items were not closed they were advanced to some extent. Activity in the Specification repo opened some months ago has been remarkably low. There have been weekly W3C Solid Community Group, Editor, and Panellist calls but not all the members listed in the editor and panel roles have been attending these calls.

@Mitzi-Laszlo I believe these problems can be extracted from your points there:

Specification work isn't progressing quickly enough
Attendance / engagement is too low on regular calls

Can we get an explanation of how the changes included address these points? Why do we think these changes will make a positive difference, as opposed to creating new swirl? Are there additional points to address? Based on the content of the changes it seems like we're also trying to cover other problems too, so lets identify those.

Activity in the Specification repo opened some months ago has been remarkably low.

I am not sure that this is quite accurate. While it is true that many issues have been opened and only one has been closed, there has been an extensive amount of discussion on the high priority issues (esp. those identified for the Dec 19 milestone). That conversation has been incredibly important; in fact, without those initial conversations, I suspect that it would be much harder for the editors to write specification text (let alone text that would stand up to scrutiny).
While I would certainly like to see formal text materialize in the spec, it would be problematic to write that text prematurely.

Check links in my first message for a list of problems associated with the gap analysis that have been raised in the last few W3C Community Group calls that @kjetilk mentioned.
Important to note that 1 of 44 items were closed in the last milestone. The project board shows that although items were not closed they were advanced to some extent. Activity in the Specification repo opened some months ago has been remarkably low. There have been weekly W3C Solid Community Group, Editor, and Panellist calls but not all the members listed in the editor and panel roles have been attending these calls.

While I appreciate your input, @Mitzi-Laszlo, I can't find the relevance of the above to the changed process text in this PR (similar to @justinwb, it seems).
When asking for issues above, I wanted to know what was wrong with the process, and so far, no such description has showed up in this thread. I have read through all the links provided, but none of them seems to point out a specific aspect of the process that needs changing.
For example, the text above seems to hint at a problem of low activity, but @acoburn disagrees, so maybe it is not a problem. But even if it were, what would be the specific underlying problems with the process (if any)? There is also a mention of low attendance. However, is that a problem of the process? And what is that specific problem? Will the four-strikes-and-you're-out then help?

Summarizing, I really feel we are running blindly here. There is no list of problems to be addressed, no agreement on whether such problems exist or what they are, and no agreement on whether they are real problems.
As such, it's impossible to tell whether this PR makes things better or worse. Assuming the worst case for safety reasons, I strongly recommend to close this PR until we understand the problems. See this as a red pen / green pen thing: we can't possibly fix if we don't know what's wrong.

Ok - let's close this pull request and use the record of the gap analysis ( see issue,  20200102_1600CET minutes and 20200109_1000CET minutes)
following the milestone done by the community for future reference if need be.
Editors @RubenVerborgh @kjetilk @csarven @dmitrizagidulin @justinwb please can you define the next milestone.

I don't see the correspondence between what has been called gap analysis (a list of technical issues that need addressing) and problems with the process (which was put in place to ensure legitimacy of the outcomes). They are completely separate things. The implication would be that somehow the validation process—which is not a planning process—would have a relation to milestones, which is not the case. Retrofitting it to have that role, does not seem meaningful.
As such, I really do not know how to act upon the comment above, other than continuing what we were already doing. I would strongly suggest that we let editors self-manage, or let them execute a planning process that they themselves install.

authors: Mitzi-Laszlo RubenVerborgh TallTed acoburn justinwb kjetilk

repo: solid/process


text:
Why does Client configuration data have to be JSON-LD serialized?

When a Client Identifier is dereferenced, the resource MUST be serialized as an application/ld+json document unless content negotiation requires a different outcome.

Why does Client configuration data have to be JSON-LD serialized?
OpenID Federation Specification defines Automatic Registration feature that achieves the same goal and the Entity Statement is a signed JWT: https://openid.net/specs/openid-connect-federation-1_0.html#section-10.1

Issue #95 seems to be referencing the Federation draft too

We should take a serious look at whether we could replace the use of Solid-OIDC client identifiers with this definition from the OpenID Federation spec

source: gharchive/issue

authors: Sakurann acoburn

repo: solid/solid-oidc

license: MIT

license_type: permissive

license_source: github-api


text:
fix: dont use node request as body in handleServerFunction

PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] infrastructure changes
[ ] Other... Please describe:

What is the current behavior?
The changes from #1521 broke the form parsing in Node, it threw the error [h3] [unhandled] TypeError: Response body object should not be disturbed or locked.
What is the new behavior?
This fixes the handling for Node, yet tries to keep the functional aspects from the edge runtime workarounds #1282 and #1521. I couldn't test this fix on edge runtimes - @supersoniko could you maybe check if your azure preset still works after this fix ☺?

Thanks. Hacks on hacks here until I guess we can get the right resolution from Nitro. I was concerned to merge that PR but it had been sitting for months. I tested all the local apps like Notes/TodoMVC and deployed my hackernews to Netlify and didn't see any problems.

source: gharchive/pull-request

authors: katywings ryansolid

repo: solidjs/solid-start


text:
hydration crash with npm "Cannot read properties of null (reading 'nextSibling')"

Describe the bug
SolidJS hydration seems to behave differently with npm and pnpm, leading to a crash with npm but not with pnpm.
The bug was originally filed at https://github.com/chakra-ui/zag/issues/385. Any Zag component crashes during hydration but not when client-side rendered only via render(). Efforts to reproduce the issue yielded that running the repro with npm crashes while pnpm does not.
Uncaught (in promise) TypeError: Cannot read properties of null (reading 'nextSibling')
    at index.page.tsx:14:3
    at Checkbox (index.page.tsx:20:34)
    at @solid-refresh:10:42
    at untrack (chunk-CGI4PW6R.js?v=14626c3e:447:12)
    at Object.fn (@solid-refresh:10:28)
    at runComputation (chunk-CGI4PW6R.js?v=14626c3e:751:22)
    at updateComputation (chunk-CGI4PW6R.js?v=14626c3e:734:3)
    at createMemo (chunk-CGI4PW6R.js?v=14626c3e:253:5)
    at hmrCompWrapper (@solid-refresh:7:20)
    at chunk-CGI4PW6R.js?v=14626c3e:555:1

Your Example Website or App
https://stackblitz.com/edit/solidjs-templates-chv1jk?file=src/pages/index.page.tsx
Steps to Reproduce the Bug or Issue
with npm:

Open the stackblitz link.
Open the console (inspect)
npm i
npm run dev
crash will appear in the console

with pnpm:

Open the stackblitz link.
Open the console (inspect)
pnpm i
pnpm run dev
works fine

Expected behavior
No client-side crash during hydration when run with npm (or any other package manager).
Screenshots or Videos

Platform

OS: macOS
Browser: Chrome
Version: 107
SolidJS: 1.6

Additional context
You can download the project from Stackblitz. Running npm i and pnpm i locally seems to resolve the same SolidJS version.

From my investigation it looks like It's related with nested elements with spread props overriding children. It works if the children prop is used instead of the JSX form. It worked until 1.6. I encountered the same problem, more info in linked issue :)

Thanks for reporting. The last release(1.5) was all about improving server-side Spreads, and this release(1.6) about the client. I would guess a change in the client logic is causing the slight mismatch.

@pawelblaszczyk5 The problem in this issue existed with v1.5 too. Might be unrelated to the other issue you filed.
@ryansolid But why would npm crash and pnpm not?

@pawelblaszczyk5 The problem in this issue existed with v1.5 too. Might be unrelated to the other issue you filed.

Oh, yeah, you're right, I must have checked something incorrectly yesterday. It's not working on v1.5 also, it's the same issue. I also discovered it while trying to use zag 😄

Yeah it's a compiler bug. I found it and should get it out today.

@ryansolid the bug has not been solved. The repro yields the same error with v1.6.2.
Uncaught (in promise) TypeError: Cannot read properties of null (reading 'nextSibling')

Make sure that the babel plugin has updated. babel-preset-solid 1.6.2 will ensure it. I updated the stackblitz template and I think it is working: https://stackblitz.com/edit/solidjs-templates-r53rfw?file=src/pages/index.page.tsx

I can confirm. Works. It seems like NPM has problems resolving babel-preset-solid though which might explain the difference between NPM and PNPM.
If other people run into the issue, I manually added babel-preset-solid to the package JSON. See this commit.

repo: solidjs/solid


text:
Vite patch update

In addition to the "weekly vite patch update", there are two other changes here:

I swapped from windicss to tailwind jit after running into some issues with css ordering in the debugger, but I'm willing to revert this change
I fixed the light theme autocompletion to be readable again

Sounds good! Thank you!

repo: solidui/solid-playground


text:
Race condition in istio NewClientsetFromConfig

NewClientsetFromConfig, located in pkg/api/istio/networking.istio.io/v1beta1/clients.go experiences a race condition due to the use of global variables, such as scheme.Scheme on line 64.
More background and occurrences on the PR here: https://github.com/solo-io/gloo-mesh-enterprise/pull/10267
Example data race
WARNING: DATA RACE
Write at 0x00c00051c150 by goroutine 877:
  runtime.mapassign()
      /home/samu/.go/src/runtime/map.go:578 +0x0
  k8s.io/apimachinery/pkg/runtime.(*Scheme).AddUnversionedTypes()
      /home/samu/go/pkg/mod/k8s.io/apimachinery@v0.24.8/pkg/runtime/scheme.go:128 +0x48c
  k8s.io/apimachinery/pkg/apis/meta/v1.AddToGroupVersion()
      /home/samu/go/pkg/mod/k8s.io/apimachinery@v0.24.8/pkg/apis/meta/v1/register.go:75 +0xa84
  istio.io/client-go/pkg/apis/networking/v1beta1.addKnownTypes()
      /home/samu/go/pkg/mod/istio.io/client-go@v1.15.4/pkg/apis/networking/v1beta1/register.gen.go:61 +0x1084
  k8s.io/apimachinery/pkg/runtime.(*SchemeBuilder).AddToScheme()
      /home/samu/go/pkg/mod/k8s.io/apimachinery@v0.24.8/pkg/runtime/scheme_builder.go:29 +0xe8
  github.com/solo-io/external-apis/pkg/api/istio/networking.istio.io/v1beta1.NewClientsetFromConfig()
      /home/samu/go/pkg/mod/github.com/solo-io/external-apis@v0.1.18/pkg/api/istio/networking.istio.io/v1beta1/clients.go:65 +0x88
  github.com/solo-io/gloo-mesh-enterprise/test.NewIstioClient()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/env.go:789 +0x234
  github.com/solo-io/gloo-mesh-enterprise/test.(*KubeContext).GetVirtualServices()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/env.go:1177 +0x84
  github.com/solo-io/gloo-mesh-enterprise/test/perf/profiles.VirtualServiceMetric.func1()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/perf/profiles/metrics.go:167 +0xce
  github.com/solo-io/gloo-mesh-enterprise/test/perf/profiles.(*MetricsRecord).To.func1()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/perf/profiles/metrics.go:253 +0x60b
  github.com/solo-io/gloo-mesh-enterprise/test/perf/profiles.(*MetricsRecord).To.func2()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/perf/profiles/metrics.go:291 +0xf6
  golang.org/x/sync/errgroup.(*Group).Go.func1()
      /home/samu/go/pkg/mod/golang.org/x/sync@v0.1.0/errgroup/errgroup.go:75 +0x133

Previous read at 0x00c00051c150 by goroutine 873:
  runtime.mapaccess2()
      /home/samu/.go/src/runtime/map.go:456 +0x0
  k8s.io/apimachinery/pkg/runtime.(*Scheme).ObjectKinds()
      /home/samu/go/pkg/mod/k8s.io/apimachinery@v0.24.8/pkg/runtime/scheme.go:267 +0x847
  k8s.io/apimachinery/pkg/runtime.(*parameterCodec).EncodeParameters()
      /home/samu/go/pkg/mod/k8s.io/apimachinery@v0.24.8/pkg/runtime/codec.go:191 +0xfa
  k8s.io/client-go/rest.(*Request).SpecificallyVersionedParams()
      /home/samu/go/pkg/mod/k8s.io/client-go@v0.24.8/rest/request.go:372 +0x199
  k8s.io/client-go/rest.(*Request).VersionedParams()
      /home/samu/go/pkg/mod/k8s.io/client-go@v0.24.8/rest/request.go:365 +0x147
  k8s.io/client-go/kubernetes/typed/core/v1.(*namespaces).List()
      /home/samu/go/pkg/mod/k8s.io/client-go@v0.24.8/kubernetes/typed/core/v1/namespace.go:90 +0x2f4
  github.com/solo-io/gloo-mesh-enterprise/test.(*KubeContext).GetNamespaces()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/env.go:1125 +0x19d
  github.com/solo-io/gloo-mesh-enterprise/test/perf/profiles.NamespaceMetric.func1()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/perf/profiles/metrics.go:117 +0xab
  github.com/solo-io/gloo-mesh-enterprise/test/perf/profiles.(*MetricsRecord).To.func1()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/perf/profiles/metrics.go:253 +0x60b
  github.com/solo-io/gloo-mesh-enterprise/test/perf/profiles.(*MetricsRecord).To.func2()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/perf/profiles/metrics.go:291 +0xf6
  golang.org/x/sync/errgroup.(*Group).Go.func1()
      /home/samu/go/pkg/mod/golang.org/x/sync@v0.1.0/errgroup/errgroup.go:75 +0x133

Goroutine 877 (running) created at:
  golang.org/x/sync/errgroup.(*Group).Go()
      /home/samu/go/pkg/mod/golang.org/x/sync@v0.1.0/errgroup/errgroup.go:72 +0x1ab
  github.com/solo-io/gloo-mesh-enterprise/test/perf/profiles.(*MetricsRecord).To()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/perf/profiles/metrics.go:290 +0x649
  github.com/solo-io/gloo-mesh-enterprise/test/perf_test.glob..func4.3.2()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/perf/perf_test.go:47 +0xcd
  github.com/onsi/ginkgo/v2/internal.extractBodyFunction.func3()
      /home/samu/go/pkg/mod/github.com/onsi/ginkgo/v2@v2.8.4/internal/node.go:463 +0x35
  github.com/onsi/ginkgo/v2/internal.(*Suite).runNode.func3()
      /home/samu/go/pkg/mod/github.com/onsi/ginkgo/v2@v2.8.4/internal/suite.go:854 +0x2d7

Goroutine 873 (running) created at:
  golang.org/x/sync/errgroup.(*Group).Go()
      /home/samu/go/pkg/mod/golang.org/x/sync@v0.1.0/errgroup/errgroup.go:72 +0x1ab
  github.com/solo-io/gloo-mesh-enterprise/test/perf/profiles.(*MetricsRecord).To()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/perf/profiles/metrics.go:290 +0x649
  github.com/solo-io/gloo-mesh-enterprise/test/perf_test.glob..func4.3.2()
      /home/samu/github/solo.io/gloo-mesh-enterprise/test/perf/perf_test.go:47 +0xcd
  github.com/onsi/ginkgo/v2/internal.extractBodyFunction.func3()
      /home/samu/go/pkg/mod/github.com/onsi/ginkgo/v2@v2.8.4/internal/node.go:463 +0x35
  github.com/onsi/ginkgo/v2/internal.(*Suite).runNode.func3()
      /home/samu/go/pkg/mod/github.com/onsi/ginkgo/v2@v2.8.4/internal/suite.go:854 +0x2d7

FYI https://github.com/solo-io/skv2/issues/375

@samuelvl has found a workaround using istio clients directly instead of external-apis. Does this solution have any downsides? Do we have a strong preference for our external-apis for some reason?

authors: fernandosanchezs marcogschmidt

repo: solo-io/external-apis


text:
Don't load fido2-0.9.0

Maybe fixes #110 ?
I don't know python too well, so this might be complete trash. Somehow, I was not able to specify the dependency like this:
>= 0.8, <0.9 or maybe =^0.8.1

AFAIK, the stanza is ~=0.8.1.

AFAIK, the stanza is ~=0.8.1.

authors: nickray uli-heller

repo: solokeys/solo-python


text:
Missing Code

I'm attempting this robot project: https://www.instructables.com/So-Many-Robots-DIY-Print-in-Place-Robot-for-STEM-L/
I went to grab the code for the project, and found that the code is missing and there is only an apache licensing agreement.  Was this meant to be available?

https://www.instructables.com/So-Many-Robots-DIY-Print-in-Place-Robot-for-STEM-L/
Step 5: Flash Robot Explorer Firmware
Can download the file  Robot Explorer.uf2 to flash the firmware. The uf2 file contains Python files and related dependencies.
Source code can be loaded by editing in Thonny, see https://projects.raspberrypi.org/en/projects/getting-started-with-the-pico/0 for additional info on getting started.

authors: somanyrobots-io strikermed

repo: somany-io/robot


text:
Symbol Instance Locator Plugin doesn't work since Sketch 96

The Symbol Instance Locator plugin unfortunately seems to have stopped working since Sketch version 96 (at least for me). I select a symbol as usual and want to use the plugin to show where instances are used in my Sketch document. The plug-in window appears, but remains without content or results (even after minutes of waiting).
I have also consulted the Sketch forum on this matter:
https://forum.sketch.com/t/symbol-instance-locator-plugin-doesnt-work-since-sketch-96/892
With kind regards
Christian

Same

Same here too

Same here

The lack of response and update probably means we can't rely on this being fixed then... which is a real shame.

Same

authors: ApamCS bl-cs derEhrenwerte jazzybeat kujass

repo: sonburn/symbol-instance-locator


text:
chore: update code implementation

一些 linters 告警的小 fix，没有功能变更，自测 OK。

Improved error handling in various modules for better stability and responsiveness.
Optimized code in several files for improved efficiency and readability.
Enhanced user experience by providing more detailed error responses in the controller.
Strengthened security by ignoring sensitive files in .gitignore.

自测

Thx~

authors: Laisky songquanpeng

repo: songquanpeng/one-api


text:
[Mixed Precision DNNs]: ImageNet codebase?

Can you share the working codebase to replicate paper results for ImageNet with MixedPrecisionQuantization?

Thank's for the interest in our work. Following your request, we will start the process of releasing the training code for the ImageNet experiments as well. However, this might take a while.
In the mean time, I can share the configuration files for the training with you. You should be able to adapt the existing code, provided that you have a working dataloader for ImageNet. The naming convention for the experiments is similar to the CIFAR10 experiments.
I will announce here, as soon as the code has been released.
train_mobilenet2.txt
train_resnet18.txt

repo: sony/ai-research-code


text:
feat/#651 stamp api + rank api

What is this issue?

[x] stamp api
[x] rank api

To Reviewer

서버에서 이미지 업로드 관련으로 문제가 하나 있어 아직 해결중입니다!
그래서 pre-signed url에 주석을 붙여두었습니다! 추후 서버에서 해결이 된다면 테스트 후 지우도록 하겠습니당
아래 코드의 경우 const를 넣고싶지만, const를 붙이니 spotlessApply에서 오류가 나오더라구요... 그래서 그냥 뒀습니다

private val startYear = 1950
private val endYear = 2100

@chattymin 미완된 PR이라면 Draft + DO NOT MERGE 달아놓는 것이 좋아보여요 !!

오 이런기능도 있군요!! 감사합니다!!
구현은 다 했는데 서버가 불안정한거라 코드리뷰는 받고싶어서 draft는 안하고 DO NOT MERGE만 달아뒀습니다 ㅎㅎㅎ
다음번에 잘 활용하겠습니당

repo: sopt-makers/sopt-android


text:
[Feature]: Show locked and unlocked tokens

User stories

As a
I want to
So that

Investor of project / Founders and advisors
I want to see my RLST tokens
To fit comfortable

Participant team
I want to notify blockchain about listing token

Acceptance criteria

The investor buys RLST tokens and enters the SORA accounts on the website.

The team checks and balances and shares their token amount with the investor.

Polkaswap allows tokens to be sent from the corporate wallet to the investor wallet.

The protocol locks all RLST tokens in the holder wallets for 10 months.
Each month the protocol unlocks 10% of the initial number of tokens.

In 10 months all tokens will be unlocked.

Polkaswap shows the Investor locked tokens and available tokens.

Polkaswap shows a timer when tokens will be available. (Optional)

The founders and advisors get their RLST tokens on SORA accounts.

The team shares a number of RLST tokens with founders and advisors.
The protocol locks all RLST tokens in the holder wallets for 6 months.
Each month the protocol unlocks 10% of the initial number of tokens on the founder's and advisor's accounts 6 months after listing on an exchange.

The team has a notification tool to say about the listing (UI or manually in the blockchain).
Polkaswap shows the founders' and advisors' locked tokens and available tokens.

Polkaswap shows a timer when tokens will be available. (Optional)

Definition of Done

[ ] The investor sees locked and unlocked tokens.
[ ] The founder and advisor see locked and unlocked tokens.
[ ] The user can see how much time until the unlocked action. (Optional)
[ ] The Rapido team has the opportunity to notify about the listing token. (Optional)

Verified on https://exchange-1564.dev.sora2.tachi.soramitsu.co.jp/#/wallet

The user can see how much time until the unlocked action. (Optional)
The Rapido team has the opportunity to notify about the listing token. (Optional)

repo: sora-xor/polkaswap-exchange-web


text:
ext_storage_next_key

Gets the next key in storage after the given one in lexicographic order. Use cursor for implementation
E.1.9.1 Version 1 - Prototype
(func $ext_storage_next_key_version_1 (param $key i64) (return i64))
Arguments :

key: a pointer-size as defined in Definition E.2 indicating the key.
return: a pointer-size as defined in Definition E.2 indicating the SCALE encoded Option as defined in Definition B.4 containing the next key in lexicographic order.

Aha! Link: https://soramitsucoltd.aha.io/requirements/PRE-43-2

Closed in #391

authors: kamilsa kogeler

repo: soramitsu/kagome


text:
[monitor] 配信画面のメモリリーク

連日配信を続けていると、OBS Studioのメモリ使用量がどんどん増加していく。
なおページの更新で解消しない模様。
chromeのタスクマネージャー等で確認する。

配信開始後24時間経過でこの状態。
まだ問題なさそう。

repo: sorarideblog/youtube-study-space


text:
Uncaught TypeError: Cannot read property 'scrollHeight' of null

Using jQuery 1.10.2, you get the following error from jquery.js
Uncaught TypeError: Cannot read property 'scrollHeight' of null
at jquery-1.10.2.js:9754
at Function.access (jquery-1.10.2.js:900)
at jQuery.fn.init.jQuery.fn.(anonymous function) [as height] (../Scripts/jquery-1.10.2.js:9737:18)
at o._showBackground (bootstrap-tour-standalone.min.js:22)
at o._showOverlayElement (bootstrap-tour-standalone.min.js:22)
at o._showPopoverAndOverlay (bootstrap-tour-standalone.min.js:22)
at o._showPopoverAndOverlay (bootstrap-tour-standalone.min.js:22)
at o._scrollIntoView (bootstrap-tour-standalone.min.js:22)
at o. (bootstrap-tour-standalone.min.js:22)
at o._callOnPromiseDone (bootstrap-tour-standalone.min.js:22)

@sorich87 please have look into it and resolve it.

license: mit

license_source: bigquery


text:
Load fields_sources_list only one

Each instantiation Scientist() loads the field-source definition anew: https://github.com/sosia-dev/sosia/blob/master/sosia/classes/scientist.py#L276
This slows down find_matches() a lot.
Need to find a way to avoid reloading everything.

Long obsolete, due to sosia.get_field_source_information()

repo: sosia-dev/sosia


text:
Allow truncation of incomplete local archive

This makes it possible to truncate an archive that has only some MSIDs.  It does require archfiles.db3 and colnames.pickle in every content dir, but not all content dirs need be defined.

I tested with a local archive that has a variety of cases wrt to missing / incomplete files. The updates did the right thing and truncated the archive appropriately.


text:
Extent.forCoordinates() does not correctly calculate the Extent with negative longitudes

maxLatitude and maxLongitued are primed with Double.MIN_VALUE which is the smallest positive double value (very, verry tiney, but still positive). They should actually be primed with -Double.MAX_VALUE which will be the smallest double possible (a negative number). See: http://stackoverflow.com/questions/3884793/why-is-double-min-value-in-not-negative

thanks for reporting that mistake! Fixed and deployed in 1.7.2. Should be on it's way to maven central.

authors: gmatrangola sothawo

repo: sothawo/mapjfx


text:
设置自己的icon

大佬写的这个我十分喜欢，设置了一下午。不知道大佬是否愿意让我们自己设置Icon

你好👋 @chiyixiaobu ，关于这个问题，可以参考 https://github.com/soulteary/docker-flare/issues/37 这里。

authors: chiyixiaobu soulteary

repo: soulteary/docker-flare


text:
Fix graphic assets management

Currently, each actor manages its own graphic assets individually. Objects of same class read the same assets multiple times in memory, which is obviously a very bad idea.
To fix this, implement a graphics cache: once a level starts, find all objects that have been used and call a static graphics bootstrapping static method on each. Load one copy of each sprite at most even if it was requested from multiple different objects. Keep the sprites in memory until the end of level or end of game. The object constructors need to be adapted to this.
Also, while changing the way the graphics are loaded, externalize the previously hardcoded values from the code to data files (XML or equivalent).

Other than that level load time resource retrieval, the applicable animation states in the manifests should also be migrated off the arbitrary number values to something more legible. (for example: "states": ["jump shoot", "fall shoot", "jump walk shoot"])

This still seems quite troublesome after putting a lot of thought and trying a failed code experiment. Some pointers:

AnimStateT should be scrapped completely. Anything that uses that type should convert to using identifier QStrings.
AnimationUser already has a function for setting the animation by the string key unique to an animation. This should be changed to accept either those keys or a key from any animation's states.
Instead of AnimationUsers having a currentAnimation and currentTransition with the latter having more options (cancellable, callback once finished), these should be combined instead. Theoretical API could bebool setAnimation(const QString& key, bool repeat = true, bool cancellable = true, AnimationCallbackFunc cb = []() { });
bool setAnimation(std::shared_ptr<GraphicResource> animation, bool repeat = true, bool cancellable = true, AnimationCallbackFunc cb = []() { });

CommonActor's overridden function could probably be simplified and replaced with one that just passes parameters forward to AnimationUser's function and runs updateHitbox() if it returned true. The transition stuff doesn't really have any reason to be there, it's pretty much Player specific.

Note: the last point of the previous comment was mostly dealt with in one of the collision revamp commits.


text:
Build broken with master?

Here's the error log:
-- Found Torch7 in ...
-- CUDNN_INSTALL: Installing CUDNN 5.1, lib:.../torch/install/lib, inc:.../torch/install/include, bin:.../torch/install/bin
CMake Error at cmake/FindCUDNN.cmake:97 (get_filename_component):
  get_filename_component unknown component DIRECTORY
Call Stack (most recent call first):
  CMakeLists.txt:17 (CUDNN_INSTALL)

-- Found CUDNN: .../torch/install/lib/libcudnn.so.5 (found suitable exact version "5")
-- Configuring incomplete, errors occurred!

Error: Build error: Failed building.

However, I was able to get it to install by reverting to commit 93d17a11bd5016782ec3da59407917e8dcff879c

Looks like it's breaking on DIRECTORY, perhaps your CMake is <= 2.8.11?
https://cmake.org/cmake/help/v3.0/command/get_filename_component.html
@shivak, can you please fix your commit so that it does not break for older CMakes?

authors: ngimel sidharthms


text:
Non-Deterministic Shorthand-Longhand Resolution

I just found this library on Twitter and really like it, great job!
As the author of fela, I've been working with Atomic CSS for quite a while and stumbled into an issue that I now also face with restyle. I wrote a long article about it, but let me try to sum it up with a little replication:
Due to Atomic CSS, the order of rules matters a lot in stylesheets. This is especially important when mixing shorthand and longhand properties e.g. padding and paddingLeft. Right now, style resolution is not deterministic. Instead the order determines what styles are applied in the end. Here's a little example:
import { css } from "restyle"

function Box({ style, as: As, children }) {
  const [className, styles] = css(style)

  return <>{styles}<As className={className}>{children}</As></>
}

const App = (
  <>
    <Box style={{ padding: 0, paddingLeft: 20 }}>Box 1</Box>
    <Box style={{ paddingLeft: 20, padding: 0 }}>Box 2</Box>
  </>
)

In this example, paddingLeft is rendered last, so both elements get a 20px left padding. If you switch the elements up, both get a 0px left padding. This example is simplified of course, but it shows the essence of the issue.
The way we solved it in Fela (see article) is using repeated selectors e.g.
.a.a { padding-left: 20px }
.b { padding: 0px }

That way the output is always deterministic. In this case favouring longhands, but could be a configuration option of course. I know this might require sth. like a createCSS factory with configuration options of some sort, but without I'm afraid I can't really safely use it in production.
Oh, and not mixing those also doesn't really work, as I often extend my components multiple times merging a dozens of style objects which eventually might result in mixed styles.

Thank you for the kind words and filing an issue for this!
My plan to solve this was always parsing rules into long-form and merging them together while only returning the class names that should be applied. For example:
padding: '0px calc(1h - 1ch) 1rem' -> { paddingTop: '0px', paddingRight: 'calc(1h - 1ch)', paddingBottom: '1rem', paddingLeft: 'calc(1h - 1ch)' }
Just checked your article and wondering if I should lock it down and require only long-form properties though 🤔 since there's no build step I do want to keep an eye on performance. The repeated selectors implementation is a nice workaround! Another option could be a strict mode that didn't allow shorthand properties to reduce additional processing.

I also tried expanding shorthands at some point (see article) which resulted in another package inline-style-expand-shorthand, but that method has some clear downsides:

increased bundle size:  bundlephobia is down right now, but it adds quite some code to the bundle
performance: needless to say, every object iteration is a performance hit on client components
complexity: padding might be an easy one, but breaking down border and other shorthands can be a tricky task

I'm all in on restrictive APIs, but I'm not sure that requiring only long-form properties would be please most users 🥲

I took a look at expanding shorthands, but like you said it has downsides. I ended up with a nice approach that didn't increase the bundle size too much that takes advantage of the precedence prop. Details are in https://github.com/souporserious/restyle/pull/3 if you're curious. Thanks again for filing an issue!

authors: robinweser souporserious

repo: souporserious/restyle


text:
chore(deps): loopback version updates

GH-50
Description
Loopback version updates
Fixes # (issue)
GH-50
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Intermediate change (work in progress)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Test A
[ ] Test B

Checklist:

[ ] Performed a self-review of my own code
[x] npm test passes on your machine
[ ] New tests added or existing tests modified to cover all changes
[ ] Code conforms with the style guide
[ ] API Documentation in code was updated
[ ] Any dependent changes have been merged and published in downstream modules

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


text:
cloud: add ui access docs

DO NOT MERGE until Entitle is announced by #security officially

Current dependencies on/for this PR:

main

PR #5715   👈

This comment was auto-generated by Graphite.

FYI: Converted to "Draft" so no one can hit "Merge" by accident.

authors: michaellzc unknwon

repo: sourcegraph/handbook


text:
Too many incidental dependencies.

This issue is largely documented downstream at https://github.com/shurcooL/go/issues/19#issuecomment-97699653, but to quickly summarize:
After #11 was merged, syntaxhighlight package now indirectly imports an extremely large number of imports that are largely unrelated and unneeded to the core functionality of this package.

https://godoc.org/github.com/sourcegraph/syntaxhighlight?import-graph&hide=1
The vast majority of that is coming from the two imports sourcegraph.com/sourcegraph/go-sourcegraph/sourcegraph and sourcegraph.com/sourcegraph/vcsstore/vcsclient which are only needed to pull in the following types:

vcsstore.FileWithRange
sourcegraph.SourceCode
sourcegraph.SourceCodeLine
sourcegraph.SourceCodeToken

Despite those types being relatively small, the packages that contain them are higher level and import many other dependencies that are unneeded.
We should fix this so that users of syntaxhighlight that only need the core functionality and do not use the NilAnnotator should not need to pull in that many dependencies.

I'm planning to tackle this now.
I've been thinking about how to best resolve this, but so far the best idea I've come up with is this.
We can simply move NilAnnotator and the needed imports into a separate package that imports syntaxhighlight. It could be a subpackage "github.com/sourcegraph/syntaxhighlight/tokenizer" or a separate repository.
That could be a temporary solution until we have something better. But it would resolve the issue and not cause many problems. Thoughts? /cc @gbbr @sqs

I am removing this functionality and putting it into the app for now as it is mostly irrelevant to the purpose of this package. Will close this issue as soon as that has been completed.

The import graph looks a lot better now!

http://godoc.org/sourcegraph.com/sourcegraph/syntaxhighlight?import-graph&hide=1

LOL!
On Tuesday, May 12, 2015, Dmitri Shuralyov notifications@github.com wrote:

The import graph looks a lot better now!
[image: image]
http://godoc.org/sourcegraph.com/sourcegraph/syntaxhighlight?import-graph&hide=1
http://godoc.org/sourcegraph.com/sourcegraph/syntaxhighlight?import-graph&hide=1
—
Reply to this email directly or view it on GitHub
https://github.com/sourcegraph/syntaxhighlight/issues/15#issuecomment-101117144
.

authors: gbbr shurcooL

repo: sourcegraph/syntaxhighlight


text:
Update elasticsearch_test.go

Summary by CodeRabbit

Chores

Added a commented-out line for potential future use in Elasticsearch integration tests. No changes to the functionality or public interface.

This is an experiment review for experiment multiple_mermaid_diagram_types
Run ID: multiple_mermaid_diagram_types/run_2024-09-30T19-14-26_v1-23-0-43-g5f7f3998a
The benchmark review for this pull request can be found at https://github.com/sourcery-ai-experiments/jaeger/pull/7.
This pull request was cloned from https://github.com/chintu-777/jaeger/pull/1. (Note: the URL is not a link to avoid triggering a notification on the original pull request.)

Experiment configuration
review_config:
  # User configuration for the review
  # - benchmark - use the user config from the benchmark reviews
  # - <value> - use the value directly
  user_review_config:
    enable_ai_review: true
    enable_rule_comments: false

    enable_complexity_comments: false
    enable_security_comments: false
    enable_tests_comments: false
    enable_comment_suggestions: false
    enable_functionality_review: false

    enable_pull_request_summary: false
    enable_review_guide: true

    enable_approvals: false

  ai_review_config:
    # The model responses to use for the experiment
    # - benchmark - use the model responses from the benchmark reviews
    # - llm - call the language model to generate responses
    model_responses:
      comments_model: benchmark
      comment_area_model: benchmark
      comment_validation_model: benchmark
      comment_suggestion_model: benchmark
      complexity_model: benchmark
      functionality_model: benchmark
      security_model: benchmark
      tests_model: benchmark
      pull_request_summary_model: benchmark
      review_guide_model: llm
      overall_comments_model: benchmark

# The pull request dataset to run the experiment on
pull_request_dataset:
  # Sourcery core examples:
- https://github.com/sourcery-ai/core/pull/4607
- https://github.com/sourcery-ai/core/pull/4631
- https://github.com/sourcery-ai/core/pull/4647
  # CodeRabbit examples:
- https://github.com/2lambda123/-Orange-OpenSource-oorobot/pull/15
- https://github.com/2lambda123/galaxyproject-galaxy/pull/12
- https://github.com/a0v0/avtoolz/pull/79
- https://github.com/adityask98/Hotaru/pull/10
- https://github.com/agdas/vscode/pull/2
- https://github.com/agluszak/hirschgarten/pull/2
- https://github.com/alexsnow348/insightface/pull/46
- https://github.com/alikuxac/utilities/pull/10
- https://github.com/AlphaDev87/timba-api/pull/49
- https://github.com/AngeloTadeucci/Maple2/pull/239
- https://github.com/AngeloTadeucci/Maple2.File/pull/36
- https://github.com/AngeloTadeucci/Maple2/pull/233
  # Examples where CodeRabbit does not generate diagrams
- https://github.com/baptisteArno/typebot.io/pull/1778
- https://github.com/btipling/foundations/pull/33
- https://github.com/btipling/foundations/pull/31
- https://github.com/chintu-777/jaeger/pull/1
- https://github.com/coji/remix-docs-ja/pull/55
- https://github.com/DaveMBush/SmartNgRX/pull/622
- https://github.com/DaveMBush/SmartNgRX/pull/481
- https://github.com/dkittle/party-connections/pull/6
- https://github.com/Drajad-Kusuma-Adi/onstudy-backend/pull/6
- https://github.com/imaami/libcanth/pull/2
  # Requested by Tim
- https://github.com/2lambda123/-Orange-OpenSource-oorobot/pull/15
- https://github.com/2lambda123/galaxyproject-galaxy/pull/12
- https://github.com/a0v0/avtoolz/pull/79
- https://github.com/adityask98/Hotaru/pull/10
- https://github.com/agdas/vscode/pull/2
- https://github.com/agluszak/hirschgarten/pull/2
- https://github.com/4DNucleome/PartSeg/pull/1183
- https://github.com/ably/ably-cocoa/pull/1973
- https://github.com/ably-labs/ably-chat-swift/pull/54
- https://github.com/ably-labs/ably-chat-swift/pull/35
  # A ton of new classes:
- https://github.com/sourcery-ai/core/pull/4618
  # Including database changes to evaluate entity-relationship diagrams
- https://github.com/sourcery-ai/core/pull/4579
  # TODO: find some with Alembic
  # Brilliant existing examples:
- https://github.com/sourcery-ai/core/pull/4680
- https://github.com/sourcery-ai/core/pull/4684

# Questions to ask to label the review comments
review_comment_labels: []
# - label: correct
#   question: Is this comment correct?

# Benchmark reviews generated by running
#   python -m scripts.experiment benchmark <experiment_name>
benchmark_reviews:
- dataset_pull_request: https://github.com/sourcery-ai/core/pull/4607
  review_pull_request: https://github.com/sourcery-ai-experiments/core/pull/374
- dataset_pull_request: https://github.com/sourcery-ai/core/pull/4631
  review_pull_request: https://github.com/sourcery-ai-experiments/core/pull/375
- dataset_pull_request: https://github.com/sourcery-ai/core/pull/4647
  review_pull_request: https://github.com/sourcery-ai-experiments/core/pull/376
- dataset_pull_request: https://github.com/2lambda123/-Orange-OpenSource-oorobot/pull/15
  review_pull_request: https://github.com/sourcery-ai-experiments/-Orange-OpenSource-oorobot/pull/5
- dataset_pull_request: https://github.com/2lambda123/galaxyproject-galaxy/pull/12
  review_pull_request: https://github.com/sourcery-ai-experiments/galaxyproject-galaxy/pull/13
- dataset_pull_request: https://github.com/adityask98/Hotaru/pull/10
  review_pull_request: https://github.com/sourcery-ai-experiments/Hotaru/pull/14
- dataset_pull_request: https://github.com/agdas/vscode/pull/2
  review_pull_request: https://github.com/sourcery-ai-experiments/vscode/pull/14
- dataset_pull_request: https://github.com/agluszak/hirschgarten/pull/2
  review_pull_request: https://github.com/sourcery-ai-experiments/hirschgarten/pull/13
- dataset_pull_request: https://github.com/alikuxac/utilities/pull/10
  review_pull_request: https://github.com/sourcery-ai-experiments/utilities/pull/4
- dataset_pull_request: https://github.com/AlphaDev87/timba-api/pull/49
  review_pull_request: https://github.com/sourcery-ai-experiments/timba-api/pull/12
- dataset_pull_request: https://github.com/AngeloTadeucci/Maple2/pull/239
  review_pull_request: https://github.com/sourcery-ai-experiments/Maple2/pull/23
- dataset_pull_request: https://github.com/AngeloTadeucci/Maple2.File/pull/36
  review_pull_request: https://github.com/sourcery-ai-experiments/Maple2.File/pull/12
- dataset_pull_request: https://github.com/AngeloTadeucci/Maple2/pull/233
  review_pull_request: https://github.com/sourcery-ai-experiments/Maple2/pull/24
- dataset_pull_request: https://github.com/baptisteArno/typebot.io/pull/1778
  review_pull_request: https://github.com/sourcery-ai-experiments/typebot.io/pull/7
- dataset_pull_request: https://github.com/btipling/foundations/pull/33
  review_pull_request: https://github.com/sourcery-ai-experiments/foundations/pull/13
- dataset_pull_request: https://github.com/btipling/foundations/pull/31
  review_pull_request: https://github.com/sourcery-ai-experiments/foundations/pull/14
- dataset_pull_request: https://github.com/chintu-777/jaeger/pull/1
  review_pull_request: https://github.com/sourcery-ai-experiments/jaeger/pull/7
- dataset_pull_request: https://github.com/coji/remix-docs-ja/pull/55
  review_pull_request: https://github.com/sourcery-ai-experiments/remix-docs-ja/pull/7
- dataset_pull_request: https://github.com/DaveMBush/SmartNgRX/pull/622
  review_pull_request: https://github.com/sourcery-ai-experiments/SmartNgRX/pull/13
- dataset_pull_request: https://github.com/DaveMBush/SmartNgRX/pull/481
  review_pull_request: https://github.com/sourcery-ai-experiments/SmartNgRX/pull/14
- dataset_pull_request: https://github.com/dkittle/party-connections/pull/6
  review_pull_request: https://github.com/sourcery-ai-experiments/party-connections/pull/7
- dataset_pull_request: https://github.com/Drajad-Kusuma-Adi/onstudy-backend/pull/6
  review_pull_request: https://github.com/sourcery-ai-experiments/onstudy-backend/pull/7
- dataset_pull_request: https://github.com/imaami/libcanth/pull/2
  review_pull_request: https://github.com/sourcery-ai-experiments/libcanth/pull/7
- dataset_pull_request: https://github.com/2lambda123/-Orange-OpenSource-oorobot/pull/15
  review_pull_request: https://github.com/sourcery-ai-experiments/-Orange-OpenSource-oorobot/pull/6
- dataset_pull_request: https://github.com/2lambda123/galaxyproject-galaxy/pull/12
  review_pull_request: https://github.com/sourcery-ai-experiments/galaxyproject-galaxy/pull/14
- dataset_pull_request: https://github.com/adityask98/Hotaru/pull/10
  review_pull_request: https://github.com/sourcery-ai-experiments/Hotaru/pull/15
- dataset_pull_request: https://github.com/agdas/vscode/pull/2
  review_pull_request: https://github.com/sourcery-ai-experiments/vscode/pull/15
- dataset_pull_request: https://github.com/agluszak/hirschgarten/pull/2
  review_pull_request: https://github.com/sourcery-ai-experiments/hirschgarten/pull/14
- dataset_pull_request: https://github.com/4DNucleome/PartSeg/pull/1183
  review_pull_request: https://github.com/sourcery-ai-experiments/PartSeg/pull/7
- dataset_pull_request: https://github.com/ably/ably-cocoa/pull/1973
  review_pull_request: https://github.com/sourcery-ai-experiments/ably-cocoa/pull/6
- dataset_pull_request: https://github.com/ably-labs/ably-chat-swift/pull/54
  review_pull_request: https://github.com/sourcery-ai-experiments/ably-chat-swift/pull/11
- dataset_pull_request: https://github.com/ably-labs/ably-chat-swift/pull/35
  review_pull_request: https://github.com/sourcery-ai-experiments/ably-chat-swift/pull/12
- dataset_pull_request: https://github.com/sourcery-ai/core/pull/4579
  review_pull_request: https://github.com/sourcery-ai-experiments/core/pull/377

🧙 Sourcery is reviewing your pull request!

Tips and commands
Interacting with Sourcery

Trigger a new review: Comment @sourcery-ai review on the pull request.
Continue discussions: Reply directly to Sourcery's review comments.
Generate a GitHub issue from a review comment: Ask Sourcery to create an
issue from a review comment by replying to it.

Customizing Your Experience
Access your dashboard to:

Enable or disable review features such as the Sourcery-generated pull request
summary, the reviewer's guide, and others.
Change the review language.
Add, remove or edit custom review instructions.
Adjust other review settings.

Getting Help

Contact our support team for questions or feedback.
Visit our documentation for detailed guides and information.
Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

authors: SourceryAI ruancomelli

repo: sourcery-ai-experiments/jaeger


text:
Very slow extension activation time

In the past few days, I have noticed a very slow activation time of Sourcery—1370ms.

Thanks a lot for reporting this. :+1:  It's very slow indeed.
Can you give some info about your system?

OS
VSCode version

Does this lead to a noticeable delay or hanging? Or is this long activation time visible only on the "Running Extensions" tab?

macOS Monterey 12.6.5
VS Code Version: 1.79.2

I haven't seen any big slowdowns, but I'm sure it impacts some places.

+1 If you run Developer: Show Running Extensions in the VS Code command palette, Sourcery 1.4.0 is (by far) the longest loading VS Code extension.   Mine is showing 8212 ms!  8.2 seconds.  For comparison, Pylance is only 1135 ms.
How can we reduce the extension loading time?

Am looking into addressing this.

@cpoptic @xshapira could you please install the latest version (1.5.0) and check the activation time? Want to make sure we've addressed the issue.

Fixed. Great job guys!

authors: Hellebore cpoptic reka xshapira

repo: sourcery-ai/sourcery-vscode


text:
No resource or method named 'build_essential'

Hi guys, I have a problem trying to use the recipe.
My chef version is: 12.11.18
From what I read in the issues closed, they speak of problems in the version of chef 11, but in version 12? or why do I see this error?
Error:
No resource or method named 'build_essential' for 'Chef::Recipe install

Cookbook Trace:

▽
---------------

▽
source 'https://supermarket.chef.io'
  /var/chef/cache/cookbooks/sc-mongodb/recipes/install.rb:4:in 'from_file'
  /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/run_context.rb:347:in 'load_recipe'
  /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/run_context.rb:303:in 'block in include_recipe'
  /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/run_context.rb:302:in 'each'
  /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/run_context.rb:302:in 'include_recipe'
  /var/chef/cache/cookbooks/sc-mongodb/recipes/default.rb:22:in `from_file'
  /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/run_context.rb:347:in 'load_recipe'
  /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/run_context.rb:303:in 'block in include_recipe'
  /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/run_context.rb:302:in 'each'
  /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/run_context.rb:302:in 'include_recipe'

Relevant File Content:
----------------------
/var/chef/cache/cookbooks/sc-mongodb/recipes/install.rb:

  1:  # install the mongodb_org_repo if necessary
  2:  include_recipe 'sc-mongodb::mongodb_org_repo' if %w(10gen mongodb-org).include?(node['mongodb']['install_method'])
  3:
  4>> build_essential 'build-tools'
  5:
  6:  # prevent-install defaults, but don't overwrite
  7:  file node['mongodb']['sysconfig_file'] do
  8:    content 'ENABLE_MONGODB=no'
  9:    group node['mongodb']['root_group']
 10:    owner 'root'
 11:    mode 0644
 12:    action :create_if_missing
 13:  end

Platform:
---------
x86_64-linux

My recipe test:
node.default['mongodb']['config']['mongod']['replication']['replSetName'] = 'test'

include_recipe 'sc-mongodb::default'

It's not listed in the README file, but sc-mongodb does depend on the build-essential cookbook

Hi @devsibwarra devsibwarra, thanks for your answer.
Yes, I saw that link, but I can't run recipe.
This are my test:

metadata.rb with depends 'build_essential', '5.0.0'

name              'sc-mongo'
maintainer        'Sous Chefs'
maintainer_email  'help@sous-chefs.org'
license           'Apache-2.0'
description       'Installs and configures mongodb'
long_description  'Installs and configures mongodb'
version           '1.0.0'

depends 'build-essential', '>= 5.0.0'
depends 'sc-mongodb'

supports 'ubuntu'

ERROR
I have this error:
>>>>>>     Failed to complete #converge action: [There is a dependency conflict, but the solver could not determine the precise cause in the time allotted.
Unable to find a solution for demands: 7-zip (1.0.2), apt (2.9.2), ark (3.1.0), aws (7.2.1), bluepill (2.4.3), build-essential (2.4.0)....

metadata.rb with only 'build_essential' (without version) and without 'build_essential', are both show the same message:

Error:
NoMethodError
-------------
No resource or method named `build_essential' for `Chef::Recipe "install"'

Cookbook Trace:
---------------
 /tmp/kitchen/cache/cookbooks/sc-mongodb/recipes/install.rb:4:in 'from_file'
 /tmp/kitchen/cache/cookbooks/sc-mongodb/recipes/default.rb:22:in 'from_file'

@rponcetn The dependency conflict error is giving pretty good details on what Chef requires to run.
Some cookbook is requiring those listed cookbooks (7-zip, apt, ark, aws, etc) be installed with at least those versions.
The build-essential (2.4.0) part of the error message indicates one of your other cookbooks is requiring that specific version, or major/minor version, and it may need updated before Chef will run.  I'd try searching for depends lines across all your cookbooks to locate conflicting dependencies or older lines that need updated.

authors: devsibwarra rponcetn

repo: sous-chefs/mongodb


text:
Standardise files with files in sous-chefs/repo-management

Signed-off-by: Dan Webb dan.webb@damacus.io

Released as: 5.0.2

authors: damacus kitchen-porter

repo: sous-chefs/transmission


text:
[Samples][Java] Fix disparities of 80.skills-simple-bot-to-bot sample

Related to microsoft/botbuilder-java1165
Proposed Changes
We compared the documentation/code migration/behavior of the 80.skills-simple-bot-to-bot sample between Java and C# and we found disparities and fixes that this PR includes.

Update README
Add missing comments
Clean-up autogenerated files/folder related to Eclipse (e.g. target/.classpath)
Add package-info.java files

Testing
Skills simple bot to bot sample working as expected

Merged in MS

repo: southworks/BotBuilder-Samples


text:
Change confirmation button partial views behavior

Purpose

When the color selected by personalizer for the button is orange the button is displayed on the top and when its blue its displayed on the bottom.

Does this introduce a breaking change?

[ ] Yes
[x] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

Please add confirm purchase button label to the config file

Fixed!


text:
代码报红，但是能正常运行，是哪个插件配置错了吗？

User 的类型没有定义正确

已解决，刚学TS，不是很熟练

repo: soybeanjs/soybean-admin


text:
HTTP Client

Add HTTP client example.

Merging so everyone can start using http client!


text:
New Release Doesn't Fix SORT and install.sh doesn't work

I just installed the newest version of himalaya(v0.5.7). I did git clone https://github.com/soywod/himalaya.git && cd himalaya && doas sh install.sh. The correct version was supposedly installed because of install.sh's output.
Downloading latest linux release…
Installing binary…
himalaya 0.5.7 installed!

But, I still get the SORT command error.
Error: cannot search in "INBOX" with query "all"

Caused by:
    Bad Response: Unknown command: SORT

I checked the output of himalaya -V and it returned himalaya 0.5.6. Did I install it wrong or is the installer broken?

The version that you have to use root didn't work for me, but the regular user worked perfectly. Thank you!

repo: soywod/himalaya


text:
3.8.0 - Airsoft Magazine

General information:
Airsoft PMAG Magazine (6241c2c2117ad530666a5108) spawned within a Weapon Box (6x3 Grey Large Long Box).

Attachments

65988eb30001fbdb6f6af6c3.zip (54 KiB)
2024-01-09[16-18]_493.4, 15.6, 128.3_0.4, 0.2, -0.1, 0.9_2.15 (0).png (1201 KiB)

Originally written by Jester_Stacks

So you're aware, all loot is generated using data dumped directly from Live. If the airsoft mag is showing up, that means it's still in the offline loot pool and can potentially be spawned.

Originally written by PhantomInTime

Can confirm the mag is supposed to appear as raid loot, weird i know!

Originally written by chomp

repo: sp-tarkov/server

license: NCSA


text:
"WildSpawnTypeNumber" in Server doesn't match Client Assembly

General information:
Project issue is for:
Server
Expected result:
"WildSpawnTypeNumber.ts" should match the values in "WildSpawnType.cs"
Actual result:
The server is missing "bossZryachiy" and "followerZryachiy", so currently SptUsec and SptBear are using those numbers

Originally written by DrakiaXYZ

Fixed with: https://dev.sp-tarkov.com/SPT-AKI/Server/commit/e8f53e1fcd663a3f0f9c8bf392b50daa4b95f9b6

Originally written by chomp


text:
Штамп психолога спавнится у психолога в сумке

Описание PR

Медиа

Проверки

[x] PR полностью завершён и мне не нужна помощь чтобы его закончить.
[x] Я внимательно просмотрел все свои изменения и багов в них не нашёл.
[ ] Я запускал локальный сервер со своими изменениями и всё протестировал.
[ ] Я добавил скриншот/видео демонстрации PR в игре, или этот PR этого не требует.

Изменения

:cl:

tweak: У психолога в сумке теперь спавнится штамп психолога

Крутой


text:
Carp can hit you through boxes

Description

Carp hit me through the box when I had closed it in. I suspect this is a problem with the new melee system in general.
Screenshots

https://user-images.githubusercontent.com/91828755/193386116-7ef1f810-ca85-46f5-9d94-07a48927c6f2.mp4

Seems to be still happening, in the reverse at least. Carps can attack you if you are in a locker.

There was a PR but it only fixed half the problem https://github.com/space-wizards/space-station-14/pull/13988

Fixed.

authors: Pangogie Scribbles0 metalgearsloth themias


text:
Forensics shouldn't work when paused

Found this in a map file

Also, fingerprints are generated on init rather than on mapinit

authors: ElectroJr metalgearsloth


text:
Zombie doesn't get anything in chat for what they have become

Description

Become zombie
You get nothing in chat about this
Somehow traitor manages to get 13 paragraphs of text about the same situation

They used to have a popup? Did it break?

This is fixed now. An additional entry to the objectives menu was added in #29259

authors: DrSmugleaf EmoGarbage404 slarticodefast


text:
Fix drobes and lockers contents

About the PR
This removes non-clothing items from all drobes and puts them into lockers where they should be.

Removed bean bag boxes from BarDrobe. They are now in the booze locker
Removed appraisal tool from CargoDrobe. It's now in the cargo tech's locker
Added cargo technicians locker. It has some basic clothing for them and an appraisal tool. Sorry mappers, a new thing to add.
Removed detective's flask from the DetDrobe. It's now in the detective's locker.
Removed flashlight, light replacer, soap, trash bags, and holoprojector from the JaniDrobe. These items are now in the custodial closet.
Custodial closet now has 2 mops. Also mappers should make sure this closet is mapped in, I didn't see it in some of the map screenshots. It's not in Saltern for sure. Once again, sorry mappers :(
Removed welding mask from EngiDrobe. EngiVend has two more to compensate.

Should resolve  #11348
at least until people put more non-clothing items in drobes >:(
closes #11291
the extra mop was added to custodial closets
Screenshots

Changelog

:cl: ashtronaut

tweak: Due to a mix-up in the NanoTrasen Standardized Equipment Logistics Warehouse, non-clothing items were getting stocked in 'Drobe machines. We've corrected this issue and ensured said equipment should be available in the appropriate lockers instead.

sussy on having to add the cargotech lockers to maps but i think a lot of maps are already missing the custodial closets and what not anyway so

authors: mirrorcult theashtronaut


text:
Mice can no longer turn into zombies

About the PR

It makes it so mice cannot turn into zombies.
Why / Balance

Mice are incredibly small, constantly spawn on the station, and can go under doors. This makes them an unbelievably
frustrating zombie type that can bypass most obstacles, be incredibly hard to hit, and there is an infinite supply of them.
Also see #21507.
Technical details

I added the ZombieImmune component to the mouse prototype.
Media

[ ] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

:cl:
tweak: Mice can no longer turn into zombies.

I know its annoying, but rats are known to bee disease carriers through history so I think it would be kinda strange for them to be immune to being zombies.

Bees were prevented from becoming zombies because their sprite is so small that you can’t even see them coming up on you, let alone that they’re a zombie. Mice sprites are big enough to show the hue shift, and iirc they die in two crowbar wide swings, which balances out their mobility.

I know its annoying, but rats are known to bee disease carriers through history so I think it would be kinda strange for them to be immune to being zombies.

As much as I like realism arguments, I think this is outweighed by the gameplay issues mice zombies have.

Bees were prevented from becoming zombies because their sprite is so small that you can’t even see them coming up on you, let alone that they’re a zombie.
Mice are still incredibly small, and can be completely invisible under doors/tables/etc.

Mice sprites are big enough to show the hue shift.
It's true that you can see that they are zombies, although this doesn't help much if you can't see them at all due to the reasons stated above.

iirc they die in two crowbar wide swings, which balances out their mobility.
Bees have a similar amount of health iirc. The same argument could be made about bees, how their low health balances out how small they are which does not seem to have flown. Similarly I believe that their low health does not justify their mobility as a zombie.

I think its wack trying to chase balance by wacking zombie animals. I'd rather go all or nothing on it than constantly chasing what zombie animal is OP and should be removed.

I think its wack trying to chase balance by wacking zombie animals. I'd rather go all or nothing on it than constantly chasing what zombie animal is OP and should be removed.

What alternative do you propose? Zombies currently seem to be balanced around human zombies, not animal zombies.

Oh nvm, I misread that. I guess we could just make all animals not be zombies although some of them seem fine for example cows.

Oh nvm, I misread that. I guess we could just make all animals not be zombies although some of them seem fine for example cows.

Zombie virus just outright killing things under a certain biomass

start wide swinging 4head, there is NO DRAW BACKS IN WIDE SWINGING, STOP HUNTING THE SILLY PIXEL

i think a good fix would be to only let humanoid characters infect but to let all other mobs just be attack zombies, then we dont have to worry about this coming up again and zombies can still be a fun horde mode with all the mobs

start wide swinging 4head, there is NO DRAW BACKS IN WIDE SWINGING, STOP HUNTING THE SILLY PIXEL

No draw backs except you can't kill a mouse under a door or table with wide swinging. You have to hit it manually.
https://github.com/space-wizards/space-station-14/assets/32041239/d6e052f4-282d-4510-b9de-14896c051f07

Zombie virus just outright killing things under a certain biomass

That could also work, may be a little too arbitrary tho.

i think a good fix would be to only let humanoid characters infect but to let all other mobs just be attack zombies, then we dont have to worry about this coming up again and zombies can still be a fun horde mode with all the mobs

That might be a good compromise, I'm unsure what everyone else thinks about it but I'll work on that if it's acceptable.

i think a good fix would be to only let humanoid characters infect but to let all other mobs just be attack zombies, then we dont have to worry about this coming up again and zombies can still be a fun horde mode with all the mobs

+1, I think at the very least most animals should have a way lower chance to infect than humanoids, if not outright prevented from it

Imma just defer discussion to discord for a day or two I guess.

Well from the discord discussion I've gathered the following:

 There is broad support for something like this, although not necessarily just making mice immune
 Making mice unable to transmit the zombie virus is good solution
 Making mice just die from the virus seems to also be very popular
 Just lowering the infection chance for mice was also proposed
 All small animals/mobs like hamlet, ticks, etc. should get the same treatment

https://discord.com/channels/310555209753690112/1174662886791061534/1174662886791061534

I quickly implemented a compromise since it seems the discord people would rather see mice and other small creatures just die from the infection (at least from the people that actually spoke in the thread) and here where the general opinion is that no change is necessary. It now also no longer affects mice as mentioned, but any really small creature I could think of. If I forgot something let me now. I can still change it to another solution, reduce the scope just to just mice, etc. However I believe that SOME change is necessary.

Seems it looks like a video was requested, I'll get it soon.

Why doesn't this use the existing ZombieImmuneComponent?

It was actually used in the first iteration of this pr which people here didn't like. ZombieImmune makes it so the mob can't become a zombie. This new component makes it so the mob can't infect others.

Why doesn't this use the existing ZombieImmuneComponent?

It was actually used in the first iteration of this pr which people here didn't like. ZombieImmune makes it so the mob can't become a zombie. This new component makes it so the mob can't infect others.

I see. Would you mind updating the comments in both components to explain this important difference?

Why doesn't this use the existing ZombieImmuneComponent?

It was actually used in the first iteration of this pr which people here didn't like. ZombieImmune makes it so the mob can't become a zombie. This new component makes it so the mob can't infect others.

I see. Would you mind updating the comments in both components to explain this important difference?
Seems good now?

Thank you for your contribution. Your changelog was not formatted correctly, so I've fixed that for you along with a minor revision.


text:
Fix crematorium

Fix creating ash out of thin air and being able to cremate while open.

Ah! Nice catch! Thanks.


text:
Senior physician sleeve symmetry

About the PR

Made the senior physician uniforms have symmetrical sleeves.
Why / Balance

Symmetry = cool
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

also git acts weird and shows unrelated commits, i'm fairly sure they're not doing anything though so it should be fine?

yeah honestly i'm considering deleting my local repository, maybe it'll make those unrelated commits stop appearing

Oh, I like the asymmetry of the senior stuff, it makes it more unique

I was about to say the same thing! I think the asymmetry looks better than symmetric

I am a huge fan of the asymmetry, ngl

personally its kind of weird how one sleeve is blue but the other one is white.
though i guess i can just make the sleeves blue and not do anything with the arm bands and see if that looks any better?

make it two armbands, one orange one blue each on their respective side. Thats how the labcoat is right? The senior physician labcoat iirc looks like that and it should probably match it

I'm a big fan of the new design!

Alright i'll make the sleeves blue and just leave the armbands as is!

honestly the orange should be removed since the SP's don't get Chemistry access

honestly the orange should be removed since the SP's don't get Chemistry access

Think of it like a mastery of the job, its showing you have the experience in med to run chem if needed based of your experience in the field

honestly the orange should be removed since the SP's don't get Chemistry access

Think of it like a mastery of the job, its showing you have the experience in med to run chem if needed based of your experience in the field

yeah but like, they don't have access... Why would they have chemistry orange if they don't have chem access

Because you do not need access to teach, or so was the reasoning for removal of senior roles.

yeah but like, they don't have access... Why would they have chemistry orange if they don't have chem access

Because they have the knowledge of chemistry. A chemist may see someone in the senior clothing (with the chem orange) and ask them how to do something. I'd imagine Green will be added to the other sleeve if virology every becomes a thing again, so that virologists know they may ask a SP questions as well.

I'd imagine Green will be added to the other sleeve if virology every becomes a thing again, so that virologists know they may ask a SP questions as well.

I unironically want to be a senior virologist


text:
Fix warden being and qm being not considered head for tot kill head objective

About the PR

Changed KillPersonConditionSystem. Previously it checked for player's job beind important to decide whether they are head or not, now it directly checks if they are Command Staff, fixing Warden being considered head and QM being not in the context of assigning a traitor to kill them.
QM is also now considered an importand job regardless, to be consistent with the other heads.
Also changed NotCommandRequirementSystem that is used to not give the disk objective to hypothetical traitor heads in the same way - hypothetical traitor Warden can now get the objective. Slarticodefast asked me to do so.
Why / Balance

This is basically a bugfix. QM is 100% a head, Warden is 90% not a head.
Also all heads are important (especially when we have Warden that is not a head but is important).
Technical details

KillPersonConditionSystem now checks for CommandStaffComponent of the entity rather than for RequireAdminNotify in its job prototype.
NotCommandRequirementSystem does the same too.
Media
https://youtu.be/N7xr0L9h9DU

Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.
I filled the changelog, and I don't think traitor warden correctly getting disk objective is not a player facing change

Changelog

:cl: pheenty

tweak: QM is now considered an important job.
fix: QM is now correctly considered head for traitor's kill head objective, while warden now isn't.

You should probably do the same in NotCommandRequirementSystem which currently does the same weird thing using RequireAdminNotify.

You should probably do the same in NotCommandRequirementSystem which currently does the same weird thing using RequireAdminNotify.

I've seen it in my IDE, but I have no idea on what does this system do and how I should test whether it works or not after the change

Also fixed NotCommandRequirementSystem, hypothetical Warden traitor can get steal disk objective now.

Also looks good to me. @slarticodefast, is this going to stable as a hotfix?

It's only an objective assignment, I think this one is not that critical. But I'll probably do a bunch of hotfixes today anyways, so I can include this one.

authors: chromiumboy pheenty slarticodefast


text:
Automatically merge changelog files

About the PR
Allow downstreams to have their own changelog yml file.
It will automatically load all yml files in /Changelog/, merge, sort by time add return as one changelog.
Screenshots

Changelog

How does this handle merging IDs between the files?

How does this handle merging IDs between the files?

Don't see a good solution here. Only these:

Use Changelog.yml as a base file and add new entries from other files using its last entry ID.
Try to use only  in code total length of array with all entries from all files.

Do we even need to merge the IDs? They're not used for display and I imagine any downstreams could just point their action at their own file.

There seems to be no more interest on discussing this further anytime soon


text:
Will the latest version be released on NPM?

NPM package version is not up to date (still at 0.9.51). Is there a plan to release the 0.9.6 version on NPM?

I too am wondering this. Including the script directly in my HTML isn't ideal.

@m4n3z40 @alexgurr I've just published 0.9.6 to NPM. Let me know if you run in to any issues.

@jenssogaard I still get the 0.9.51 version. My guess is that this still happens since 51 is greater than 6.

@pierlon you are right. That is absolutely not ideal. You'll have to hold out for a new release with proper version number before that is fixed. I'm sorry :unamused:

authors: alexgurr jenssogaard m4n3z40 pierlon


text:
[SI-3931] Server implementations using csp_send() have no way of detecting a broken-pipe (connection timeout)

The RDP implementation did not take connection timeouts into account, when the connection is in the OPEN state. This could result in servers sending data onto a RDP connection would not be able to detect if the client was lost.
This PR includes an attempt at fixing that issue by implementing a new API in csp.h called csp_conn_is_active() which returns the state of a particular connection object. The connection time out is monitored in the RDP layer by time stamping the connection on the reception of each packet in OPEN state.
The SFP implemention in the CSP library has been made to use this new API to be able to bail the TX loop if the connection is no longer active.

We can use csp_packet_s::timestamp_rx for storing the received timestamp

authors: Lykkeberg troelsjessen

repo: spaceinventor/libcsp


text:
Exit tortoise beacon cleanly by using taskgroup.Group

Motivation
Tortoise beacon creates multiple goroutines during its lifetime, not all of them are guaranteed to exit when Close is called. I need it for my logging refactoring, and it should be default behavior anyway.
closes: https://github.com/spacemeshos/go-spacemesh/issues/2621
depends on change in: https://github.com/spacemeshos/go-spacemesh/pull/2605
Changes
I added new module called taskgroup, it behaves identically to errgroup, with a difference that it is safe to call Go concurrently with Wait. If the group didn't terminate Wait will ensure that concurrent Go call completes. If it did Go call will exit immediately with Terminated error (this error should be ignored unless callers counts number of goroutine for some reason).
Test Plan
unit tests
TODO

[ ] Explain motivation or link existing issue(s)
[ ] Test changes and document test plan
[ ] Update documentation as needed

DevOps Notes

[x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources)
[x] This PR does not affect public APIs
[x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.)
[x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)

The only relevant commit is the last https://github.com/spacemeshos/go-spacemesh/pull/2625/commits/00be5a28a84614fcb594eac35c20d76e9b2ce542. Will update the change after linked PR is merged.
@noamnelke @countvonzero we had a conversation about it in another PR, do you have anything against using new module to handle task of managing goroutines?

bors test

bors try

bors try

bors try

bors merge

repo: spacemeshos/go-spacemesh


text:
checkpoint: generate checkpoint data

Motivation
part of #4090
Changes

add db fields for data that needs to survive across checkpoint so that at the point of restore, these data will be queried on its own without parsing the atx blob

checkpoint runner that saves the following data in a json file

the account state at snapshot layer
the last two atx for each miner

add checkpoint rpc that return the checkpoint data

bors try

bors merge


text:
implement pruner for activesets

closes: https://github.com/spacemeshos/go-spacemesh/issues/5114
pruning activesets will significantly reduce space (as of now ~1.5GB / 2.9GB).

bors merge

bors merge

bors cancel

bors merge

bors merge

bors merge

bors merge


text:
Links in notebooks are broken

The link to the drizzlepac handbook is broken in the aligning multiple visits notebooks, so I'd imagine this occurs in other notebooks as well.

I found another on in the WFPC2 notebook, step 2.

List of notebooks to check over for broken links:

[ ] Initialization
[ ] align_mosaics
[ ] align_multiple_visits
[ ] align_sparse_fields
[ ] align_to_catalogs
[ ] drizzle_wfpc2
[ ] mask_satellite
[ ] optimize_image_sampling
[ ] sky_matching
[ ] use_ds9_regions_in_tweakreg
[ ] using_updated_astrometry_solutions...

See PR #127 for current progress

authors: catherine-martlin rjavila shannnnnyyy

repo: spacetelescope/notebooks


text:
nokogiri vulnerable to XXE attack when used under c ruby

Using external xml entities you can specify URLs (e.g.  HTTP) to be contacted when attacker-supplied XML is parsed. This can be used to trigger URLs on the internal network of a XML parsing service and potentially leak their responses.
External xml entities should be completely (file, http, etc.) disabled.
$ cat test.rb
require 'nokogiri'
d=Nokogiri::XML.parse("<!DOCTYPE doc [ <!ENTITY ent SYSTEM \"file:///tmp/marker\"><!ENTITY ent2 SYSTEM \"http://www.google.com/marker\"> ]>\n<root>\n<element>&ent;</element>\n<element>&ent2;</element>\n</root>")
d.each do |node| puts node.content end
$ strace -e connect ruby test.rb
# many connects, to www.google.com
$ ruby --version
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]
$ apt-cache show libnokogiri-ruby1.8 | grep Version
Version: 1.4.0-3
$ apt-cache show libxml2 | grep Version
Version: 2.7.6.dfsg-1ubuntu1.5
Version: 2.7.6.dfsg-1ubuntu1
$ apt-cache show libxml-ruby | grep Version
Version: 1.1.3-2

No problem - just to close the loop, MITRE has assigned CVE-2012-6685 to this issue.

authors: dfj felixgr

repo: sparklemotion/nokogiri


text:
RTD build failing, LaTeX out of memory

https://github.com/noaa-oar-arl/monet/issues/126
https://github.com/readthedocs/readthedocs.org/pull/9967

Build output directory for format "pdf" contains multiple files and it is not currently supported. Please, remove all the files but the "pdf" you want to upload.
...
! TeX capacity exceeded, sorry [main memory size=5000000].
\par ...@m @noitemerr {@@par }\fi \else {@@par
}\fi
l.9255 ...p: Running optimization trial 21{\ldots}
!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on self-driving-lab-demo.log.
Latexmk: Index file 'self-driving-lab-demo.idx' was written
Failure to make 'self-driving-lab-demo.pdf'
Latexmk: Errors, in force_mode: so I tried finishing targets
Collected error summary (may duplicate other messages):
pdflatex: Command for 'pdflatex' gave return code 256

readthedocs.org_api_v2_build_21041788.txt

Got a new error:

We encountered a problem with a command while building your project. To resolve this error, double check your project configuration and installed dependencies are correct and have not changed recently.

loading configurations for self-driving-lab-demo 0.8.2.post1.dev49+g8ac3de3 ...

/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/nbsphinx/init.py:1058: RuntimeWarning: You are using an unsupported version of pandoc (1.19.2.4).
Your version must be at least (2.14.2) but less than (4.0.0).
Refer to https://pandoc.org/installing.html.
Continuing with doubts...
nbconvert.utils.pandoc.check_pandoc_version()
/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/checkouts/latest/docs/notebooks/4.2-paho-mqtt-colab-sdl-demo-test.nblink:846: ERROR: Duplicate substitution definition name: "image0".
/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/checkouts/latest/docs/notebooks/4.2-paho-mqtt-colab-sdl-demo-test.nblink:895: ERROR: Duplicate substitution definition name: "image0".
/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/checkouts/latest/docs/notebooks/4.2-paho-mqtt-colab-sdl-demo-test.nblink:930: ERROR: Duplicate substitution definition name: "image0".
/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/checkouts/latest/docs/notebooks/4.2-paho-mqtt-colab-sdl-demo-test.nblink:965: ERROR: Duplicate substitution definition name: "image0".
/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/checkouts/latest/docs/notebooks/4.2-paho-mqtt-colab-sdl-demo-test.nblink:1039: ERROR: Duplicate substitution definition name: "image0".
looking for now-outdated files... none found
pickling environment... done
checking consistency... /home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/checkouts/latest/docs/notebooks/test.nblink: WARNING: document isn't included in any toctree
done
processing user_guide.tex... index readme tutorials notebooks/4.2-paho-mqtt-colab-sdl-demo-test notebooks/escience/1.0-traditional-doe-vs-bayesian notebooks/6.1-multi-objective notebooks/6.2.1-multi-fidelity-continuous notebooks/6.2.2-multi-fidelity-discrete notebooks/escience/2.7.1-multi_task notebooks/6.3-batch-optimization notebooks/escience/2.8.2-ax_service_existing_data_saasbo_multi_objective notebooks/escience/2.11-predefined-candidates notebooks/7.3-benchmark-dataset-generation contributing license authors changelog api/modules api/self_driving_lab_demo api/self_driving_lab_demo.data api/self_driving_lab_demo.demos api/self_driving_lab_demo.utils
resolving references...
failed
Traceback (most recent call last):
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/cmd/build.py", line 285, in build_main
app.build(args.force_all, args.filenames)
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/application.py", line 353, in build
self.builder.build_update()
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/builders/init.py", line 308, in build_update
self.build(['all'], to_build)
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/builders/init.py", line 378, in build
self.write(docnames, list(updated_docnames), method)
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/builders/latex/init.py", line 287, in write
doctree = self.assemble_doctree(
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/builders/latex/init.py", line 353, in assemble_doctree
self.env.resolve_references(largetree, indexfile, self)
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/environment/init.py", line 656, in resolve_references
self.apply_post_transforms(doctree, fromdocname)
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/environment/init.py", line 668, in apply_post_transforms
transformer.apply_transforms()
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/transforms/init.py", line 79, in apply_transforms
super().apply_transforms()
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/docutils/transforms/init.py", line 171, in apply_transforms
transform.apply(**kwargs)
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/transforms/post_transforms/init.py", line 37, in apply
self.run(**kwargs)
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/builders/latex/transforms.py", line 364, in run
self.document.walkabout(visitor)
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/docutils/nodes.py", line 199, in walkabout
if child.walkabout(visitor):
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/docutils/nodes.py", line 199, in walkabout
if child.walkabout(visitor):
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/docutils/nodes.py", line 199, in walkabout
if child.walkabout(visitor):
[Previous line repeated 5 more times]
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/docutils/nodes.py", line 212, in walkabout
visitor.dispatch_departure(self)
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/docutils/nodes.py", line 2046, in dispatch_departure
return method(node)
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/builders/latex/transforms.py", line 434, in depart_table
tbody = next(node.findall(nodes.tbody))
StopIteration
Exception occurred:
File "/home/docs/checkouts/readthedocs.org/user_builds/self-driving-lab-demo/envs/latest/lib/python3.8/site-packages/sphinx/builders/latex/transforms.py", line 434, in depart_table
tbody = next(node.findall(nodes.tbody))
StopIteration
The full traceback has been saved in /tmp/sphinx-err-frecixsf.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at https://github.com/sphinx-doc/sphinx/issues. Thanks!

Related:

https://github.com/readthedocs/readthedocs.org/issues/7503
https://github.com/readthedocs/readthedocs.org/issues?q=is%3Aissue+sort%3Aupdated-desc+resolving+references+failed+is%3Aclosed
https://github.com/readthedocs/readthedocs.org/issues/10132
https://github.com/sphinx-doc/sphinx/issues/11273

Fixed by updating to latest readthedocs configuration file format

repo: sparks-baird/self-driving-lab-demo


text:
SNR may have broken with a recent update

Just got 3155b85a-29b0-4de0-8c5e-c23c321bf245.uterm.release and I've not looked into it much, but at least my SNR graph looks broken while the rest of the stuff seems to be working.

Yeah, sadly SNR was removed in that firmware update. A bunch of other fields, too.
I was going to drop a note in the README, but I didn't want something that was essentially a temporary notice cluttering that up (further...). Maybe I should have kept the issue tracking this (#32) open so people could see it had already come to my attention.

license: Unlicense


text:
Add Licensing referred to in readme.md

Noticed that licensing docs in readme led to nowhere, just raising a quick request to add the files in. Copied licenses from rust-lang/rust

Thanks addressing this in #31.

authors: pvichivanives spastorino

repo: spastorino/dynosaur


text:
Handle encoding in GeoFile Reader and Writer

UTF-8 format can not be identified  in the contemporary version

Postpone to the 1.4 release when we also update to Geopandas 1.0 which uses pyogrio instead of Fiona for file handling

authors: UrbanGISer koettert


text:
US2020 Tiger Map node produces corrupt output table for specific queries

Depending on the query the output table can’t be viewed (it gets stuck at “Loading port content…”. In addition, when wanting to reset the node, the following error is shown: Error when attempting to close open closeable.WARN  ResetAction Reset not allowed
Node config:

State FIPS: 01
County FIPS: 01 (same as State FIPS because I want all counties of state 01)
TIGER/line data type: county20

The node execute successfully but I can’t use it for further processing (tried Joiner node and Geospatial View node)
See example workflow here: https://hub.knime.com/tobias.koetter/spaces/Geospatial/latest/bugs/Faulty exection Tiger Map node~p65jSa5GEUA_THX_

In the updated Tiger nodes with revised FIPS dictionary, it is fine now


text:
Bugfix: Synchronous schema generation for the Commandlet to be able to save the SchemaDatabase uasset

Description
Running the schema generation into a background thread require the saving of the SchemaDatabase to be delayed into another async task to be run in the game tread afterward.
The issue is that the Snapshot is then generated before the SchemaDatabase is saved, which crash if there is not already an up to date SchemaDatabase
Release note
Bugfix: Synchronous schema generation for the Commandlet to be able to save the SchemaDatabase uasset
Tests
On a clean checkout of a project, run the GenerateSchemaAndSnapshots commandlet an see that it crashs while trying to generate the snapshot: after the crash, there is no Content/Spatial/ since the SchemaDatabase.uasset has not been generated.

This is apparently not needed anymore in current master of the GDK!
I'll update our GDK and report here if this change can safely be dropped.

Oh nice! I was just about to merge this in but if it's not needed that works as well.

Hi,
I am closing this since it is unneeded now in the current state of the GDK.
Cheers!

This is apparently not needed anymore in current master of the GDK!
I'll update our GDK and report here if this change can safely be dropped.

What changed that caused this to no longer be needed? A cursory check leads me to believe that this is still solving a valid problem.

We don't reproduce the problem anymore, while it was totally reliably crashing, so I assumed there was somehow no need for this anymore (I thus have also no way of checking this anymore).

We don't reproduce the problem anymore, while it was totally reliably crashing, so I assumed there was somehow no need for this anymore (I thus have also no way of checking this anymore).

Which version of the UnrealGDK are you using? We're on 0.2.0, and we're still seeing the issue without this fix. If we start by removing our existing SchemaDatabase.uasset, we are getting this error summary:
[2019.03.06-21.27.22:122][  0]LogInit: Display: Warning/Error Summary (Unique only)
[2019.03.06-21.27.22:123][  0]LogInit: Display: -----------------------------------
[2019.03.06-21.27.22:123][  0]LogInit: Display: LogLinker: Warning: Can't find file '/Game/Spatial/SchemaDatabase'
[2019.03.06-21.27.22:123][  0]LogInit: Display: LogUObjectGlobals: Warning: Failed to load '/Game/Spatial/SchemaDatabase': Can't find file '/Game/Spatial/SchemaDatabase'
[2019.03.06-21.27.22:124][  0]LogInit: Display: LogUObjectGlobals: Warning: Failed to find object 'Object /Game/Spatial/SchemaDatabase.SchemaDatabase'
[2019.03.06-21.27.22:125][  0]LogInit: Display:
[2019.03.06-21.27.22:126][  0]LogInit: Display: Success - 0 error(s), 5 warning(s)
This is paired with a variety of other undesirable functionality, such as double-copying the schemadatabase file after the commandlet has finished, etc.. I'm feeling quite convinced that this PR is still necessary. Do you not also see this happening?

Closing this PR as Schema Generation is now synchronous.

authors: DW-Sebastien Vatyx jed-improbable mattyoung-improbable

repo: spatialos/UnrealGDK


text:
Add generic collection support

The following syntax must be supported:
class MyObject
{
    /** @var \Spatie\ValueObject\T[] */
    public $arrayOfT;
}

When setting this property, we must validate two things:

The value is an array.
This array only contains values of type T.

The implementation will be in Property::assertTypeEquals. I expect a new check to be added which detects the array syntax [] and will recursively validate every element in it. assertTypeEquals should be reused.
null values should not be supported.

Another thing coming to mind: the more we can parse at construction time, the better. So feel free to add functionality in Property::resolveTypeDefinition.

repo: spatie/value-object


text:
Git Download Location regex matcher doesn't meet spec

Spec: https://spdx.github.io/spdx-spec/3-package-information/#37-package-download-location
Code: https://github.com/spdx/Spdx-Java-Library/blob/c909ebcdbcca06e89a2e406362b261d5b7f1e729/src/main/java/org/spdx/library/SpdxConstants.java#L362
Here is a link to a bunch of test cases that should work according to the spec, but do not: https://regex101.com/r/mb4tWm/1
For reference in case that link dies, here's a summary of ones that do and do not work:
git://git.myproject.org/MyProject.git@master ✅
git://git.myproject.org/MyOrg/MyProject.git@master ✅
git+git@git.myproject.org:MyProject ✅
git+git@git.myproject.org:MyOrg/MyProject ❌
git+git@git.myproject.org:MyProject.git ❌
git+git@git.myproject.org:MyOrg/MyProject.git ❌
git+git@git.myproject.org:MyProject@main ❌
git+git@git.myproject.org:MyProject@6338c7a2525e055a05bae1580e4dd189c2feff7b ❌

@ianling Thanks for reporting the issue.  I'm in the process of creating a new release and should be able to get a fix for this within the next few days.

Resolved with PR #54

authors: goneall ianling

repo: spdx/Spdx-Java-Library


text:
Fix re-ordering of elements in tree editor

@goneall  The reordering of the tags has been fixed

Please test and provide suggestions :slightly_smiling_face:

Test a few scenerios and it works good.  I'll go ahead and merge.

One more thing is that when we switch from tree to text editor the pretty printing of the text gets lost, will that be a problem ? I am trying to fix that too, its on my todo list.

Loosing the pretty printing isn't critical - it would be nice to fix, but I think we could make the application available for use by the legal team this as a known problem.

authors: goneall techytushar

repo: spdx/spdx-online-tools