出现“ValueError: The number of weights does not match the population”问题

训练代码的时候出现“ValueError: The number of weights does not match the population”，更换numpy的版本也不行，请问您有遇到过这个问题吗？

Could you please provide a more specific error report (such as a screenshot) to show where you encounter this problem? The training code can run smoothly with two different conda environment (NumPy v1.21.3 and v1.23.1) I just tried.

Thanks for letting me know. Could you please provide a more specific error report (such as a screenshot) to show where you encounter this problem? The training code can run smoothly with two different conda environments (NumPy v1.21.3 and v1.23.1) I just tried.

我的numpy换成1.21.3还是会出现这个问题，我的python是3.7版本。

这应该不是版本的问题，看上去是因为你的训练数据集准备方式不太一致哈～
On Fri, Apr 14, 2023 at 1:03 PM marico2020 @.***> wrote:

Thanks for letting me know. Could you please provide a more specific error
report (such as a screenshot) to show where you encounter this problem? The
training code can run smoothly with two different conda environments (NumPy
v1.21.3 and v1.23.1) I just tried.
[image: image]
https://user-images.githubusercontent.com/68038484/231943553-7bd41f8f-8f34-4ec3-9ea0-7075492adcdd.png
我的numpy换成1.21.3还是会出现这个问题，我的python是3.7版本。
—
Reply to this email directly, view it on GitHub
https://github.com/Little-Podi/GRM/issues/1#issuecomment-1507927704, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AXDCZ4BHE64VCYJOEKCITTDXBDLDRANCNFSM6AAAAAAW5PAREI
.
You are receiving this because you commented.Message ID:
@.***>

我把numpy换成1.21.3还是不行，python是3.7的版本。

我明白了，之前只测试一个got10k数据集， 忘把DATASETS_RATIO其他数据给注释了， 现在可以跑通了，非常感谢您的帮助！

I think it is not caused by a wrong version of package. It seems to be a dataset preparation issue.

Great to hear that! You are welcome.


[BEAM-12829] Fix Release Gradle Build

Don't copy .gogradle files for python builds.
Don't run gofmt through gradle.

This is a stop gap to unblock the 2.33.0 release. A later PR will be removing use of GoGradle from the repo handled in https://issues.apache.org/jira/browse/BEAM-12830

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Run Java_Examples_Dataflow PreCommit

Run Java_Examples_Dataflow PreCommit

The Release_Build failure is in a single Python test (test_custom_merging_window), which looks unrelated to this change.


Multiselect dropdown 2.0, options disappear after removing items

Steps to reproduce:

Select Items
Remove Items
Add different Item (only removed items will be listed)

Fiddle: http://jsfiddle.net/3mbrke0x/1/
Browser: Current Chrome + Firefox

This is a pretty bad regression. I'll take a look

Should fix.. will give fiddle in a sec

Actually you can check your same jsfiddle
http://jsfiddle.net/3mbrke0x/1/

Thanks for the quick fix. Nice work :+1:


Cannot rebuild a lucene index in 3.2.0

OrientDB Version: 3.2.0
Java Version: 1.8
OS: centos/ubuntu/windows
Expected behavior
Lucene Indexes can be rebuilt normally
Actual behavior
Error triggers when trying to redbuild an index
Steps to reproduce
1-Create a new Class
2-Add some properties
3-Create a lucene index on one of the properties
4-Try de rebuild the created index
The attached capture shows the error's informations

The above scenario runs without problem in 3.0.27
Thanks for any help or explanation

@laa can you confirm that is a regression comparing to 3.0.x version ?
Thanks

@aberdev yes , sure that is regression which we will fix.

This is related to #9498 (see comment https://github.com/orientechnologies/orientdb/issues/9498#issuecomment-898586327). The problem is that the database gets unusable until the server is restarted, no new connections are possible. Every exception thrown by Lucene turns the database into that broken state.

Yes ,the issue is caused by the same behavior.
Is that mean we can't rebuilt lucene indexes  ? But, we can only drop&create them ?

It looks like the fixes applied in 72e7d639a5f96be237dc49c43c815ef7c9255400 to stop the DB going into an internal error status on read errors would fix this in 3.2.x/develop as well.
The root cause is actually that a rebuild index on a Lucene index has always (at least in 3.1/3.2) thrown an UnsupportedOperationException when it is rebuilt.
The delete/doDelete method in OIndexAbstract isn't designed for extension, so when an index is rebuilt it executes the private OIndexAbstract.doDelete, which attempts to iterate all index items and remove them before removing the index engine.
If OLuceneIndexNotUnique provided an override of doDelete that does what it's delete does now (which is simply to remove the engine from the storage), it would probably eliminate the actual error.

Hi,
Rolling 3.2.7 with the relative fix, closing this.


commit "added rate0 right, merged rate0 and rate1 into combines" introduced a bug that affects shorter codes

While preparing for a SSLC playground I found out that reverting commit ae495026af5ec6ae20eb1711fbde402c9b164e96 significantly improved BER for short codes.
I am recreating the BER plots now and will keep the commit reverted for now.
Anyone care to investigate why the commit is problematic?
For SSLC it is unnecessary but It might be still useful for long codes under SSC decoding.

Yes, that bug is real:

I've re-added correct versions of the rate0 and rate1 combines.


Parallelized transform propagation

Objective
Currently we traverse every tree in the entity hierarchy top-to-bottom every frame to update transforms. We iterate separate trees in parallel, but in practice (and especially when loading complex gltf scenes) the world tends to consist of a few very deep trees, and several users and reported performance problems (see for example https://github.com/bevyengine/bevy/pull/9442).
Fixes https://github.com/bevyengine/bevy/issues/7840 (partially).
Solution
This is the first of two PRs I am publishing to address this problem. In this PR, I deal with trying to start updating transforms as deeply into the tree as possible, while also running as much of the traversal in parallel as possible.
propagate_transforms now preforms two passes of parallel iteration. The first pass updates all root and orphaned nodes (just as before) but now we skip any trees without top-level changes instead of immediately doing a depth-first traversal. The second pass then walks up the tree from every changed non-root node to find minimal disjoint sub-trees containing changed transforms, and then propagates transforms down each sub-tree in parallel.
These optimizations should significantly improve the case when most transform changes occur near the leaves of the entity hierarchy. The best case performance (all changes are leaves) should be much better than current. The worse case (when all changes are in roots) should be approximately just as fast as the current implementation.
This is just a proposal. Please evaluate it for efficiency and safety. While this algorithm seems intuitively correct to me, and I have done my best to justify the new unsafe block, am not super happy with the logic in the second safety comment.

the stress test example transform_hierarchy should have plenty of cases to test the perf changes

the stress test example transform_hierarchy should have plenty of cases to test the perf changes

On the off chance that someone tries this for themselves, these are broken. You have to switch out MinimalPlugins for DefaultPlugins, or they won't profile properly. See tracking issue here: https://github.com/bevyengine/bevy/issues/7433.

Interesting, would be curious to see performance results.
Ultimately, if we go down this route I think we want something like Servo had, where every node enqueues its descendants and work-stealing distributes the load across all the threads. This would also allow us to encapsulate the "parallel tree traversals" logic into a single code, eliminating the unsafe code in the systems themselves. However, I'm not sure how much work stealing infrastructure that Bevy has, and just throwing Rayon into there would result in a lot of thread bloat.

I profiled all of the transform_hierarchy benchmarks. All of these were run for 25 seconds on a 11th gen i7-1165G7 (2.80GHz) cpu running Linux. Red is main, yellow is this PR.
Keep in mind that propagation happens at both at startup and every frame. The startup tends to take longer, so the distribution is usually bimodal.
Large Tree
A fairly wide and deep tree, with a depth of 18 and 8 children per node. Entities transform with a probability of 0.5 each frame.

Wide Tree
A shallow but very wide tree, with a depth of 3 and 500 children per node. Entities transform with a probability of 0.5 each frame.

Deep Tree
A deep but not very wide tree, with a depth of 25 and 2 children per node. Entities transform with a probability of 0.5 each frame.

Chain
A chain 2500 levels deep. Entities transform with a probability of 0.5 each frame.

Interesting performance regression here, but I don't think this is something we should be optimizing for.
Update Leaves
A fairly wide and deep tree, with a depth of 18 and 8 children per node. Leaf nodes transform with a probability of 0.5 each frame.

This is a much more serious regression. I believe it is from the added cost of walking up the tree from every root node. It may be possible to optimize this case further, but introducing a Static marker will also help in practice.
Update Shallow
A fairly wide and deep tree, with a depth of 18 and 8 children per node. Entities in the bottom half transform with a probability of 0.5 each frame.

Humanoids Active
4000 human-rig hierarchies. Every single entity moves every single frame.

Another regression. The added overhead of finding disjoint sub-trees is useless when every entity moves every frame.
Humanoids Inactive
4000 human-rig hierarchies. All but 10 are static.

An easy performance win coming from just ignoring all the trees that don't move.
Humanoids Inactive
4000 human-rig hierarchies. Half are static, half move every frame.

Very slight regression.
Analysis
This technique performs very well when few entities are moving, and about equally poorly when more than half of the entities mover every frame. It may be possible to combine this with other techniques, such as a Static marker, or to get more consistent performance benefits.
TL;DR It's a mixed bag, depends on what we want to optimize for.

One potential alternative if #11995 gets merged  is a (unsafe) alternative to the current par_iter that supports splitting tasks to support work stealing sub-hierarchies. par_iter trivially should be able to take advantage of it by subdividing archetype/table slices, but a hierarchy traversal may be difficult, but possible to do safely.

I think this sort of optimization is worth looking at, but to really see performance improvements across the board it will need to be coupled with a "two-pass" propagation algorithm, similar to what is done in bigspace.


a few Cypress enhancements

Asana ticket Assorted fixes for aiding consistent snapshot recording
Not much to see here but if you unskip the new tests you can see the screenshots it generates! I didn't want to commit screenshots to this repo quite yet, so that's why the tests that create the screenshots are skipped here.
Also threw in the ability to specify a port to run tests on on the fly, and added a baseUrl configuration so that tests don't have to specify the base URL every time.

Ooooo coool!  So neat to see those screenshots!  I think it looks great.  Once curiosity, though:  how will these screenshots handle the fact that dotcom content changes all the time?  One of the screenshots has news headlines, which will change

Once curiosity, though: how will these screenshots handle the fact that dotcom content changes all the time? One of the screenshots has news headlines, which will change

I'm about to stage a WIP branch that will introduce a test server that will serve up a version of Dotcom that mocks/stubs some parts of the site! For the CMS content, we have some static data of old news stories that we can load. Stay tuned....


Collection timed out warnings in Event Viewer

I'am getting alot of warnings in Event Viewer from the wmi_exporter after upgrading to 0.8.1 (from 0.7.0, upgraded by removing it via Control Panel and installing the newer version)
Warning: Collection timed out, still waiting for [net os service system]
Image:

Does anyone else has the same problems?/Is there a fix for this issue?

Hi @EHammer98,
Part of the 0.8 release was functionality to try to avoid missing the entire scrape if some collectors take unexpectedly long time, and this is what you are seeing the results of. Prometheus passes us how long it will wait for results before giving up, and we now try to return whatever data we managed to gather when that time is almost up. What is your scrapeTimeout configuration in Prometheus?
Also, previous to the update, did you see many "gaps" in the data in Prometheus? Is the server under heavy load?

@carlpett the scarpe timeout is the default 10s, scrape interval is changed to 5s.
The warnings are on all our servers.
I did have some "gaps" with <0.7.0 on a few servers which are mostly under heavy load.
On the worst, it was 1,5min. (1:30)

Thanks! If you are scraping that frequently, you're probably scraping more often than WMI is able to keep up with. Are you seeing fewer gaps with 0.8?

@carlpett ah ok i see, i will try to slow it down a bit tomorrow (i am now not at the office).
I will also let you know of the gaps are different ( i don't know that at this moment)

@carlpett i slowed the scrape interval to 15s, time-out is still the default 10s.
The warnings on my Prometheus servers (where i also have WMI exporter running) are gone now, but my co-worker told me that it is till happening on the other servers (we did restart the WMI-exporter service), it did slow down a bit (about every 15s while it first was every 5s, it was about every 15min. on my Prometheus server).
I have increased it to 30s (scrape interval). I will let you know if it is gone now as soon as my co-worker reports back to me

I found out that now only 1 server is having these warnings. That's because the CPU is at 100% at a rate of about 15s.
So increasing to 15s was enough to stop it from the other servers, i will leave it now at 30s (from the last test), and figure something out to block the warnings from the WMI-exporter in Event Viewer.
But thanks for the help @carlpett !


Revert "fix (statsd) fix hostname_in_prefix flag bug and request_size refs: #FT-3518

…/response_size statsd type bug (#9402)"
This reverts commit 9381b0a54bd40676cd2fbcd2c227224907c55087.
We need to do this in a non-backwards breaking way

hold for discussion

@fffonion Please avoid out-of-band discussions. What is the discussion that needs to happen to merge or close this PR?

@catbro666 is working on a proper fix, closing this now.


Constant ObjectSchema

If every property in an ObjectSchema is constant, I think it should have a ConstantSchema. See ConstantProduct in Validation: https://github.com/Azure/autorest.testserver/blob/e0d8dcad0f06f45ad6ec4416e45b326a139a63ff/swagger/validation.json#L239

Hmm interesting idea -- that is quite the interpretation.
I'm gonna have to think about this for a bit -- it's gonna have quite a few rules around it, but it maybe doable.

@fearthecowboy isn't it as simple as "if all properties in an object is constant, the object itself is constant, and then any property of this type is a constant property" ? Recurseveliy?


Performance improvements to executing cells without Ipywidget

For #11576
Basically defer waiting on messages to be processed by UI kernel until we know it is required, i.e. until we have widgets being created on the UI side.

Codecov Report

Merging #11578 into master will increase coverage by 0.05%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master   #11578      +/-   ##
==========================================
+ Coverage   60.59%   60.64%   +0.05%
==========================================
  Files         618      619       +1
  Lines       33644    33708      +64
  Branches     4733     4741       +8
==========================================
+ Hits        20386    20443      +57
+ Misses      12279    12278       -1
- Partials      979      987       +8

Impacted Files
Coverage Δ

src/client/datascience/ipywidgets/constants.ts
0.00% <0.00%> (ø)

src/datascience-ui/react-common/arePathsSame.ts
75.00% <0.00%> (-12.50%)
:arrow_down:

src/client/common/utils/platform.ts
64.70% <0.00%> (-11.77%)
:arrow_down:

src/client/linters/pydocstyle.ts
86.66% <0.00%> (-2.23%)
:arrow_down:

src/client/datascience/debugLocationTracker.ts
76.56% <0.00%> (-1.57%)
:arrow_down:

src/client/common/process/proc.ts
14.49% <0.00%> (-0.73%)
:arrow_down:

...client/datascience/kernel-launcher/kernelFinder.ts
77.01% <0.00%> (+13.04%)
:arrow_up:

Continue to review full report at Codecov.

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


www/nginx: allow ports in upstream Host and XFH headers

Hi!
ref. https://github.com/opnsense/plugins/pull/3365
may close https://github.com/opnsense/plugins/issues/3317
-allow to set port number (in Upstream settings) that will be attached to the proxy_set_header Host $host
-allow to use unchanged Host header from the users request in X-Forwarded-Host header
Thanks!

@fabianfrz how about now? tried to make it a little shorter

Ok sorry I have to pass this over to next one (1.33) since I have to cut 1.32. for 23.1.6 today.

@fichtner ok, i'll update this. thanks

that is ok.

Merged, thanks!

@fabianfrz @fichtner thanks!


Display empty stages with another color and status

When using declarative pipelines, skipped stages from a "when" clause are
displayed as "SUCCESS" in green. This is a bit misunderstanding because
you can think the stage was effectively ran.
With this commit, skipped stages are displayed in gray and have the
"EMPTY" status.

As an exemple with the following pipeline :
pipeline{
    agent any
    stages{
        stage("build"){
            steps{
                sh("echo build")
            }
        }
        stage("test"){
            steps{
                sh("echo test")
            }
        }
        stage("publish"){
            when{
                branch "master"
            }
            steps{
                sh("echo publish")
            }
        }
    }
}
```
![image](https://user-images.githubusercontent.com/2646864/29242371-67c4039a-7f8c-11e7-9415-f492785d540d.png)

Hey, good job! I find it very useful for me.

@vvanholl This looks like a pretty reasonable addition and AFAICT the code looks correct (though it's generally preferred to see a new status in the Pipeline Graph Analysis plugin, where Blue Ocean can consume it, if possible).
However, it does still need testcases before I can merge it.

Good idea! Waiting for the merge.
I think it would be more clear if you change "empty" with "skipped".

@mvanini It's not mergeable without appropriate test coverage -- if you are waiting for merge, you can make that happen by providing a PR replacing this one which uses this branch as its base and includes tests.

I agree this is a good idea. I guess the original requester has lost interest in this PR?
I would be interested to see if this appears in historical builds where a stage has been introduced. Currently those stages disappear - when IMHO it would be better for them to still be displayed - but with the missing stages in grey.

Is it solved now??

Any advance or workaround/plugin?


[BUG] Varcem creates an empty config.varc file

Hello!
In the last two  or three commints, Varcem creates a config.varc that is empty (0 kb) , so never saves the configuration. The emulator works if I add the config.varc file form an older commit creted in novebember, 2018.
Thanks!

Hi,
That is weird!
What do you do to make it do that?
--fred

On Sat, 2/16/19, Fenix770<EMAIL_ADDRESS>wrote:
Subject: [VARCem/VARCem] [BUG] Varcem creates an empty config.varc file (#68)
To: "VARCem/VARCem"<EMAIL_ADDRESS>Cc: "Subscribed"<EMAIL_ADDRESS>Date: Saturday, February 16, 2019, 2:10 AM
Hello!
In the last two  or three commints, Varcem creates a
config.varc that is empty (0 kb) , so never saves the
configuration. The emulator works if I add the config.varc
file form an older commit creted in novebember, 2018.
Thanks!
—
You are receiving this because you are subscribed to this
thread.
Reply to this email directly, view it on
GitHub, or mute
the thread.

In the old commits from the emulator created the file correctly. In the new ones it always says there is no config file and it creates an empty file.

The folder is not write protected i checked it .
I copied the folder to C:\Users....\Documents\win-336_dev-x86 to see if Win 8.1 interferes in some way  but with same results.

So I think in the last commit something was broken.
Thanks!

Fixed in #337, thanks for reporting!


Remove : Litejob detected an exit, cleaning up

This is how my test suite report looks

would it be possible to either disable those logs in test environment or to redirect them to a standard logger?
https://github.com/oldmoe/litestack/blob/0dbd6194606b71839017bb656ed906602d861888/lib/litestack/litejobqueue.rb#L145

As per this recent commit which has yet to be released, looks like this error message will no longer be displayed when  number of jobs in flight is zero
https://github.com/oldmoe/litestack/commit/ee2eac82ca917c7e96f149f6c782ba9297b10223
Would be nice to have this new change documented in the changelog

Thanks
This being said, there is the @logger instance variable available in this class. So maybe puts could be replaced by @logger.info("...").

Yes, this will be removed in the next release if the remaining job count in flight is zero, the main reason to show this on STDOUT is to highlight the reason the process exit is delayed to a manual operator. Logging is optional so there will be cases when the Logger is not available/useful


Short docs

We need to write a short document about all functions in init.py which have the decorator @register_function. For each function we need a bullet poinnt with a short sentence and below a single line of code demonstrating how the function works.
Examples:

Takes a binary image and draws cuts in the objects similar to the ImageJ watershed algorithm
nsbatwm.split_touching_objects(binary_image)

Applies Otsu's threshold selection method to an intensity image and returns a binary image.
nsbatwm.threshold_otsu(image)

Apply a median filter to an image to remove noise while preserving edges.
nsbatwm.median_filter(image)

Now, do this for all the specified functions.
git-bob comment

included into the code in https://github.com/haesleinhuepf/napari-segment-blobs-and-things-with-membranes/commit/ebc23d5fcd37b0fd5d83a6826572a1613bbb212c


Use cookies to remember user preferences

It would be helpful to set cookies to restore user state when they return to the page. This should be an optional feature that allows the user to opt-out. The first time we attempt to save a cookie we can show a toast that has some kind of countdown that presents them with an option to accept or decline.
Things we could track:

dark/light mode preference
shown/hidden columns
selected sorts
filter states
column position

#80 partially implements this


[TimeLine] Startline display

This PR closes #207

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Proposal: Add an "exclusive or" (^) operator

Based on this comment TypeScript does not allow exclusive union types.
I'm proposing a logical or operator similar to union (|) or intersection (&) operators that allows defining types that are one or another.
Code
type Person = { name: string; } ^ { firstname: string; lastname: string; };

const p1: Person = { name: "Foo" };
const p2: Person = { firstname: "Foo", lastname: "Bar" } ;

const bad1: Person = { name: "Foo", lastname: "Bar" }
                                    ~~~~~~~~~~~~~~~   Type Person can not have name and firstname together
const bad2: Person = { lastname: "Bar", name: "Foo" }
                                        ~~~~~~~~~~~   Type Person can not have lastname and name together

For literal and primitive types it should behave like union type:
// These are the same
type stringOrNumber = string | number;
type stringORNumber = string ^ number;

The issue is there are no exact/final types in TS. all types are open ended.  so this is allowed from an assignable perspective:
var p1: {name: string };
var p2 =  {name:"n", firstName: "f", lastName: "l"};
p1 = p2;  // OK

A type is assignable to a union type, iff it is assignable to one of the constituents. so even with the exclusive union, open types would allow that check to pass.
Another feature that TS has is flagging "unknown" properties. This only applies to object literals, that happen to have a contextual type. e.g.:
var p: {name: string} = { name: "n", another: "f" }; // Error `another` is not a known property

This check is simplified for union types, just to say it has to be a "known" property on the union in general, not for this constituent. The main issue here is how unions are compared, when we are comparing constituent types, we do not know if we should check for "unknown" properties, because it might be one of the other types.
If i am not mistaken, you are after this unknown property check in this case. I would say we are better off trying to change how this is handled for unions, rather than creating a new concept in the language that users need to understand.
Related discussion in https://github.com/Microsoft/TypeScript/issues/12997. Issue tracked by  https://github.com/Microsoft/TypeScript/issues/12745

#12745 will solve parts of this problem. But it won't have exclusive or logic because tagged unions are merging assignable types. For example:
interface A { foo: string; }
interface B { bar: string; }

type C = A | B;

const a: C = { foo: '' } // Wrongfully ✔ // Hopefully #12745 fixes this
const b: C = { bar: '' } // Wrongfully ✔ // Hopefully #12745 fixes this
const c: C = { foo: '', bar: '' } // ✔

What I'm suggesting is an exclusive or operator between two interfaces:
interface A { foo: string; }
interface B { bar: string; }

type C = A ^ B;

const a: C = { foo: '' } // ✔
const b: C = { bar: '' } // ✔
const c: C = { foo: '', bar: '' } // ❌

without exact types the new operator does not solve the issue, since { foo: '', bar: '' } is still a { foo: string; }

This would be really helpful, Allows better management in development time.

Presumably the behavior here would be that
type A = { m: T } | { n : U };

is equivalent to
type A = { m: T, n: undefined } | { m: undefined, n : U };

@RyanCavanaugh it makes it even easier to implement as de-sugar algorithm is so easy!
This operator is still a good idea since there are lots of cases where an API expect two or more completely different interfaces.
Adding undefined can pile up quickly:
type A = { m: T } ^ { n:  U } ^ { o: Q }

vs.
type A =
    { m: T; n: undefined; o: undefined; } |
    { m: undefined; n: U; o: undefined; } |
    { m: undefined; n: undefined; o: Q; }

Search terms so I can find this later: "mutually exclusive" "disjoint unions"

I'd like to add another use case for this feature. I'm currently using json-schema-to-typescript to generate TypeScript interfaces from JSON Schema. Currently the "oneOf" keyword is listed as not expressible in TypeScript. Having exclusive unions would then make it expressible.

With this example:
type A = { m: T } ^ { n:  U } ^ { o: Q }
// ->
type A =
    { m: T; n: undefined; o: undefined; } |
    { m: undefined; n: U; o: undefined; } |
    { m: undefined; n: undefined; o: Q; }

This actually doesn't work:
// Assume T, U, and Q are string:
let a = { // <-- error
  m: ""
}

Because it expects:
This actually doesn't work:
// Assume T, U, and Q are string:
let a = {
  m: "",
  n: undefined, // <-- expects undefined value
  o: undefined,  // <-- expects undefined value
}

You have to define it like this:
type A =
    { m: T; n?: undefined; o?: undefined; } |
    { m?: undefined; n: U; o?: undefined; } |
    { m?: undefined; n?: undefined; o: Q; }

But that allows you to put n: undefined on the object, which makes the key enumerable. So far I've found this works out better:
type A =
    { m: T; n?: never; o?: never; } |
    { m?: never; n: U; o?: never; } |
    { m?: never; n?: never; o: Q; }

I wish there was an ^ operator. I've been bitten by thinking | was supposed to be an exclusive OR. Thinking about bitwise it makes sense. But I almost always want ^ instead of |.

I'm all for the ^ sugar, that's great.
But I also think TS needs to recognize and leverage mutually-exclusive union patterns, regardless of the sugar. For example, { kind: 'foo'; } | { kind: 'bar'; } is mutually exclusive because kind cannot possibly be 'foo' and 'bar' simultaneously. Likewise with literal number types. And naturally, { m: T; n?: never; } | { m?: never; n: U; } under discussion as a de-sugared { m: T; } ^ { n: U; } is mutually exclusive as well. None of these types is mutually exclusive because of any specific syntax, they just are exclusive by their very nature.
But TS doesn't recognize or leverage that fact as strongly as it could. For examples, #20375 and #21879 could benefit from recognizing mutually exclusive unions to allow for narrowing (that would not be safe with mutually inclusive unions). So I think this request should be more than just sugar.

We already turn unit type contradictions ("foo" & "bar") into never during union/intersection type distribution.
Going further than that is somewhat dangerous because it means we'd produce never in a way that was fundamentally un-debuggable - imagine intersection two types and deep inside two uninteresting properties conflict and the whole thing collapses to never and you'd have no way to figure out why.
Also, sometimes you want to intersect two types in a way where you're using the part of it that isn't contradictory.

I agree with the debugging issue; having a way to investigate type inference would be really useful in general but I imagine that would be very difficult to offer.
But I still think never is the correct type for this case. Omit could be used, perhaps, to specify that you weren't interested in that bit that conflicts; certainly on our project, that would be an expectation that we'd have of our coders, to be explicit about something like that.
Finally, even if you really want to maintain { kind: 'foo'; } & { kind: 'bar'; }, test.kind should still have the type never. It currently has the type 'foo' & 'bar', which is, again, impossible.

It seems like this operator should result in closed types rather than open types like the union operator.

I think I figured this out. By introducing a Without generic that forces all properties in an object to not present we can construct a working XOR generic:
FYI @isiahmeadows
type Without<T> = { [P in keyof T]?: undefined };
type XOR<T, U> = (Without<T> & U) | (Without<U> & T)

type A = XOR<{hi: number}, {bye?: number}>

type NameOnly = { name: string };
type FirstAndLastName = { firstname: string; lastname: string };
type Person = XOR<NameOnly, FirstAndLastName>

const p1: Person = { name: "Foo" };
const p2: Person = { firstname: "Foo", lastname: "Bar" } ;

const bad1: Person = { name: "Foo", lastname: "Bar" }
const bad2: Person = { lastname: "Bar", name: "Foo" }

Works in 2.7:

@mohsen1 Hat off! 🎩
I've tried to play with your solution a bit, and so far I haven't been able to find a solution that allows common property names to remain in the resulting type. Below a simple example:

In the real life use cases I have for an exclusive OR type, objects generally have at least some properties in common.

@SylvainEstevez Maybe this way?

@geovanisouza92 Yes that'd definitely work! Only issue is that it requires the Pizza and Sandwich types declaration to be split, which in real life would be pretty weird :/

@mohsen1 Do you need to include the intersection? I know yours is effectively the symmetric difference based on properties, but it seems people here were looking for something closer to a logical xor rather than a set-wise xor.

I agree, we need to address shared properties too. I've made an Intersection generic that can get us some good result but it doesn't work for all cases
type Without<T> = { [P in keyof T]?: undefined };
type Intersection<T, U> = { [P in keyof (T | U)]: T[P] | U[P] };
type XOR<T, U> = Intersection<T,U> | ((Without<T> & U) | (Without<U> & T));

type NameOnly = { name: string; height: number; };
type FirstAndLastName = { firstname: string; lastname: string; height: number; }
type Person = XOR<NameOnly, FirstAndLastName>
type HeightOnly = Intersection<NameOnly, FirstAndLastName>

const h: HeightOnly = { height: 100 }
const p1: Person = { name: "Foo", height: 1.8 };
const p2: Person = { firstname: "Foo", lastname: "Bar", height: 2.0 } ;

const bad1: Person = { name: "Foo", lastname: "Bar" }
const bad2: Person = { lastname: "Bar", name: "Foo" }
const bad3: Person = { name: "Foo", lastname: "Bar", height: 10 } // 😵

I'm confused why bad3 is a member of Person type?

Using the upcoming TypeScript 2.8 exclude type, what about:
//tslint:disable
type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never };
type XOR<T, U> = (Without<T, U> & Required<U>) | (Without<U, T> & Required<T>)

type NameOnly = { is: "NameOnly", name: string };
type FirstAndLastName = { is: "FirstAndLastName", firstname: string; lastname: string };
type Person = XOR<NameOnly, FirstAndLastName>;

let person: Person;

person = {  is: "NameOnly", name: "Foo" };
person = { is: "FirstAndLastName", firstname: "Foo", lastname: "Bar" } ;

@EliSnow wow! Conditional Types were answer to every TypeScript problem, weren't they?
I think Required is not necessary there. It can break optional members of T and U
type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never };
type XOR<T, U> = (Without<T, U> & U) | (Without<U, T> & T)

type NameOnly = { name: string; height: number; weight?: number; };
type FirstAndLastName = { firstName: string; lastName: string; height: number; }
type Person = XOR<NameOnly, FirstAndLastName>

const p1: Person = { name: "Foo", height: 1.8 };
const p2: Person = { name: "bar", height: 1.3, weight: 100 }
const p3: Person = { firstName: "Foo", lastName: "Bar", height: 2.0 } ;

const bad1: Person = { name: "Foo", lastName: "Bar" }
const bad2: Person = { lastName: "Bar"}
const bad3: Person = { height: 10 }
const bad4: Person = { name: "Foo", lastName: "Bar", height: 10 }

We ask for new operators and random fancy features and @ahejlsberg is like here is "conditional types" go build those things yourself! 😁

A little more conditional types magic so it works with primitive types:
type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never };
type XOR<T, U> = (T | U) extends object ? (Without<T, U> & U) | (Without<U, T> & T) : T | U;

type NameOnly = { is: "NameOnly", name: string };
type FirstAndLastName = { is: "FirstAndLastName", firstname: string; lastname: string };
type Person = XOR<NameOnly, FirstAndLastName>;
let person: Person;

person = { is: "NameOnly", name: "Foo" };
person = { is: "FirstAndLastName", firstname: "Foo", lastname: "Bar" };

let stringOrNumber: XOR<string, number>;
stringOrNumber = 14;
stringOrNumber = "foo";

let primativeOrObject: XOR<string, Person>;

primativeOrObject = "foo";
primativeOrObject = { is: "NameOnly", name: "Foo" };
primativeOrObject = { is: "FirstAndLastName", firstname: "Foo", lastname: "Bar" };

@EliSnow
Yup with primitives exclusiveness doesn't mean anything. Your latest iteration satisfy everything I asked in the original post.

@mohsen1 BTW, I beat you to it kind of already for the logical variant of the type.

#23777 is an example of why this feature would be very nice without complex workarounds, which can cause performance issues.

Can we close this thread?
If anyone's looking for ways to generatate XORs for arbitary ammounts of keys i'll direct you to
https://stackoverflow.com/questions/54874718/in-typescript-how-to-use-a-string-type-union-to-constraint-a-key-from-another-t/54875224#54875224
(way4 and way5)

just sumbled uppon this ussue ass well and this is my solution for anybody who will land here after me:
// Omit<{ a: string, b: string }, "a">  ==> { b: string }
type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>

// PickOne<{ a: string, b: string }, "a"> ==> { a: string; b?: never };
type PickOne<T, K extends keyof T> = Pick<T, K> & { [P in keyof Omit<T, K>]?: never };

// base type with all properties
type M = { m: number, n: number, o: number };

// type that allows EXACTLY ONE property from M
type N =
   | PickOne<M, "m">
   | PickOne<M, "n">
   | PickOne<M, "o">;

// OK
const n1:N = { m: 42 };
const n2:N = { n: 42 };
const n3:N = { o: 42 };

// Type '{ o: number; x: number; }' is not assignable to type 'N'.
//  Object literal may only specify known properties, and 'x' does not exist in type 'N'.
const n4:N = { o: 42, x: 42 };

//  Type '{ o: number; m: number; }' is not assignable to type 'N'.
//  Type '{ o: number; m: number; }' is not assignable to type 'PickOne<M, "o">'.
//    Type '{ o: number; m: number; }' is not assignable to type '{ m?: never; n?: never; }'.
//      Types of property 'm' are incompatible.
//        Type 'number' is not assignable to type 'never'.
// (same error goes for other conbinations of m, n and o properties)
const n5:N = { m: 42, n: 42 };

only thing, that i didnt figure out is generic declaration of type N:
type P = "m" | "n" | "o";
// same as M above, but uses unit P
type M = { [key in P]: number }

// this one will work only if typeof T === typeof M
// (second param of PickOne must be keyof T - dont know how to enumerate that into union...)
type PickExaclyOne<T> =
   | PickOne<T, "m">
   | PickOne<T, "n">
   | PickOne<T, "o">;

// ideall way, how to define type N
type N = PickExaclyOne<M>

A little more conditional types magic so it works with primitive types:
type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never };
type XOR<T, U> = (T | U) extends object ? (Without<T, U> & U) | (Without<U, T> & T) : T | U;

type NameOnly = { is: "NameOnly", name: string };
type FirstAndLastName = { is: "FirstAndLastName", firstname: string; lastname: string };
type Person = XOR<NameOnly, FirstAndLastName>;
let person: Person;

person = { is: "NameOnly", name: "Foo" };
person = { is: "FirstAndLastName", firstname: "Foo", lastname: "Bar" };

let stringOrNumber: XOR<string, number>;
stringOrNumber = 14;
stringOrNumber = "foo";

let primitiveOrObject: XOR<string, Person>;

primitiveOrObject= "foo";
primitiveOrObject= { is: "NameOnly", name: "Foo" };
primitiveOrObject= { is: "FirstAndLastName", firstname: "Foo", lastname: "Bar" };

Is this a bug?

I've got an error in this sample of code with @EliSnow XOR type https://gist.github.com/inoyakaigor/a7ddca413753c4a3460544348f13f1e9
If change it to
type XOR<T, U> = (T | U) extends Object ? (Without<T, U> & U) | (Without<U, T> & T) : T | U; (Object instead of object) fix it

What about long chains of XOR types? People might have use-cases (like I do) when you have to XOR more than 40 types.
This is how it looks:
export type Task =
    XOR<{ a: AModule },
      XOR<{b: BModule },
        XOR<{ c: CModule },
          XOR<{ d: DModule },
            XOR<{ e: EModule }, { f: FModule }> // ...
          >
        >,
      >
    >;

I would perfer to have:
XOR<
  { a: AModule },
  { b: BModule },
  { c: CModule },
  { d: DModule },
  { e: EModule },
  { f: FModule },
  ...
>

or

^ { a: AModule },
^ { b: BModule },
^ { c: CModule },
^ { d: DModule },
^ { e: EModule },
^ { f: FModule },
//  ...

Related https://github.com/krzkaczor/ts-essentials/issues/183

@sobolevn The former isn’t too hard to write in Typescript 4.1:
type AllXOR<T extends any[]> =
    T extends [infer Only] ? Only :
    T extends [infer A, infer B, ...infer Rest] ? AllXOR<[XOR<A, B>, ...Rest]> :
    never;

Before 4.1, you don’t have conditional recursive types, which makes this a pain. There are often ways to get around that, but I don't know what you would need to do to satisfy the compiler there off the top of my head.

hello,
so this is a 6 years old topic and nothing was done so far; looking at the roadmap, nothing is going to be done.
my question is at this point in time, what is the reason for NOT even discussing this?
what are the technical challenges that prevents this feature to be implemented?
is there an elegant alternative (i do find this xor proposal an ugly hack)
is there an official position / statement / blog ...anything that would at least close this matter?

Every suggestion here is approximately 6 to 8 years old, that's what happens when your programming language is ten+ years old and has been popular for 6 to 8 years. If your bar for "it should be done by now" is "it's six years old", then you think TypeScript should have approximately every feature anyone's ever thought of.

I rewrote the XOR type a bit, which can accept more parameters. The problem for me was not this, it was the problem with "recursion is too long and possibly infinite" @krryan said that the limit was 40 but for me the error appeared from the 10th type, possibly because my types were more complex, I didn't have tested for my variant which is the limit but with 11 it works ok
export type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never };

export type SkipUnknown<T, U> = unknown extends T ? never : U;

export type XOR<
  A,
  B,
  C = unknown,
  D = unknown,
  E = unknown,
  F = unknown,
  G = unknown,
  H = unknown,
  I = unknown,
  J = unknown,
  K = unknown,
> =
  | (Without<B & C & D & E & F & G & H & I & J & K, A> & A)
  | (Without<A & C & D & E & F & G & H & I & J & K, B> & B)
  | SkipUnknown<C, Without<A & B & D & E & F & G & H & I & J & K, C> & C>
  | SkipUnknown<D, Without<A & B & C & E & F & G & H & I & J & K, D> & D>
  | SkipUnknown<E, Without<A & B & C & D & F & G & H & I & J & K, E> & E>
  | SkipUnknown<F, Without<A & B & C & D & E & G & H & I & J & K, F> & F>
  | SkipUnknown<G, Without<A & B & C & D & E & F & H & I & J & K, G> & G>
  | SkipUnknown<H, Without<A & B & C & D & E & F & G & I & J & K, H> & H>
  | SkipUnknown<I, Without<A & B & C & D & E & F & G & H & J & K, I> & I>
  | SkipUnknown<J, Without<A & B & C & D & E & F & G & H & I & K, J> & J>
  | SkipUnknown<K, Without<A & B & C & D & E & F & G & H & I & J, K> & K>;

so Is there a best practice for implementing type now ?
the discussion is too long.
we can use ^  now ？ @RyanCavanaugh  or use XOR like @mohsen1  said ？

If you ended up here from Google, I've packaged up a working solution complete with tests and documentation and published it on npm as ts-xor (shameless plug blah blah but I've ended up needing this way too often and thought I'd make a neat shareable solution I don't feel but introducing as a dependency at work).

I was recently led here indirectly when asking on Stackoverflow about this functionality. It's roughly a year or so since the last comment so I figured I'd voice one.
It feels that from an end user perspective the ability to say something is "one of these types" in a native built-in way would be extremely helpful.  It could possibly have better intellisense than options you will see suggested such as ts-essentials XOR or ExclusifyUnion custom type def from https://stackoverflow.com/a/46370791/5117487.
I've read through the comments and as someone on the newer side of learning typescript I was wondering if it can be shared if there is technical limitations that block this from being native to TS? Or even design philosophical reasons why it should not be included? Not so as to put pressure on why it does not exist today but I think it is what I see missing from this thread thus far in what mostly became driven by external library solution talks.

I've read through the comments and as someone on the newer side of learning typescript I was wondering if it can be shared if there is technical limitations that block this from being native to TS?

This would not prevent from the additional properties to exist, because additional properties are allowed to exist. It would only work for excess property checks and object literals, which is not really what the people want. An operator like this would only really make sense when we have Exact Types (#12936).

Thanks for the reply @MartinJohns

This would not prevent from the additional properties to exist

I don't follow this part - the linked "ExclusifyUnion" suggestion (very popularly pointed to online) and ts-essentials XOR does stop the properties from existing. You can see this in this playground.
Maybe you are referring to one of the few suggested approaches in this issue specifically? I personally am not suggesting one specific one (to ignorant of under the hood of TS to be making suggestions yet).
Though I could be misunderstanding depending on how you are distinguishing between blocking "additional properties ... exist[ing]" and "excess property checks". My current level of understanding interprets that as the same thing? From all the stackoverflow posts / blog posts I've read on this it seems to be exactly what many people want (blocking extra properties) so again not sure what you are referencing when you say it is not what the people want.
I read through the Exact Types suggestion you linked and yes I do think (from what I can tell) that it is one way to solve this. Though you say "when we have" but I don't get any stronger sense from reading all the comments there that it is committed to versus something like proposed in any of the comments here (except for of course that this one was closed).

here in 2024 and I would be happy for it.


Better Programmatic API

PSL is great as a stand alone program (whether run in Groovy or CLI).
But, I want to be able to load a PSL model/data and run online tasks.
This is not about updating in real-time, but just about using PSL as a decision maker to drive some larger program.

Hello - was this completed enough for PSL to be embedded in a program for ongoing predictions?  (As you say, online evaluations but not online training.)  Is there some example code somewhere for it?  Thanks!

It can be done, but I don't think this issue will be properly solved until we have a pure Java interface (#44).
Pure Java can already be used to define and run a PSL program (eg in the tests: https://github.com/eriq-augustine/psl/blob/master/psl-core/src/test/java/org/linqs/psl/model/rule/GroundRuleTest.java#L131 ), but it is more bulky than the Groovy interface.
With the support of the string rule parser, implementing the Java interface shouldn't be too hard.
We have also had good experiences calling the PSL CLI from Python.
That is pretty different approach to this problem, but calling out to the CLI is a viable alternative.

Thanks for the information!  By "support of the string rule parser" -- do you mean that the string parser is available or not available yet?

It is available.
See https://github.com/eriq-augustine/psl/wiki/Rule-Specification-in-Groovy#string-syntax for examples.
The historical decisions relevant to this was that Groovy was chosen as the language for the interface to the PSL engine because enough operators could be overridden to make the syntax for PSL rules look like natural first-order logic rules.
But as we have added more functionality, like arithmetic rules, overriding Groovy operators is no longer sufficient.
That and the CLI drove the need for more robust and formal language definition for PSL rules.
Which was implemented and currently used: https://github.com/eriq-augustine/psl/blob/master/psl-parser/src/main/antlr4/org/linqs/psl/parser/antlr/PSL.g4
So now that we are no longer dependent on overriding Groovy operators, we can implement a Java interface where rules are defined as strings.


Rouge-SU-4 (skipgram)

I was trying to migrate from https://github.com/tagucci/pythonrouge whose ROUGE-SU-4 has the highest variance on my summary evaluations (and so is an important metric in the PCA/eigenvector sense) but you don't provide it. Are there plans for it? Is there a reason why it wasn't or won't be implemented?

The ROUGE implementation in evaluate relies on Google's ROUGE repository. Feel free to open a PR if you'd like to add this as a feature.


Allow user to select date range from a predefined set of date ranges

This is a feature request. Add an option to set predefined date ranges the user can select from. This feature is extremely useful in reporting.

This feature is available in the Date Range Picker for Bootstrap  by Improvely.

This is a duplicate of https://github.com/airbnb/react-dates/issues/29
It's already possible to do this functionality because the DRP is fully controlled by adding some buttons inside the renderCalendarInfo prop (which takes a function that returns a node) that would set start and end date appropriately.
That being said I think exporting a PresetDateRangePicker component with that prop already set up seems reasonable.

I'm gonna close in favor of #29 (and in order to pare down the number of issues a bit)

Thanks @majapw. Did not see the renderCalenderInfo prop or the PresetDateRangePicker example in the docs.

how did you focus to the selected date range when u selected custom date range.


Posting to nested forms without leading / modifies route (since v2.3.0)

Reproduction
https://stackblitz.com/edit/remix-run-remix-tutwtc?file=app%2Froutes%2F%24.tsx

nested url -> routeParam submit -> check terminal log of route params & pathname

Working cases (flat url, posting form with leading /) included for convenience
System Info
System:
    OS: macOS 14.1.1
    CPU: (10) arm64 Apple M2 Pro
    Memory: 2.71 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.9.0 - ~/.nvm/versions/node/v20.9.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v20.9.0/bin/yarn
    npm: 10.2.4 - ~/.nvm/versions/node/v20.9.0/bin/npm
    pnpm: 7.28.0 - ~/.nvm/versions/node/v20.9.0/bin/pnpm
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Safari: 17.1

Used Package Manager
npm
Expected Behavior
The route do not change, independent of the form action
Actual Behavior
When submitting to an action with a dash that isn't in the first position, the route is changed

This is the result of a recent bug fix in React Router (https://github.com/remix-run/react-router/pull/10983) where useResolvedPath was not working correctly for splat routes (this is what is called internally by useFormAction).
Relative routing when not using a leading / is relative to the current location, so when you are on http://example.com/foo, if you have a <Link to="foo">/<Form action="foo">, then that should append to the current location and result in http://example.com/foo/foo.  Previously, this behavior was broken in splat routes so there was an inconsistency across static, dynamic, and splat routes where static/dynamic were relative to the current route location but splat routes were relative to the parent route.
This shows itself most notably when using an action on a splat route:
// $.tsx
export function action() { ... }

export default function Component() {
  return (
      <Form method="post">
        <button type="submit">Form no action</button>
      </Form>
    </>
  );
}

Submitting the above form in Remix 2.2.0 and before would throw a 405 error because the <Form> action (defaulting to ".") would be relative to the splat parent (/), not the current location (i.e., /foo), so it would look on root.tsx for the action instead of the current route.
Whereas if you did the exact same thing above in a static route (foo.tsx) or a dynamic route ($param.tsx) then it would work as expected.  This unit test shows the expected consistency across route types with the aforementioned fix.
If you want your paths to be relative to the parent, you can do that via:
<Form method="post" action={`../${routeParam}`}>


simplify & standardize makie rendering of objects

This pull request is to simplify the Makie rendering process for objects. Instead of manually dispatching each object type (apart from Agent) using if statements and rendering it separately, this branch implements a default consistent rendering for an object (based on its character representation, as is done previously).
A change that occurs with respect to the previous rendering is that walls are now :white (implied by its get_color method), as opposed to being :darkgray earlier. Note that this default implementation can be easily overridden by explicitly checking for a particular object type. For example, in this case, we could add an if statement to check for a Wall and manually set the color to :darkgray. However, I feel that :white doesn't look too bad (in my humble opinion :smile: )
Overall, I believe this buys us a cleaner code and a consistent rendering across Makie and the terminal.

Codecov Report

Merging #29 into master will increase coverage by 0.93%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master      #29      +/-   ##
==========================================
+ Coverage   41.04%   41.98%   +0.93%
==========================================
  Files          10       10
  Lines         268      262       -6
==========================================
  Hits          110      110
+ Misses        158      152       -6

Impacted Files
Coverage Δ

src/render_with_Makie.jl
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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

This looks great!


Fix 4bpp tiled tga bugs

When a 4bpp tga is decoded using the tga_image_decode_tiled function, odd rows are skipped. This addresses that. This is a quick fix; there definitely are more performant ways to do this, such as a bitshift, but for clarity reasons I opted not to do that.

Thank you for the patch.


Beryllium UAT Phase 3: Test on a Summer 24 sandbox failed when just loading the app

after 24 hours, the app works again. nothing changed.
maybe a patch from Salesforce....


Discord Linux Phone Verification Form

What is your username and discriminator?
Bitcoin#4388    ID:<PHONE_NUMBER>01981957
Why did you join Discord Linux?
It is official and I want to see what's in the server.
Where did you hear about Discord Linux?
Discord Feedback server
What is the passphrase that was assigned to you by the bot?
Welcome to Discord Linux!
Read Me!
Please read the rules carefully to familiarize yourself with our community guidelines and important things to know. Click this link and type the passphrase exactly as it appears in the link without copy and pasting it to enter the server. Entering the passphrase will indicate you have read and agree to follow all rules.
Info
Username: Bitcoin#4388
ID:<PHONE_NUMBER>01981957
Created: 2017/10/24 01:04:29

That's not the passphrase that you were given, that's the text giving you a link that will tell you the passphrase. Please read over that and post the actual passphrase here.


Add Korean Translation Support

I added korean documents,
see this -> https://github.com/2jun0/lovebrew-ko-kr

Ah, apologies for not seeing this sooner. I will look it over ASAP.

Looks good at a quick pass. Awesome work!


Bug: H2 maps decimal to bigint

Describe the bug
H2 is mapping BigDecimals to but should map to numeric as according to the dialect docs?
See:
https://github.com/komapper/komapper/blob/3c69412c0bdbbc4e3ae3a2c5400cd61b2a5875c4/komapper-dialect-h2-jdbc/src/main/kotlin/org/komapper/dialect/h2/jdbc/H2JdbcDataTypeProvider.kt#L40
https://github.com/komapper/komapper/blob/3c69412c0bdbbc4e3ae3a2c5400cd61b2a5875c4/komapper-dialect-h2-r2dbc/src/main/kotlin/org/komapper/dialect/h2/r2dbc/H2R2dbcDataTypeProvider.kt#L34
Expected behavior
"bigint" should be "numeric"
Actual behavior
H2 returns a big int if the type is defined as java.math.BigDecimal
Steps to reproduce the problem
Versions

Komapper: 1.16
Kotlin:
JVM:
JDBC Driver or R2DBC Driver:
Database:
OS:

Thanks for your report.


Current path not correctly display in zsh-snap parent folder

Describe the bug
I cloned zsh-snzp in the ~/dev/clone folder. Unfortunately, when I'm navigating to this folder the part of the prompt display ~znap instead of ~/dev/clone.
Steps To Reproduce
Last login: Sat Aug 27 15:38:30 on ttys010
{15:38}[ruby-2.7.2]~ ➭ cd dev/clone/zsh-snap
{15:39}[ruby-2.7.2]~[zsh-snap]:main ✓ ➭ cd ..
{15:39}[ruby-2.7.2]~znap ➭ cd ~/dev/clone
{15:39}[ruby-2.7.2]~znap ➭ cd
{15:39}[ruby-2.7.2]~ ➭ cd dev
{15:39}[ruby-2.7.2]~/dev ➭ cd clone
{15:39}[ruby-2.7.2]~znap ➭ cd ../md
{15:40}[ruby-2.7.2]~/dev/md ➭

Expected behavior
{15:43}[ruby-2.7.2]~ ➭ cd ~/dev/clone
{15:43}[ruby-2.7.2]~/dev/clone ➭

Observed behavior

Click to expand

Environment:

OS: macOS
Terminal: iTerm
Zsh version: 5.7.1
Repo version:

main c0fa1da Let znap source store plugin links in $XDG_STATE_HOME

Ok looking at the README.md it has to do with named dirs

It’s expected behavior, as documented in the part of the Readme that you linked to.


Wrong order of Revision History elements

If a new version is created, something is changed (multiple times) and the document is saved, there are errors according the versions of the revisions.

The revsion history is kind of mixed up (1.0.1-1, 1.0.0, 2.0.0-2.0) (if approved, this lead's to the deadlock)
It is not possible to create a valid document with the form editor because of the revsion history entry is added and can't be changed.

#83 brings some more updates in the revision history and we are confident that everything works as expected now.
If the issue still persists, please let us know. Otherwise this could be closed :slightly_smiling_face:

The Problem is only solved for the second version. When a new (third) version is created, the order is mixed up again.
        {
          "date": "2022-09-21T08:38:00.000Z",
          "number": "1.0.1",
          "summary": "New Version 1"
        },
        {
          "date": "2022-09-21T08:37:00.000Z",
          "number": "1.0.0",
          "summary": "\"Initial Publication\""
        },
        {
          "date": "2022-09-21T08:39:00.000Z",
          "number": "1.0.2",
          "summary": "New Version 2"
        }

I guess your frontend branch (feat/minimal-web-ui) is not up to date. There was a bug that reordered the history elements. This was fixed 7 days ago.

You are right. I had not the latest version.
Issue is solved by #83


Define the Type Model

This needs a lot more documentation, but this will get people to start
thinking about the API. The 'Shadow' typeclass, the most non-obvious
part, is at least well documented.

This all makes sense, but I think for application logic we would probably like to write that in a way that doesn't need to care about the shadowed state of the underlying model.

We do want the application logic to be aware of shadowing, because we want every operation to encode exactly what must be unshadowed for it to be completed. The other options are forcing all of the structure(which is unacceptable for caching purposes) or lazy IO(which is unacceptable due to the transactional nature of the data); we can't guarantee repeatable reads without some sort of system like this.

@harlanhaskins I think unpaid dues would be represented as a lack of a Dues record in the memberDues list for the Term of interest.

@gambogi A third option would be literally representing relationships between structures with the database ID's alone, e.g. memberEvaluations would be of type [Word64]. I anticipate that this would clutter the application logic with lookups and force operations that would otherwise have the opportunity to be pure into the IO monad. Shadowed let's us push a lot of those checks for uninspected data into pattern matching, rather than having to inspect the cache.

Ok, how would you guys feel about this:
data Member = Member {
    memberID            :: Word64
   ,memberUUID          :: UUID
   ,memberUsername      :: T.Text
   ,memberCommonname    :: T.Text
   ,memberToken         :: Maybe B.ByteString
   ,memberHousingPoints :: Int
   ,memberOnfloorStatus :: Bool
   ,memberEboards       :: Fetch [Eboard]
   ,memberRooms         :: Fetch [Room]
   ,memberMemberships   :: Fetch [Membership]
   ,memberEvaluations   :: Fetch [Evaluation]
   ,memberPackets       :: Fetch [Packet]
   ,memberQueues        :: Fetch [Queue]
   ,memberApplications  :: Fetch [Application]
   ,memberDues          :: Fetch [Dues]
   }

Where Fetch is a monad with a MonadIO instance. That way, if you have some pure function on the non-Fetchable components of a Member, you can do something like pureMemberFunction <$> fetchMemberID 1337. Pure functions on, say, Member and [Eboard], and the current time could be something like:
do
    m <- fetchMemberID 1337
    e <- memberEboards m
    t <- liftIO posixTime
    return $ pureMemberEboardTimeFunction m e t

There will be some function like:
runFetch :: Pool Postgres -> LRU (TypeRep, Word64) Dynamic -> Fetch a -> IO a

Using generic programming to create a fair LRU of any type of cache-able object.
Thoughts?

We've opted to pursue the fetch monad approach. Closing until that is addressed.


[FLINK-4581] [table] Table API throws "No suitable driver found for jdbc:calcite"

Thanks for contributing to Apache Flink. Before you open your pull request, please take the following check list into consideration.
If your changes take all of the items into account, feel free to open your pull request. For more information and/or questions please refer to the How To Contribute guide.
In addition to going through the list, please provide a meaningful description of your changes.

[x] General

The pull request references the related JIRA issue ("[FLINK-XXX] Jira title text")
The pull request addresses only one issue
Each commit in the PR has a meaningful commit message (including the JIRA id)

[x] Documentation

Documentation has been added for new functionality
Old documentation affected by the pull request has been updated
JavaDoc for public methods has been added

[x] Tests & Build

Functionality added by the pull request is covered by tests
mvn clean verify has been executed successfully locally or a Travis build has passed

This PR simplifies the planner creation. A dummy JDBC connection which also caused problems for a user is not necessary anymore.

+1 to merge

Merging


meilisearch 0.25.2 checksum mistmatch issue

Describe the bug
👋  it looks like the meilisearch 0.25.2 source tarball got changed, raising this issue to confirm if that is intended. Thanks!

If you didn't retag this on purpose and the hash just changed that could point to a compromised git repo. Are you sure nobody recreated the tag?

Hello @SMillerDev we took the time to check with @Kerollmops but we don't know why and how the first sha were even created (5097f0...).
We downloaded manually our tar.gz https://github.com/meilisearch/meilisearch/archive/refs/tags/v0.25.2.tar.gz and applied sha256 to find out the second hash (544f04...) and not the original one (5097f0...). This tar.gz was created 18/01/2022 and was not modified
As far as we know, the tag was not modified, and still correspond to the github release created the same day, on the same commit: https://github.com/meilisearch/meilisearch/commit/523fb5cd566f22168e89cb0af1f341d9b6f99ede

FIY, we've just release v0.26.0 today -> https://github.com/Homebrew/homebrew-core/pull/96820#pullrequestreview-909043670


Destroy network cache before calculating

@grdw Could you see if this fixes the gas cache issue for you?
My guess is that the "strategies off" calculation was finishing before "strategies on", and the app thought that the "strategies on" load was also complete. Thus, it would be sending the old cached loads even though the "strategies on" calculation was still running.
This change deletes the cache before starting the calculation. That should prevent the old "strategies on" cache from being considered valid.
Closes #1044

Thanks, already saw this flying by in my mail. I'll take a look right now.

Works as expected 👍


Hard coded timeouts have been moved to config

Resolve #96

Coverage remained the same at 45.532% when pulling 1412679d3877a1c4f62fb3a012c821abc3977e9e on remove-hard-coded-timeouts-to-config into 95b8dde3d51ab544a1164d6fe3578c690a2c77b7 on master.

Coverage remained the same at 45.587% when pulling 2271f76467fad44621b2145f360cc794e1b5a98d on remove-hard-coded-timeouts-to-config into 77593e2090d2d8c521c918d2675dc719741157e3 on master.

Coverage increased (+0.06%) to 45.587% when pulling 875a4bcc2dee7d2cd0caf5cc7ecde1b45bae5641 on remove-hard-coded-timeouts-to-config into 487f1bd2c46cecd2a842ee80fbd022990885b4df on master.

Coverage remained the same at 45.587% when pulling 5a96e5c63f0c0e843486e3d5813a0619d2645b28 on remove-hard-coded-timeouts-to-config into a9c6f1a330d66b0896f856ad75b5ecea10e6491a on master.


BLINK installation failed

Hi, I followed instructions to install BLINK with the given command but failed.
pip install -e git+git@github.com:facebookresearch/BLINK#egg=BLINK
It threw an error as follows:
ERROR: git+git@github.com:facebookresearch/BLINK#egg=BLINK is not a valid editable requirement.
It should either be a path to a local project or a VCS URL (beginning with bzr+http, bzr+https, bzr+ssh, bzr+sftp, bzr+ftp, bzr+lp, bzr+file, git+http, git+https, git+ssh, git+git, git+file, hg+file, hg+http, hg+https, hg+ssh, hg+static-http, svn+ssh, svn+http, svn+https, svn+svn, svn+file).

So I slightly revised the command as follows and it worked well.
pip install -e git+https://github.com/facebookresearch/BLINK.git#egg=BLINK

I got error...
Preparing metadata (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [14 lines of output]
error: Multiple top-level packages discovered in a flat-layout: ['img', 'elq', 'blink', 'elq_slurm_scripts'].
  To avoid accidental inclusion of unwanted files or directories,
  setuptools will not proceed with this build.

  If you are trying to create a single distribution with multiple packages
  on purpose, you should not rely on automatic discovery.
  Instead, consider the following options:

  1. set up custom discovery (`find` directive with `include` or `exclude`)
  2. use a `src-layout`
  3. explicitly set `py_modules` or `packages` with a list of names

  To find more information, look for "package discovery" on setuptools docs.
  [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

Here's what I found I had to do in order to install:

Run pip install -e git+https://github.com/facebookresearch/BLINK.git#egg=BLINK
cd to src/blink and create a file called pyproject.toml
add contents:

[project]
name = "BLINK"
version="0.1.0"

[tool.setuptools]
py-modules = []

Re-run Step 1

I am still getting same error. Can anyone pls help me to downlaod BLINK & use it in my local python environment.

hello, I got the same issue, did you solve it?

I am still getting same error. Can anyone pls help me to downlaod BLINK & use it in my local python environment.

I got the solution, after step 3 please run cd ../.. back to your own project root path, and then rerun step 1.


如何用jpg等图片格式做测试

作者您好，看到您代码里的测试数据是mdb格式，想请问一下如何用图片格式进行测试呢，期待回复，多谢多谢

这个可以修改dataloader函数，直接在__getitem__里读取jpg图片之后返回即可。

@meihao5631 Hi, I am also trying to convert the mdb format to jpg images for testing the model. I am wondering if you are able to implement the changes that can accept jpg images.
I need some help in that part. Thank you.

You need to modify the dataloader function to allow the reading of images of other format. This is not hard, you can achieve this by yourself.


POST /global-projects

Is the response on this correct?  It doesn't look correct to me.  POST by making a request with a simple description, and they get a list back of already linked projects?
https://docs.hslynk.com/?urls.primaryName=Global Api#/default/POST_global-projects

Resolved.
Commit id:  https://github.com/hmis-api/global-api/tree/7f2c4d5cb14983dc53b402729a1599f743f54e6a


ovr_sdk_mobile 1.12.0 compatibility

As it is unfortunately too habitual on every ovr_sdk_mobile release, changes to the API break functionality. This time it compiles correctly but it crashes immediately at run time. The change that produces this crash is:

Applications are now required to pass through explicit EGL objects (Display, ShareContext, NativeWindow) to vrapi_EnterVrMode, otherwise the call will fail.

This update is interesting to support the new A-series devices like the Samsung Galaxy A8.

i believe this is complete, right?

Yes.


Add modular classpath handling to Java plugin extension

Fixes #12605
Documentation will be added separately.

I am not sure. I was following what we do for other things. Adding more test tasks is a common pattern because there is currently no other convenience to add them.
Compile tasks on the other hand do not need to be added manually that often, as they are automatically added for each source set.
The ordering issue only exists if plugins want to add tasks and use convention(). As long as the user code only uses set(), we are good. But yes, it is a good reason not to do it for all user/plugin added tasks.
We could leave it like this and rethink the test task behavior when we add more conveniences for adding new test sets (before or for 7.0)?

On the other hand, this particular option is a very "basic" one. So maybe you usually want consistent behavior for ALL tasks. 🤔

Oh right, I forgot that most tasks will be effectively added when you add a SourceSet!
And thus, the convention will be applied.

I propose to merge this like it is now. We can still adjust if we get additional feedback.


Type-unstable struct arguments

Discovered and discussed here.

This is going to be trivial to solve once I've modified the rrule!! interface to provide the arguments passed to the rrule also to the forwards-pass of a rule to the reverse-pass (this is a performance optimisation). Since this is a fairly high-priority problem, I'm going to bump this API change up the list of things which are important, and try to get it done this week.


Can I use *.rdl in the configuration file.

Is it possible to deploy all reports (rdl files) by having *.rdl inside configuration file rather than having single entry for every single report

Hi,
You can configure the release task like this:
Local Report Path: $(System.DefaultWorkingDirectory)/.../*.rdl
Report Upload Path: /ProjectName


ensemble problem

Hello,
I changed the cancer-dream-syn3.yaml with the following configuration
  5 details:
  6 - algorithm:
  7     aligner: bwa
  8     align_split_size: 5000000
  9     nomap_split_targets: 100
 10     mark_duplicates: true
 11     recalibrate: true
 12     realign: true
 13     remove_lcr: true
 14     platform: illumina
 15     quality_format: standard
 16     variantcaller: [mutect2, freebayes, vardict, tnhaplotyper]
 17     indelcaller: false
 18     ensemble:
 19       numpass: 2
 20     variant_regions: ../input/NGv3.bed
... ...

I used mutect2(GATK3.7) and tnhaplotyper from sentieon in the variantcaller list.
This gives error:
subprocess.CalledProcessError: Command 'set -o pipefail; export PATH=/usr/local/share/bcbio/anaconda/bin:$PATH &&  /usr/local/share/bcbio/anaconda/bin/bcbio-variation-recall ensemble --cores=16 --numpass 2 --names mutect2,freebayes,vardi
ct,tnhaplotyper --nofiltered /mnt/data/Datasets/benchmarking/cancer-dream-syn3/work3/bcbiotx/tmpBd4nzQ/syn3-ensemble.vcf.gz /usr/local/share/bcbio/genomes/Hsapiens/GRCh37/seq/GRCh37.fa /mnt/data/Datasets/benchmarking/cancer-dream-syn3/wo
rk3/mutect2/syn3-effects-annotated.vcf.gz /mnt/data/Datasets/benchmarking/cancer-dream-syn3/work3/freebayes/syn3-effects-annotated-filter.vcf.gz /mnt/data/Datasets/benchmarking/cancer-dream-syn3/work3/vardict/syn3-effects-annotated.vcf.g
z /mnt/data/Datasets/benchmarking/cancer-dream-syn3/work3/tnhaplotyper/syn3-effects-annotated.vcf.gz
2017-08-05 05:51:49 cpuserver INFO [bcbio.run.itx] - Note: -w option not given, printing list of sites...
2017-08-05 05:51:50 cpuserver ERROR [bcbio.variation.recall.main] -
java.lang.IllegalStateException: Incompatible header types, collision between these two types: INFO=<ID=ECNT,Number=1,Type=Integer,Description="Number of events in this haplotype"> INFO=<ID=ECNT,Number=1,Type=String,Description="Number o
f events in this haplotype">
      htsjdk.variant.vcf.VCFUtils.smartMergeHeaders       VCFUtils.java:  94
    bcbio.variation.variantcontext/merge-headers/fn  variantcontext.clj: 161
bcbio.variation.variantcontext/write-vcf-w-template  variantcontext.clj: 187
                         clojure.lang.RestFn.invoke         RestFn.java: 573
bcbio.variation.ensemble.intersect/ensemble-vcfs/fn       intersect.clj:  88
   bcbio.variation.ensemble.intersect/ensemble-vcfs       intersect.clj:  86
           bcbio.variation.ensemble.intersect/-main       intersect.clj: 140
                        clojure.lang.RestFn.applyTo         RestFn.java: 137
                                 clojure.core/apply            core.clj: 630
               bcbio.variation.recall.main/-main/fn            main.clj:  34
                  bcbio.variation.recall.main/-main            main.clj:  33
                        clojure.lang.RestFn.applyTo         RestFn.java: 137
                   bcbio.variation.recall.main.main                    :
' returned non-zero exit status 1

It seems mutect2 and sentieon have different formats of ID=ECNT (Integer vs. String). Any way to fix the problem?
Thanks,
-Han

Han;
Thanks for the report and sorry about the issue. It looks like Sentieon makes a number of MuTect2 headers more specific, but this makes them incompatible for merging with the more generic String values MuTect2 uses. @DonFreed -- is this something Sentieon might want to swap to ensure the headers match GATK outputs?
I pushed a fix which will enable this to work in bcbio by using sed to post-process Sentieon output and convert over to what GATK uses. If you update with bcbio_nextgen.py upgrade -u development, remove the tnhaplotyper directory and re-run, it should now work cleanly.
Practically, I don't recommend running GATK3 MuTect2 and tnhaplotyper at the same time. The Sentieon version is meant to be a near identical reimplementation, so you're essentially running the same caller twice. In addition to the wasted CPU cycles, you're biasing the ensemble calls towards the MuTect2 algorithm.
Thanks again for reporting this.

@chapmanb Thanks a lot for the quick fix!
Here are the results I picked from the "validate" folder
GATK3.7 (mutect2)
  1 sample│caller│vtype│metric│value
  2 syn3-tumor│mutect2│SNPs│tp│367
  3 syn3-tumor│mutect2│Indels│tp│342
  4 syn3-tumor│mutect2│SNPs│fp│228
  5 syn3-tumor│mutect2│Indels│fp│54
  6 syn3-tumor│mutect2│SNPs│fn│10
  7 syn3-tumor│mutect2│Indels│fn│27

Sentieon tnhaplotyper (2016.11)
  1 sample│caller│vtype│metric│value
  2 syn3-tumor│tnhaplotyper│SNPs│tp│367
  3 syn3-tumor│tnhaplotyper│Indels│tp│339
  4 syn3-tumor│tnhaplotyper│SNPs│fp│39
  5 syn3-tumor│tnhaplotyper│Indels│fp│10
  6 syn3-tumor│tnhaplotyper│SNPs│fn│10
  7 syn3-tumor│tnhaplotyper│Indels│fn│30

I think tnhaplotyper does a good job in controlling the FP, at least for syn3 dataset.  If I use mutect2 and sentieon together (bias towards mutect2), I expect higher TP, FP and lower FN in the ensemble results.  I will update  bcbio_nextgen and see how the result looks like:)
BTW,
Ensemble using vardict, mutect2 and freebayes
  1 sample│caller│vtype│metric│value
  2 syn3-tumor│ensemble│SNPs│tp│360
  3 syn3-tumor│ensemble│Indels│tp│333
  4 syn3-tumor│ensemble│SNPs│fp│8
  5 syn3-tumor│ensemble│Indels│fp│13
  6 syn3-tumor│ensemble│SNPs│fn│17
  7 syn3-tumor│ensemble│Indels│fn│36

I also tried GATK4-mutect2, but could not finish the variant call due to some spark error.
-Han

A fix has been accepted in the GATK4 to make the GATK's headers more accurate. It should solve this issue with the next release of the GATK4.

Don -- brilliant, thanks so much for fixing it properly in GATK4.


Pylance will prompt "Code is unreachable"  erroneously in a special case

Environment data

Language Server version:  v2023.3.10
OS and version: Ubuntu 18.04
Python version (& distribution if applicable, e.g. Anaconda): Python 3.9.12

Code Snippet

# pwn package is from https://github.com/Gallopsled/pwntools
from pwn import *

p = process('./pwn')
payload = b"%9$p"
p.sendlineafter(b"HELLO?PWN IT!!!\n", payload) # pylance will prompt "Code is unreachable"  after the line of code
p.interactive()  # pylance prompts "Code is unreachable" but it still can be executed

Repro Steps

Create a implement class, for example IMyClass

class IMyClass:
    def functionA(self):
        # Should not be called directly
        raise EOFError('Not implemented')

    def functionB(self):
        print("do something in functionB")
        self.functionA()

    def functionC(self):
        print("do something in functionC")
        self.functionB()

Create a subclass of IMyClass

class MyClass(IMyClass):
    def functionA(self):
        print("do someting in MyClass.functionA")

instantiate MyClass and invoke functionC

if __name__=="__main__":
    myClass = MyClass()
    myClass.functionC()
    print("done")  # pylance prompts "Code is unreachable" but it still can be executed
'''
do something in functionC
do something in functionB
do someting in ClassName.functionA
done
'''

Expected behavior
pylance should not prompts "Code is unreachable" in above case
Actual behavior
pylance prompts "Code is unreachable"  where the codes can be executed in fact.
Logs

No logs

This behavior is intended. The methods in your example do not have a return type annotation, so their return types are inferred. The method IMyClass.functionA always raises an exception, so its inferred return type is NoReturn. (Refer to PEP 484 for information about the NoReturn type.)
If you do not want pylance to infer NoReturn for this method, you need to do one of the following:

Make IMyClass derive from abc.ABC and decorate functionA with @abstract_method. This tells a static type checker that you intend to override this method, so it shouldn't assume that the override will always raise an exception.
Rather than raising an EOFError, raise a NotImplementedError. This is the recommended way in Python to implement an abstract method that is intended to be overridden.
Add a return type annotation to functionA.

class IMyClass:
    def functionA(self) -> None: ...

All of these are considered best practices when writing Python code. I would do all three of these if I were writing this code, but any one of them is sufficient to address the "code is unreachable" issue you are seeing.


How can I get a public key?

I've read all the documents and there's no way to get a public key using a private key or a mnemonic.
Is it possible to transfer coins while the user only has a private key?

Did you mean get the address of the account? You can use tronWeb.address.fromPrivateKey.

Did you mean get the address of the account? You can use tronWeb.address.fromPrivateKey.

tronWeb.address.fromPrivateKey
The code returns the wallet address.
All I want is to return the Publik key as a factor for the private key.

If you have mnemonic, you can use TronWeb.fromMnemonic to get the public key.

you can go with tronWeb.address.fromPrivateKey

как узнать публичный ключ адреса ТРОН
НЕ ПОДСКАЖЕТЕ

To find the public key of a TRON (TRX) address, you need to follow these steps:
Make a Transaction
Check on TRONSCAN
Go to Tronscan and enter the TRON address.
Look at the transaction details to see if the public key is available. It is usually part of the transaction data.
Without a transaction, the public key will remain private.


Issue summoning the possessed elder guardian

The ritual for summoning the possessed elder guardian isn't accepting any fish that I could find. Cod, Salmon, Tropical Fish were attempted. Modifying the ritual with a datapack from forge:fish to forge:chicken allowed the ritual to complete just fine. It seems to be an issue with fish.
System (please complete the following information):

Occultism Version:  occultism-1.20.1-1.109.0
OS: Windows
Minecraft Version: 1.20.1
Modpack Link and Version, or list of mods: Allthemods 9 and Allthemods 9 no frills

Additional context
Atm9 implemented custom ritual designs but that is not the cause of this. I also tested it without the modifications to rule it out.

Closed in #1043


placement no longer gets cloned for every shard in MarkShardAvaialble

The placement clone is now create once before going through all the
shards. This commit also moves a bunch of stuff into placement.go from
the algo module.

Coverage decreased (-1.4%) to 87.844% when pulling 55d8807e9b42d1407b7c1d995ba3697084ea198f on dgromov-no-clone-on-available into f2a900e5b6c7c1856ca1dbef6801048722d5b666 on master.

Coverage decreased (-0.2%) to 89.0% when pulling 1fde687b7e93a89f891ed4887700279cd62b0dd7 on dgromov-no-clone-on-available into f2a900e5b6c7c1856ca1dbef6801048722d5b666 on master.


Migration to torch and lightning 2.0

Note, I've patched CI file so it's working for all tests ^
I will roll it back later


API Reference for .NET Core 3.0

API reference for .NET Core 3.0 must be updated to include all of the changes from 2.2

This has been an ongoing task for each preview.

Last PR was merged today: https://github.com/dotnet/dotnet-api-docs/pull/3263


Travis CI

@route Would need your help with this one: simply logging into https://travis-ci.org and flipping the switch to enable route/mogrify

@talklittle done


email not sending from dev environment

This may just be fallout of the environment we were testing on, but trying to use the function to send e-mail to volunteers was not actually sending e-mail.

@BillWagner It seems that this issue can be closed as it is fixed by TravCav with PR #241 when working on #235 (Email Sending needs full testing/fixing in dev using test tool).
When running the application in debug mode the emails that are created to be sent are written to files in the AppData directory of the current user by the SmtpClient as the deliverymethod is set to SpecifiedPickupDirectory and never 'really sent'.

Closed per discussion and examination.


[docs] List required props first in /api/*

Props in /api/* are now sorted by required first and then by their name.
What props are required is the most important information on how to use a component. Scrolling through the list is error prone and time consuming.
~Sorting on the frontend to not invalidate translated props descriptions.~ Double checked after vague statements from Olivier that order of props is based on pages/api-docs->props not translations/api-docs->propDescriptions.
Example: /api/modal
current next
PR

Should the sorting be done at the rendering step or before?

I already acknowledged that the frontend is not ideal and why it is problematic to do in buildAPI.
Maybe you're suggesting to do it in getInitialProps? I do not know if this brings any benefit. I don't think the page is re-rendered very often. Doing it in getInitialProps would also mean we sort every locale. So it's more work on mount to reduce work in re-render. It's not obvious to me that this is faster.
The decision is trivial if we had getStaticProps though. But we can't use getStaticProps on pages as long as we have getInitialProps on _app which we can drop once we use i18n routing of nextjs

Should the sorting be done at the rendering step or before?

I already acknowledged that the frontend is not ideal and why it is problematic to do in buildAPI.
Maybe you're suggesting to do it in getInitialProps? I do not know if this brings any benefit. I don't think the page is re-rendered very often. Doing it in getInitialProps would also mean we sort every locale. So it's more work on mount to reduce work in re-render. It's not obvious to me that this is faster.
The decision is trivial if we had getStaticProps though. But we can't use getStaticProps on pages as long as we have getInitialProps on _app which we can drop once we use i18n routing of nextjs

Sorting on the frontend to not invalidate translated props descriptions.

@eps1lon I'm asking because we aren't yet translating the .json file. Actually, we have paused the whole sync because there is a bug in the synchronization cc @mbrookes

Sorting on the frontend to not invalidate translated props descriptions.

@eps1lon I'm asking because we aren't yet translating the .json file. Actually, we have paused the whole sync because there is a bug in the synchronization cc @mbrookes

@eps1lon I'm asking because we aren't yet translating the .json files

No, you've asked because you didn't read the PR description. Now you're saying we don't translate props which isn't accurate either. I wasn't aware that we have different files for the list of props and their descriptions. I'm now aware of that after looking instead of you just adressing what I wrote.

@eps1lon I'm asking because we aren't yet translating the .json files

No, you've asked because you didn't read the PR description. Now you're saying we don't translate props which isn't accurate either. I wasn't aware that we have different files for the list of props and their descriptions. I'm now aware of that after looking instead of you just adressing what I wrote.

We can still invalidate keys (no human translator's work will be lost)

Just to add that neither changing the keys, nor the order of them, will invalidate translations (when we have any).

We can still invalidate keys (no human translator's work will be lost)

Just to add that neither changing the keys, nor the order of them, will invalidate translations (when we have any).


packadd loads the plugin twice

Steps to reproduce
Follow the installation guide in https://github.com/prabirshrestha/vim-lsp (vim9script lsp client) (happens with other plugins as well)
Add echom fnamemodify(resolve(expand('<stack>:p')), ':h') in plugin/lsp.vim. You see the different print message twice.
My vimrc is located in ~/.vim/vimrc
with plugins dir in
 ~/.vim/pack/plugins/opt/
Expected behaviour
Print only once
Version of Vim
8.2 Included patches: 1-4179
Environment
Fedora 35
Logs and stack traces
No response

Append a bang to :packadd.  That is, in your vimrc, instead of writing this:
:packadd some_package

Write this:
:packadd! some_package
        ^

With a bang, only the runtimepath is updated, so that later, once your vimrc has been fully sourced, and Vim tries to source the plugins, it can find the package.
Without a bang, the package is sourced immediately.  But then later, it's sourced a second time during the step where Vim sources the plugins.
See :help :packadd.

Oh, sorry for my noobness. It worked. Thanks a lot.


Archive node needs to support storing blocks with missing parents (replace with state_hash)

From deepthi:

If the parent of a block is not in it already then it'll fail. So adding blocks after bootstrap will fail. We need the parent_id to successfully get the chain from the current best tip to genesis
Having the parent state hash alongside the parent id (and removing the non null constraint on parent_id) would help a bit. So there's always a statehash to look up when we want to make that link. The missing blocks will still have to be added separately from another database

However, we should support this and allow patching up the missing bits later. Otherwise, if you're disconnected only for a short while you'll never be able to store data until you get those missing bloocks.

Closed by #6926.


Config values not being read

When I enter my API key in my .env file, it's not being read in the Geocoder class.
In the register method of the GeocoderServiceProvider class, the config('geocoder.key') value prints out fine, reading it from the .env file. But the callback inside the $this->app->bind() method isn't being called. The call to setApiKey in the Geocoder class doesn't take place. This would explain the issue but I have no idea about the cause.
I discovered the problem after immediately getting a Geocoding failed because You have exceeded your daily request quota for this API error when doing reverse geocoding.
Laravel Framework 5.6.7 and the geocoding class was just pulled in today via composer so it must be the latest version.
This bit of a code in a Controller also produces the same error even when I pass along my api key
$client = new Client();
$geocoder = new Geocoder($client);
$result = $geocoder->getCoordinatesForAddress('Infinite Loop 1, Cupertino', 'abc123');

It seems to be related to this issue
Any ideas what causes this?
(Edited with further info and for brevity)

Same problem for me.

Try running php artisan cache:clear

@freekmurze that's not the problem. Already did that. Will dive in to this when I've time 👍

@freekmurze @stefkes found the problem. Obviously you have to use the facade:
use Spatie\Geocoder\Facades\Geocoder;

And not
Spatie\Geocoder\Geocoder

Otherwise it you'll get that error.

thanks @larsjanssen6 - at least for me in phpstorm the class it autopopulates is the more general geocoder class which does NOT read the API key, so changing it to the facade and using the static Geocoder::getCoordinatesForAddress() method fixed it for me :)

I just ran into this issue as well. Glad to find the solution, but curious why dependency injecting Geocoder doesn't work identically to the facade? Shouldn't they be interchangeable?
The facade is ultimately fine, but it doesn't seem to be possible to access the class constant, RESULT_NOT_FOUND, via the facade, so I had switched to dependency injection. (I also liked the more explicit use clause.)

The Facade is not the injected class is not the Facade. The Facade accesses an instance of the class which has already been configured; injection accesses a unique instance instead.

Hmm.. doesn't seem to work for me:
use Spatie\Geocoder\Facades\Geocoder;

class GeoController extends Controller
{
    public function getCoordinates()
    {
        dd(Geocoder::getCoordinatesForAddress('Infinite Loop 1, Cupertino'));
    }
}

Gives me:
"Call to undefined method Spatie\Geocoder\Facades\Geocoder::getCoordinatesForAddress()"

Running php artisan config:cache did the trick for me, I have a laravel installation on shared hosting.