On-chain zipped NFT

Good evening, morning, afternoon or whatever the time is.
I'm new in Solidity development, I don't fully understand how does this work.
I'm contributing on an ERC721A on-chain NFT project, the HTML source code is stored in the contract, but I would like to move the code of the html, json and tokenURI generator (it makes a base64 datauri from the json) to a zipped contract. Is that possible?
Could someone help me out with an example or some other tips?
Also, it's the first time using Fountry, I'm learning it :D
I'm stuck at calling the zipped contract from the tokenURI function. I can't call the zipped contract with delegatecall because it says Function cannot be declared as view because this expression (potentially) modifies the state.
Also I'm not sure if I'm doing the zipped contract right. I'll test it later with other methods if it works at all.

Yes, it should be possible. Often you can just remove the view modifier from the tokenURI() function. You might have to modify your ERC721 interface, or manually re-cast it, for tests, etc, to pass. But for most off-chain callers, it's all the same (they won't be using your ABI anyway).
If you really don't want to modify interfaces, another option is to hide the state-modifying logic from the compiler with a hack like:
    function tokenURI() external view {
        __forwardToZipped(ZIPPED);
    }

    function __forwardToZipped(address zipped) private view {
		function () fwd = __forwardToZippedNonView;
		function () view vfwd;
		assembly ("memory-safe") { vfwd := fwd }
		vfwd();
	}

	function  __forwardToZippedNonView(address zipped) private {
		assembly ("memory-safe") {
			calldatacopy(0x00, 0x00, calldatasize())
			let s := delegatecall(gas(), zipped, 0x00, calldatasize(), 0x00, 0x00)
			returndatacopy(0x00, 0x00, returndatasize())
			if iszero(s) {
				revert(0x00, returndatasize())
			}
			return(0x00, returndatasize())
		}
	}

This is actually the trick used by wrapper contracts deployed by bytecode.zip.

I appreciate your help, thank you.
If I use my own function to generate the tokenURI, then I'm going to use it in the tokenURI function, does the visibility of my function have to match with the zipped contract?
Another question,
If I test the zipped contract with interface in the deploy script as like in the sample DeployZCall.s.sol and it works, does that mean I did everything right and my deployed zipped contract is working?

The answer is complicated due to how view is enforced in different calling contexts. When calling a view function from another contract, it will be enforced and any state-modifying operations (such as a self-extraction) will cause a revert. If, however, called directly by an EOA via eth_call (which is how tokenURI() is usually used), then the view modifier is ignored and will not be enforced.
I'm assuming you're trying to do something like this...?
interface IZIPPED {
    function tokenURI() external view returns (string memory);
}

contract ERC721 {
    function tokenURI() external view returns (string memory) {
        return IZIPPED.tokenURI();
    }
}

This will compile but revert because the view modifier on IZIPPED.tokenURI() will be enforced by the call inside ERC721.tokenURI(). If you drop view from just IZIPPED, it will not compile (unless you apply the assembly trick I mentioned earlier) because the compiler will not let you call a non-view function from a view function. If you drop view from both it will compile and succeed.
As for testing in the deployment in the deploy script, if you've inspected the output and it looks correct, then yes, it's probably fine. You could also use forge cast to call the deployed contract from the command line and inspect its results.

Or by visibility did you mean external vs public? You can mix those however you want.

Or by visibility did you mean external vs public? You can mix those however you want.

Yes, external vs public.
Sorry for misunderstanding. 😅
I've made a test function for easy testing that returns a string, but with cast it only returned a single 0x. :(
I'm trying not to send the exact source code due to NDA.
This is how my project looks like:
src/MyTokenGenerator.sol
...
contract MyTokenGenerator {
    ...
    function generateURI(
        string memory _previewBaseURI,
        uint256 _tokenId,
        bool _someCustomProperty
    ) external view returns (string memory) {
        return "Some generated base64 URI.";
    }
}

script/deploy.sol
...
import "zipped-contracts/script/ZDeployBase.sol";
import "../src/MyTokenGenerator.sol";

contract Deploy is ZDeployBase {
    function run() external {
        Z z = _getOrDeployZ();
        vm.broadcast(vm.envUint('DEPLOYER_KEY'));
        _zcallDeploy(
            type(MyTokenGenerator).creationCode
        , z);
    }

    function test() external view returns (string memory) {
        return "this is a test";
    }
}

.env
DEPLOYER_KEY=my_test_private_key

Then I deployed with this command:
forge script script/deploy.sol:Deploy --broadcast --rpc-url http://<IP_ADDRESS>:7545/

http://<IP_ADDRESS>:7545/ is my local Ganache test network.
Test with call:
cast call 0xdd1c00993f657db6ada0d5e41ea05e5e2ff550c0 "test()" --rpc-url http://<IP_ADDRESS>:7545/

and returned a single 0x
My other contract in a different repository:
...
contract MyContract is
    ERC721A,
    ...
{
    string private previewBaseURI = "...";
    address generatorContractAddress = ...;
    ...

    function tokenURI(uint256 tokenId)
        public
        view
        override
        returns (string memory)
    {
        // I'm going to call the `generateURI` function from the zipped contract and return it.
        return "...";
    }
}

Ahh, I think it's because it's on a local testnet so there won't be an instance of the shared (Z) runtime on it. _getOrDeployZ() does deploy the runtime if it doesn't exist but it isn't preceded by a vm.broadcast(), so it doesn't get permanently deployed to your local testnet.  You can try adding a vm.broadcast() before it or just use a single vm.startBroadcast() at the start of the function.

Thank you so much!
I'm calling it with the 'hack' above, but it didn't return the value that I expected.
With a little modification it works.
I replaced delegatecall to call method as like in the deployed wrapper example, now it works fine.
However, can I call it from another function?
Like this:
function generateJSONURI(string memory _previewBaseURI, uint256 _tokenId, bool _someProperty) public view returns (string memory) {
    __forwardToZipped();
}

function __forwardToZipped() private view {
    function () fwd = __forwardToZippedNonView;
    function () view vfwd;
    assembly ("memory-safe") { vfwd := fwd }
    vfwd();
}

function  __forwardToZippedNonView() private {
    address zipped = zippedContractAddress;
    assembly ("memory-safe") {
        calldatacopy(0x00, 0x00, calldatasize())
        let s := call(gas(), zipped, callvalue(), 0x00, calldatasize(), 0x00, 0x00)
        returndatacopy(0x00, 0x00, returndatasize())
        if iszero(s) {
            revert(0x00, returndatasize())
        }
        return(0x00, returndatasize())
    }
}

function tokenURI(uint256 tokenId)
    public
    view
    override
    returns (string memory)
{
    if (!_exists(tokenId)) revert URIQueryForNonexistentToken();
    ...
    return generateJSONURI(previewBaseURI, tokenId, someProperty);
}

Because there is an extra boolean property of the NFTs that the zipped contract doesn't know about, only when we tell it through the function.

You can try something like this (assuming the target function is also called generateJSON on the zipped contract):
function generateJSONURI(string memory _previewBaseURI, uint256 _tokenId, bool _someProperty) public view returns (string memory) {
    __forwardToZipped(abi.encodeCall(this.generateJSONURI, (_previewBaseURI, _tokenId, _someProperty)));
}

function __forwardToZipped(bytes memory callData) private view {
    function (bytes memory) fwd = __forwardToZippedNonView;
    function (bytes memory) view vfwd;
    assembly ("memory-safe") { vfwd := fwd }
    vfwd(callData);
}

function  __forwardToZippedNonView(bytes memory callData) private {
    address zipped = zippedContractAddress;
    assembly ("memory-safe") {
        let s := call(gas(), zipped, callvalue(), add(0x20, callData), mload(callData), 0x00, 0x00)
        returndatacopy(0x00, 0x00, returndatasize())
        if iszero(s) {
            revert(0x00, returndatasize())
        }
        return(0x00, returndatasize())
    }
}

function tokenURI(uint256 tokenId)
    public
    view
    override
    returns (string memory)
{
    if (!_exists(tokenId)) revert URIQueryForNonexistentToken();
    ...
    return generateJSONURI(previewBaseURI, tokenId, someProperty);
}

Thank you so much!
Finally it's working. :D


Updating CONTRIBUTING file with pypy tips.

As it turns out, both of our optional crypto dependencies have issues in pypy.
See it on https://github.com/dhermes/oauth2client/blob/add-pypy-note-to-contributing/CONTRIBUTING.md
@nathanielmanistaatgoogle I have two potential uneasy things here

Maybe this should go in README
Maybe it should be in its own section in CONTRIBUTING (rather than in "Running Tests")

My impression is that it should go in README - the content seems to be about running the software, and what's there applies whether the context of running the software is running the software's tests or doing something else with it. And all the information there is valid whether or not the reader intends to contribute patches or go live under a rock for the next century, so CONTRIBUTING definitely feels like the wrong place?

@nathanielmanistaatgoogle I put most of it in the docs and left a tiny reference in CONTRIBUTING since the pypy target will fail on too early a version of pypy. (Relevant to testing.)


Questions regarding annotation tool

Hi,
I attempted to run the demo with some additional images, but it appears that proper results are only generated when a file with image annotations is provided. Since your PGDP paper mentions your unique annotation method and the re-annotation of other datasets, could you please point me to the part of the code responsible for annotation?
Thank you very much for your assistance!

Hello, our annotation file only provides the OCR content of text because the PGDPNet  doesn't have the OCR ability. You could use OCR tools to generate bounding box and content of text, or leverage annotation  tools such as "labelme" and "labelimg" to label text content, then convert to the corresponding annotation format. I'm apologize that we have not built an end-to-end annotation tool yet.

I see. Your response is much appreciated.


Web browser glitch

Glitch stopping me from loading webpages or even searching for anything in Safari and Google chrome

Duplicate of #50 see issue for fix.


Segmented MP4 issues

Hello,
This is quite an interesting project! I did get it to work with the included test file, however it did not completely work for a segmented mp4 that was merged into a single file then tested with testall.sh.
Is this because each chunk/segment needs to be separately ran through the project then merged together? I was getting lots of errors related to duplicate and unexpected frame matches.
When the output finished and I tested the file with mpv, I was able to play the first two minutes without issues, then the file unexpectedly closes on its own. I would assume this is where the next chunk begins?
Any suggestions would be welcome.

How did you merge the segments?

Thanks for the quick reply! Here is a link to the merge function I am using, its pretty bare bones aside from changing the trailing byte to \x01 in the tfhd box.
https://privatebin.net/?799dc43999a48015#6vmsv4zUrNfzYmSzt7gtoQMTNtjvCPi9xym5CnSRSv9n

I'm thinking it might just be better to try MP4Box or Bento4 to merge the fMP4's...

@DavidBuchanan314 After double checking some stuff, this media file was actually downloaded in one piece, NOT segmented. I thought the errors were related to merging the segments but its apparently not so.
I am currently running testall again and its still spitting out similar errors so I am not sure whats going on.

testall.sh will only work if the encryption key matches the one here https://github.com/DavidBuchanan314/DeCENC/blob/6b447b4b331545cc15352963030c3379050ea7ef/testall.sh#L31
If you're testing with a different key you'll need to change it there

testall.sh will only work if the encryption key matches the one here
https://github.com/DavidBuchanan314/DeCENC/blob/6b447b4b331545cc15352963030c3379050ea7ef/testall.sh#L31
If you're testing with a different key you'll need to change it there

Wait I am confused; I thought this can decrypt without knowledge of the key? If I decrypt it using mp4decrypt and the key I have it works of course, but shouldn't DeCENC be able to decrypt without knowledge of the key?
I shot you a message on discord as that would be a bit more convenient than this if you'd be so inclined.

testall.sh is just an artificial test, you'd need to use a modified variation of the "open loop" procedure if you want to test against a real CDM provisioned with real keys


Question about mutating props

What problem does this feature solve?
One of the provided examples mutates its props.
https://github.com/vuejs/vue-next/blob/0ea14cade9bffa1af6c7af3f8a68b528665c66f6/packages/vue/examples/composition/tree.html#L54
In comparison to this, the Vue 2 Tree View example does not mutate its props directly. Has the recommendation regarding that changed or is this just to keep the example simple? If it's the latter, what would be a clean  way of doing so?
What does the proposed API look like?

The recommendation hasn't changed.
I think the example you should compare it to is at https://github.com/vuejs/vue/blob/dev/examples/tree/tree.js

The example was actually trying to reproduce exact the same logic, mostly to serve as an e2e test for backwards behavior compatibility. You should still avoid doing this in actual code. We should probably update the example to remove that usage though.


core(controls): Remove image controls

Overview
Remove image-adaptor-related controls from the AllControls/ArmoBest frameworks

@YiscahLevySilas1 @alegrey91 ?


Perf tests should not have dependency to api-gateway nor function

Description
Istio being core component should NOT have dependency to any other kyma components (api-gateway, functions). It should not be required to install any other components to execute performance test (or any other tests). It should be possible to execute perf tests (or any other int tests) on upcoming Istio version to see results before releasing Istio module. authn/authz should not be tested in this perf tests (that might be tested in api-gateway in future). Remove dependency to api-gateway and functions from perf test. Remove any unused resources. Remove dependency to oauth2client from ORY Hydra.
ACs:

[ ] tests can be executed on a cluster with Istio (no dependency to any other kyma components)
[ ] there are no unused resources in tests
[ ] clear documentation on what is tested
[ ] httpbin exposed via VS only

existing implementation can be moved to api-gateway


Max password length

Hello,
Since I use a password manager to generate unique passwords, I tend to go a little long on the password length front.
When the password was set to 32 characters (assuming symbols, numbers, upper/lower case is all permitted) the log-in flow would display an error "invalid login details", or similar response.
My first thought was that it could be due to symbols not being handled properly. This didnt fix it. However, shrinking my password down to 24 characters, the log-in flow worked.
Is this a bug that can be fixed, or guidance added to the install guide?
(as a side note, the ac infinity android app doesnt support wifi passwords above a certain length either)

It looks like the android/ios app is truncating passwords down to 25 characters.  Sending the full password to their API results in a 400 error, but after removing characters from the end until it reaches 25 characters... it lets you log in. 🤮 As gross as this is, I can update the login function to do the same.
I also like make long random passwords, though I usually stop at 24 characters as that seems to be the average max password length for a lot of applications.  Any longer, and I would have run into this disgusting issue myself . 🥲

Yuck.
In times like these it makes me hope they're not storing passwords in plain text.
Alternatively, could you relay a different error message back to the user when passwords exceed 25 char? Rather than hack it into shape.
E.g. "AC Infinity does not store passwords longer than 25 characters. Please check with their website and reduce length accordingly".
M

This should be fixed in 1.4.1.  Thanks for the report!


Allow use of codicons in custom views

Related to #84695 & #85579

Duplicate of https://github.com/microsoft/vscode/issues/84695


make build fails on fresh env

https://github.com/netobserv/network-observability-cli/blob/ab18a4b3caea4c79370dd2ded15b79e55de151b1/Makefile#L73
this step fails on envs that doesnt have go.tmz.dev/musttag in their local cache
$ make build
which: no podman in (/home/yuval/.local/bin:/home/yuval/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)
basename: missing operand
Try 'basename --help' for more information.
### Formatting code
go fmt ./...
### Test if prerequisites are met, and installing missing dependencies
GOFLAGS="" go install<EMAIL_ADDRESS>go: downloading go.tmz.dev/musttag v0.7.2
/home/yuval/go/pkg/mod/github.com/golangci/golangci-lint@v1.54.2/pkg/golinters/musttag.go:4:2: unrecognized import path "go.tmz.dev/musttag": parse https://go.tmz.dev/musttag?go-get=1: no go-import meta tags ()
make: *** [Makefile:73: prereqs] Error 1

I'm using
$ go version
go version go1.21.8 linux/amd64

on a new vm (so nothing in my caches yet)

Trying to reproduce, cleaning up & removing my "~/go/pkg/mod/github.com/golangci" and "go/pkg/mod/go.tmz.dev", but it worked for me, everything seem downloaded again as expected (I tried with go 1.21.7)
Also on CI (which also starts with a fresh new env) this is working, example: https://github.com/netobserv/network-observability-cli/actions/runs/8433720228/job/23095366225#step:5:8
Can you post your go env so we can check if something differs?


git graph often crash when using vscode-insiders

Does this issue occur when all extensions are disabled?: Yes/No

版本: 1.64.0-insider (system setup)
提交: 807bf598bea406dcb272a9fced54697986e87768
日期: 2021-12-20T07:18:13.749Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.22523
名称: Git Graph
ID: mhutchie.git-graph
说明: View a Git Graph of your repository, and perform Git actions from the graph.
版本: 1.30.0
发布者: mhutchie
VS Marketplace 链接: https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph
Steps to Reproduce:

open git graph
I don't know but It often crash

vscode stable works fine

/causedByExtension
Please report to extension author in the first instance. If they think it is a 1.64 issue they should open an issue here with technical details.


OBHR to NBHR if not yet upgrade but app got updated there are some cases

if we have requested to older version to accept request for new health

-Verified this issue on staging app v1.6.0(277)


fix the traffic light problem in React - Medium

Pull Request Type
What kind of change does this PR introduce?
[x] Solved an issue/task
[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:
What is the current behavior?
Issue Number: #1532
What is the new behavior?
create a component that displays a traffic light.
Other information

Merged

This is an automated message from Fork, Commit, Merge [BOT].

Thank you for your contribution! Your pull request has been merged. The files have been reset for the next contributor.
What's next?
If you're looking for more ways to contribute, I invite you to check out our forkcommitmerge.io website repository. The repository contain real issues that you can help to resolve or create some of your own if you see any bugs or want to add new features to the site, etc. You can also check out the Influences section in the README to find more projects similar to this one.
Also please leave a star to this project if you feel it helped you, i would really appreciate it.
I look forward to seeing your contributions!


upgrade-provider uses go version 1.21.x even 1.22 is specified

https://github.com/equinix/pulumi-equinix/pull/190/files
the toolchain reflected in the examples says toolchain go1.21.13 but it should be 1.22.3
I guess it's due to a cached version

It could probably be fixed adding cache: false to the setup-go action

https://github.com/actions/setup-go/issues/457


Add Quarto slides for team culture / psych. safety lesson

I worked on that here for quick iteration: https://mfisher87.github.io/presentation-nasa-openscapes-team-culture/
The plan is to put the slides here and title them team-culture-slides.md, and link to both the Quarto version and the original from team-culture.md.
I also have a learn-more.md file in my repo. I wanted it to be a slide, but there was too much stuff. So it became a dedicated page: https://mfisher87.github.io/presentation-nasa-openscapes-team-culture/learn-more.html
Thoughts on how to organize this content?

We appreciate everything you’ve done for this! How about we link to your slides under the "Additional slides and recordings" section as we did for your video? Then your files can stay in your repo without having to move them.

I'm cool with that, but thought it might be more useful to Openscapes to have one place to contribute to the lessons, including the slide decks. What do you think? I'm happy to open a PR :)

Hi Matt,
Sounds good, please open a PR. Would you make a subfolder called "slides" in https://github.com/Openscapes/series/tree/main/core-lessons? We don't yet use Quarto Slides in this book so this can be a start to organizing them. Thanks!

Right on, will do!

Matt & Stef met Jun 17
notes in pull request thread


no video when application is not in foreground

when application is not in foreground video call started without video for that user. Sound is working fine.
if exist a way to bring application to foreground?

Thank you for reporting this issue! To address the video not starting when the app is in the background:

Use Picture-in-Picture (PiP) Mode: The Azure Communication Services UI Library supports PiP on Android, enabling video calls to remain visible when the app is not in the foreground. Learn more here.

Other Options:

On Android, you can use callComposite.bringToForeground(context) to programmatically bring the app to the foreground.
On iOS, you can check if the app is hidden with callComposite.isHidden and take appropriate action.
Let me know if further assistance is needed!

@ahammer
I added callComposite.\bbringToForeground(context) inside of joinCall in Composite.cs before callComposite.Launch
still same problem - also I see toast message - unable to start camera

Hi,
From your logs, the main issue is:
An error occurred while connecting to camera 1: Status(-8, EX_SERVICE_SPECIFIC): '6: connectHelper:2498: Camera "1" disabled by policy'
This indicates that Android's security policies are preventing the camera from starting when the screen is off or the app isn't in the foreground. Unfortunately, starting a call without user interaction isn't supported by the call composite due to these restrictions.
Let me know if there's anything else I can assist with.

Hi
sorry I did not understand your statement "starting a call without user interaction isn't supported by the call composite due to these restrictions"
The default behavior that when call come in - phone application is automatically go to foreground - why you can not make same with video call?

Hi @vovanb,
Thanks for bringing this important detail up:

Important to add that screen of Android phone is off.

Currently call composite is not presenting self on the screen when phone is locked. This feature will be added in the next release.
Thanks


chore: Put LDK-related data into $DATA_DIR/ldk

Having a subdirectory will make our seed file stand out more
(and all LDK stuff will be together).

bors r+


Adds constellation templates

What this PR solves / how to test:
This PR adds constellation code templates.
Associated docs issue(s)/PR(s):
The code templates include README.md files.

hi @celso :) it looks like one of the checks is failing, would you be able to address this? i think you may need to run npm run prettify

Hi @celso, I'm trying to run the text-processing example locally and I'm getting 500s back from all of the endpoints. I'm assuming there is a necessary step of uploading the models used to constellation. Can I ask how the models are named / what are the steps for that?
Hope you don't mind me asking on your PR


armv7 linux (raspberry pi) releases

Vscode remote is supporting armv7 in their nightlies
https://www.hanselman.com/blog/VisualStudioCodeRemoteDevelopmentOverSSHToARaspberryPiIsButter.aspx
When trying to debug though I get
"Acquiring platform package for CodeLLDB" and then "Error: Current platform is not supported"
Any thoughts on supporting?

Doable, but not in my immediate plans.    I kinda expect people to cross-compile for arm32 targets from another machine, in which case they can use remote debugging.

Ive certainly done that too for the faster builds, but the remote development is also really nice.

I'm also looking for this feature!

Added armv7 support in 1.4.1


train content type

During training of a model, the content type mentioned should be application/json. other types during the training will result in 415 error. there is also a missing statement in regards to the total size of the documents for training, it needs to be <4MB

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 18818774-5076-cb76-ee9e-4ecb632b6caa
Version Independent ID: 22d60153-50fc-024e-6249-edc796dcdf19
Content: Quickstart: Train a model and extract form data by using the REST API with Python - Form Recognizer - Azure Cognitive Services
Content Source: articles/cognitive-services/form-recognizer/quickstarts/python-train-extract.md
Service: cognitive-services
Sub-service: form-recognizer
GitHub Login: @PatrickFarley
Microsoft Alias: pafarley

@yodobrin Thank you for your feedback! We will review and provide an update as appropriate.

@yodobrin Hi Yoav, thank you for your feedback. I have add the statement for the total size, "content-type" is already stated as application/json in the sample. You should see the change after it has been approved.

@yodobrin
We will now proceed to close this thread. If there are further questions regarding this matter, please respond here and @YutongTie-MSFT and we will gladly continue the discussion.


[Question] Mocking express $Request

Couple of more generic questions first:

Do you annotate your unit test files with flow as well as source files?
How do you handle mocks when the actual implementation type is fairly extensive?

Take this example:
// parseCookieInformation.js
import type { $Request } from expess;
export default function parseCookieInformation(req: $Request) => req.cookies;

//parseCookieInformation.test.js
import parseCookieInformation from './parseCookieInformation';

decribe(() =>{
  it(() => {
    expect(parseCookieInformation({ cookies: { foo: 'bar' }}).foo).toEqual('bar');
  });
});

Obviously this will throw a flow error, because the passed object is not a $Request. It's really convoluted to create an entire express request object if at all possible (I haven't found a constructor for it).
What is a best practice here? One solution would be to modify the underlying function by not requiring an entire request object, just what it needs, but I don't think that's a real solution. parseCookieInformation may call other functions that actually use other fields in the request object, but they might be mocked out in this test file.
I feel like the nature of mocks just doesn't really sit well with flow.

You can try https://github.com/lykmapipo/mock-express-request and write a libdef for it using $Request type from express.

That's what I ended up doing. I'm not happy about it, but it works. Thanks!


merge from arlac77/template-arlac77-github,arlac77/template-esm-only

.travis.yml

chore(travis): (jobs.include)
chore(travis): add 14.2.0 remove 14.1.0 (jobs.include.node_js)

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Cloudflare DNS verification - credential information missing

lego dnshelp recommends the following command to use dns verification:
<EMAIL_ADDRESS>\
CLOUDFLARE_API_KEY=b9841238feb177a84330febba8a83208921177bffe733 \
lego --dns cloudflare --domains www.example.com --email<EMAIL_ADDRESS>run

However, when I run that (with the appropriate values), I get the following error:
cloudflare: some credentials information are missing: CLOUDFLARE_EMAIL,CLOUDFLARE_API_KEY
Cloudflare is the DNS provider I am using. What am I doing wrong?

I checked the command and it works for me:
$<EMAIL_ADDRESS>\
CLOUDFLARE_API_KEY=b9841238feb177a84330febba8a83208921177bffe733 \
lego --dns cloudflare --domains www.example.com --email<EMAIL_ADDRESS>run

2019/02/06 02:39:58 No key found for account<EMAIL_ADDRESS>Generating a curve P384 EC key.
2019/02/06 02:39:58 Saved key to ~/.lego/accounts/acme-v02.api.letsencrypt.org/me<EMAIL_ADDRESS>2019/02/06 02:39:58 Please review the TOS at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
Do you accept the TOS? Y/n
y
2019/02/06 02:40:00 [INFO] acme: Registering account for<EMAIL_ADDRESS>!!!! HEADS UP !!!!

                Your account credentials have been saved in your Let's Encrypt
                configuration directory at "~.lego/accounts".
                You should make a secure backup of this folder now. This
                configuration directory will also contain certificates and
                private keys obtained from Let's Encrypt so making regular
                backups of this folder is ideal.2019/02/06 02:40:01 [INFO] [www.example.com] acme: Obtaining bundled SAN certificate
2019/02/06 02:40:02 [INFO] [www.example.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/JcDVNcyD7dDPnTPDSzka14i8umTk8W8XfV9Ixi3ac-Q
2019/02/06 02:40:02 [INFO] [www.example.com] acme: Could not find solver for: tls-alpn-01
2019/02/06 02:40:02 [INFO] [www.example.com] acme: Could not find solver for: http-01
2019/02/06 02:40:02 [INFO] [www.example.com] acme: use dns-01 solver
2019/02/06 02:40:02 [INFO] [www.example.com] acme: Preparing to solve DNS-01
2019/02/06 02:40:03 [INFO] [www.example.com] acme: Cleaning DNS-01 challenge
2019/02/06 02:40:04 [WARN] [www.example.com] acme: error cleaning up: cloudflare: failed to find zone example.com.: ListZones command failed: error from makeRequest: HTTP status 403: insufficient permissions
2019/02/06 02:40:04 Could not obtain certificates:
        acme: Error -> One or more domains had a problem:
[www.example.com] [www.example.com] acme: error presenting token: cloudflare: failed to find zone example.com.: ListZones command failed: error from makeRequest: HTTP status 403: insufficient permissions

Strange. I even tried putting it in a script and executing it that way, but I still get the same error.

In a script you have to export the vars:
#!/usr/bin/env sh

export<EMAIL_ADDRESS>export CLOUDFLARE_API_KEY=b9841238feb177a84330febba8a83208921177bffe733

lego --dns cloudflare --domains www.example.com --email<EMAIL_ADDRESS>run

Yeah, this doesn't make sense to me. I tried both, I get the same result for each. cloudflare: some credentials information are missing: CLOUDFLARE_EMAIL,CLOUDFLARE_API_KEY

Have you tried to simply copy/paste my samples?

@andyforceno any news?

Have you tried to simply copy/paste my samples? (with the fake email, key, etc. without changing anything)

This worked in that I no longer get the error I was seeing. Now I'm getting a new error, but after the dns validation attempt. I'll do some research on that (maybe this won't work with .tech domains...). This issue is resolved, thanks.


only update range when the source has the attribute

The variable range in parser is initialized to full set, however, no matter the source defines the range or not, the variable will be assigned to range [Lower, Upper). Since Lower and Upper are initialized to 0, if source does not define range, the range will be assigned to [0, 0), which is the empty set.
This patch forces it to change the range only when the range is defined in the source file.

thanks!


Watch compiles only first time

I have an issue with watch. The first time i change a file webpack emits the compiled files, but next time i change them nothing hapens. The callback is not called. It's as if webpack.watch only runs the compilation, but doesn't watch the files any more.
Here is my configuration:
https://gist.github.com/jacek-dargiel/59a559c1fb6888727659
What am I doing wrong?

@jacek-dargiel Please use gulp.watch instead of gulp-watch.

Replacing gulp-watch with the standard gulp.watch doesn't help. I don't think that's the source of the problem. gulp-watch detects the first change, and detects the subsequent changes, it's webpack.watch that doesn't fire its callback.

@jacek-dargiel I have tested with gulp-watch and it didn't work correctly, but it works fine with gulp.watch.
It is very difficult to reproduce your issue without working example. Could you please fork the repo and create an example under test/fixtures which reproduces your issue.

Sorry, it's taking longer than I thought, because I have python 3.3

Ok, here's my fork with the fixture:
https://github.com/jacek-dargiel/gulp-webpack-build/tree/master/test/fixtures/watch-once
Now, I have dug deeper into the problem, and noticed that I was requiring a file with a different case filename - require('./module1.js'), while the actual file was Module1.js. I would expect webpack to throw some kind of error that it can't find ./module1.js, but instead it uses Module1.js in the first build, and then ignores subsequent changes to that file.
BTW, I'm running Windows 8.1 - that may make a difference, as windows file names are case insensitive AFAIR.
Do you want a PR with this fixture?

Closing this, as this is an issue with webpack, not the gulp plugin. https://github.com/webpack/webpack/issues/944


preloader-exception-handling

Current coverage is 64.24%

Merging #174 into master will increase coverage by +1.27% as of 3e7d19c

@@            master    #174   diff @@
======================================
  Files           40      40
  Stmts         2752    2755     +3
  Branches       318     318
  Methods          0       0
======================================
+ Hit           1733    1770    +37
  Partial         58      58
+ Missed         961     927    -34

Review entire Coverage Diff as of 3e7d19c

Powered by Codecov. Updated on successful CI builds.

:+1:


[Event Requet] Codeunit 6500 "Item Tracking Management" - OnBeforeExitFindInInventory

Describe the request
I need to customize the filters in procedure FindInInventory, therefore, I request the following event:
procedure FindInInventory(ItemNo: Code[20]; VariantCode: Code[20]; SerialNo: Code[50]): Boolean
var
ItemLedgerEntry: Record "Item Ledger Entry";
begin
ItemLedgerEntry.SetCurrentKey("Serial No.", "Item No.", Open, "Variant Code", Positive);
ItemLedgerEntry.SetRange("Item No.", ItemNo);
ItemLedgerEntry.SetRange(Open, true);
ItemLedgerEntry.SetRange("Variant Code", VariantCode);
ItemLedgerEntry.SetRange(Positive, true);
if SerialNo <> '' then
ItemLedgerEntry.SetRange("Serial No.", SerialNo);
    OnBeforeExitFindInInventory(ItemLedgerEntry);
    exit(not ItemLedgerEntry.IsEmpty());
end;

[IntegrationEvent(false, false)]
local procedure OnBeforeExitFindInInventory(var ItemLedgerEntry: Record "Item Ledger Entry");
begin
end;
Additional context
This is needed to ensure a unique serial no. across all inventory instead of per item.
The modification was done for a customer in Navision 2018 and he is now migrating to BC
We need to remove the filter on the Item No. and Variant Code fields
Internal work item: AB#545886

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 23666.


Move X_TREE_NODE_PREFIXES into TreeBuilder and cleanup.

Out of curiosity, are the actual key contents important at all?  Are there callers looking for specific strings? i.e. does it matter that a Vm is represented as "v"?  Could we switch it to something else, like "vm", without affecting the callers?

@Fryguy : unlikely :-( We cannot be sure that we do not rely upon the values of the keys in some other place. Said in another way: we are not consistent with the usage of the keys.
My reasons for this change is

to add more consistency (by using a method rather than accessing a constant/constants) and
to have less places to modify when adding a new tree/accordion
stop using UiConstants as a place to dump whatever

Oh don't get me wrong, I think this change is great, especially for all of your points.  I was just thinking ahead and wondering if we can autogenerate the key names, so someone doesn't have to hardcode a new one every time we add something.

I am good with this change :+1:

Testing in the UI, seems to be working well.


Disallow epsilon = 0, and try to catch NaNs earlier

@jeff-regier What do you think of these? Does the check on epsilon seem reasonable? Is this a good place to check it? Are the asserts going to be too much of a performance hit? I'm not sure if Julia optimizes out asserts under certain conditions or what...I can research it.

@gostevehoward -- This code looks useful for debugging, but I don't think we should include it in master.
First, epsilon=0 shouldn't be a problem for the code, because that just means there's no background noise---an easy case, not a bad one. If it is, a problem, we should fix that rather than check for it. (Does epsilon show up in a log term something?)
There should never be NaNs (or Infs for that matter) in the elbo. We should always throw an exception right away in cases where either is inevitable, though I wouldn't expect either to be inevitable except in the case of pathological data. Ideally we'd through an exception for pathological data when we load the data, not once we're processing it unsuccessfully. Also, as you suspected, adding anything to those functions in elbo.jl is likely a bad performance hit.
I'm making some revisions to the Transform module now, that may catch some inevitable numerical issues at the right places. Also, I got the optimizer to be more robust to poorly conditioned hessians in a my recent PR: JuliaOpt/Optim.jl/#284  I don't think a release with this change is tagged yet, but you could try Pkg.checkout("Optim", "master").

@jeff-regier
Regarding epsilon=0: what happens is that in my test images, which (in simple cases) are dark except for a small, bright source at the middle, the expected intensity E_G.v[1] for certain pixels gets driven towards zero. This eventually causes a blowup: currently, the breaking point seems to be dividing by E_G.v[1]^4, which causes an Inf in combine_hess, which propagates into a NaN in elbo_log_term.h (though I'm pretty sure the version I was working with on Sunday was breaking elsewhere, but the specific breaking point isn't really important, because there are many possible ones). When epsilon > 0, this is prevented from happening.
Regarding assertions: I'm sure you guys already have opinions on this, so let me lay out my philosophy to make sure we're on the same page:
I think of assertions as being used to check conditions that should always be true in the code unless there is a bug in the code itself. Assertion failure => there is definitely a bug in our code. (You already have tons of assertions like this so I'm assuming you already take this approach too.) So checking for NaNs/Infs seems like a perfect use for assertions: it should never happen, but it will, because inevitably the code will have bugs from time to time (be they bugs in the optimization routine or bugs in the input validation), and when it does, we do want the whole program to crash ASAP, and assertions will save developers many hours of tracking down root causes.
Input validation, or error handling more generally, is a completely different beast, something we do expect to happen in bug-free code when the user passes invalid input. In this case we raise an exception the user can handle however she chooses. Like you said, ideally we'd catch every possible input problem up front in validation, but inevitably there will be corner cases we miss, hence the assertions.
All of this is to say, I think the fact that we should catch the root causes in input validation doesn't mean we shouldn't also assert on key symptoms down the road. What is important is that an assertion firing means someone has to fix the code in some way, it doesn't just mean we change our inputs and move on.
Regarding performance: I was hoping Julia might do something like the old-fashioned C #assert, which would get compiled out on gcc -O and have zero performance impact. I did a little benchmark and Julia does not do that right now, even with julia -O3. However, there are options: we could define a global const DEBUG = false, and

If you write a function ala
@inline function my_debug_check()
  if DEBUG
    # do expensive checks
  end
end

then it seems to have zero performance impact when DEBUG == false. (I found I did have to specify @inline, even when the check function was quite simple.)

Or, if you're down with macros, a nicer option is along the lines of
macro my_assert(ex)
  if DEBUG
    return :( $ex ? nothing : throw(AssertionError($(string(ex)))) )
  else
    return :( nothing )
  end
end

Obviously we could define different debug levels to trade of granularity of assertions and performance.
Now there is still the issue of all these assertions making the code ugly and harder to read, which is fair, but I think if used judiciously they could add a lot of value, especially for common failure modes. I got the impression from Ryan that this failure mode isn't uncommon.
If you're curious, here's the script I was using to play with assertion performance:
const DEBUG = true

function fill_fibonacci!(array)
    array[1] = array[2] = 1
    for i in 3:length(array)
        array[i] = array[i-1] + array[i-2]
    end
end

macro my_assert(ex)
    if DEBUG
        return :( $ex ? nothing : throw(AssertionError($(string(ex)))) )
    else
        return :( nothing )
    end
end

function check_valid_fibonacci(array, max_index)
    for i in 3:max_index
        if array[i] != array[i-1] + array[i-2]
            return false
        end
    end
    return true
end

@inline function assert_valid_fibonacci(array, max_index)
    if DEBUG
        @assert check_valid_fibonacci(array, max_index)
    end
end

function fill_fibonacci_with_assertions!(array)
    array[1] = array[2] = 1
    for i in 3:length(array)
        array[i] = array[i-1] + array[i-2]
        assert_valid_fibonacci(array, i)
        #@my_assert check_valid_fibonacci(array, i)
    end
end

function main(size)
    values = fill(0, size)

    fill_fibonacci!(values)
    @time fill_fibonacci!(values)

    fill_fibonacci_with_assertions!(values)
    @time fill_fibonacci_with_assertions!(values)
end

main(1000000)

Also, I realized my own input validation (on epsilon) in this patch is using an @assert, and ought to throw some other kind of exception, according to my own advice :). I will make that change if we keep it.

@jeff-regier https://github.com/jeff-regier
Regarding epsilon=0: what happens is that in my test images, which (in
simple cases) are dark except for a small, bright source at the middle, the
expected intensity E_G.v[1] for certain pixels gets driven towards zero.
This eventually causes a blowup: currently, the breaking point seems to be dividing
by E_G.v[1]^4
https://github.com/jeff-regier/Celeste.jl/blob/master/src/deterministic_vi/elbo.jl#L783,
which causes an Inf in combine_hess, which propagates into a NaN in
elbo_log_term.h (though I'm pretty sure the version I was working with on
Sunday was breaking elsewhere, but the specific breaking point isn't really
important, because there are many possible ones). When epsilon > 0, this is prevented
from happening
https://github.com/jeff-regier/Celeste.jl/blob/master/src/deterministic_vi/elbo.jl#L741
.

That's interesting.  Ultimately, this is a failure of the poisson
approximation, which I continue to say we should really get rid of.  Our
model should not break if we evaluate it with a low expected intensity
where there is in fact light, we should just return a very low objective
function.  Unfortunately, this means passing around variance estimates,
which would increase the size of the image data structure quite a lot.
That's not a good idea right now before IPDPS, but I have it on my roadmap.
(Many other unrelated benefits will accrue from switching to a normal
model.)
In the meantime, epsilon being zero is not the problem, the model is the
problem.  I do not think we should make an assert that is only there to
prevent unrelated numerical pathologies in the model.  I like the idea of
failing before the NaN gets passed to Optim, but I don't think asserting
that epsilon be greater than zero is the right fix.  (If you have this
problem, you should get a NaN, and increase epsilon if you think that's the
right way to hack around the model's shortcomings in your particular case.)

Regarding assertions: I'm sure you guys already have opinions on this, so
let me lay out my philosophy to make sure we're on the same page:

I for one am totally on board with all of this, including a global DEBUG
boolean and a debug_assert macro (or something like that).

I think of assertions as being used to check conditions that should always
be true in the code unless there is a bug in the code itself. Assertion
failure => there is definitely a bug in our code. (You already have tons of
assertions like this so I'm assuming you already take this approach too.)
So checking for NaNs/Infs seems like a perfect use for assertions: it
should never happen, but it will, because inevitably the code will have
bugs from time to time (be they bugs in the optimization routine or bugs in
the input validation), and when it does, we do want the whole program
to crash ASAP, and assertions will save developers many hours of tracking
down root causes.
Input validation, or error handling more generally, is a completely
different beast, something we do expect to happen in bug-free code when the
user passes invalid input. In this case we raise an exception the user can
handle however she chooses. Like you said, ideally we'd catch every
possible input problem up front in validation, but inevitably there will be
corner cases we miss, hence the assertions.
All of this is to say, I think the fact that we should catch the root
causes in input validation doesn't mean we shouldn't also assert on key
symptoms down the road. What is important is that an assertion firing means
someone has to fix the code in some way, it doesn't just mean we change our
inputs and move on.
Regarding performance: I was hoping Julia might do something like the
old-fashioned C #assert, which would get compiled out on gcc -O and have
zero performance impact. I did a little benchmark and Julia does not do
that right now, even with julia -O3. However, there are options: we could
define a global const DEBUG = false, and

If you write a function ala
@inline function my_debug_check()
if DEBUG
# do expensive checks
endend
then it seems to have zero performance impact when DEBUG == false. (I
found I did have to specify @inline, even when the check function was
quite simple.)
Or, if you're down with macros, a nicer option is along the lines of
macro my_assert(ex)
if DEBUG
return :( $ex ? nothing : throw(AssertionError($(string(ex)))) )
else
return :( nothing )
endend
Obviously we could define different debug levels to trade of granularity
of assertions and performance.
Now there is still the issue of all these assertions making the code ugly
and harder to read, which is fair, but I think if used judiciously they
could add a lot of value, especially for common failure modes. I got the
impression from Ryan that this failure mode isn't uncommon.
If you're curious, here's the script I was using to play with assertion
performance:
const DEBUG = true
function fill_fibonacci!(array)
array[1] = array[2] = 1
for i in 3:length(array)
array[i] = array[i-1] + array[i-2]
endend
macro my_assert(ex)
if DEBUG
return :( $ex ? nothing : throw(AssertionError($(string(ex)))) )
else
return :( nothing )
endend
function check_valid_fibonacci(array, max_index)
for i in 3:max_index
if array[i] != array[i-1] + array[i-2]
return false
end
end
return trueend
@inline function assert_valid_fibonacci(array, max_index)
if DEBUG
@assert check_valid_fibonacci(array, max_index)
endend
function fill_fibonacci_with_assertions!(array)
array[1] = array[2] = 1
for i in 3:length(array)
array[i] = array[i-1] + array[i-2]
assert_valid_fibonacci(array, i)
#@my_assert check_valid_fibonacci(array, i)
endend
function main(size)
values = fill(0, size)
fill_fibonacci!(values)
@time fill_fibonacci!(values)

fill_fibonacci_with_assertions!(values)
@time fill_fibonacci_with_assertions!(values)end

main(1000000)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jeff-regier/Celeste.jl/pull/315#issuecomment-250046247,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AESWPjiKjlFCbafHNDC63BpcmDuivVCEks5qucBugaJpZM4KGDHZ
.

@rgiordan
Are you pretty sure it's essential we divide by E_G.v[1], or can we reorder the computations to avoid this? (I'm not sure either way, just asking here.) Does the true Hessian have, in the limit, infinite entries as the rate parameter goes to 0? If that's the case, reordering won't help, but if otherwise there should be a work around.
Regardless, there's always a non-zero change that a photon will land in a pixel, so I don't think it's a huge problem with the model if we require epsilon > 0. Not that there aren't other reasons from switching from a Poisson to a Gaussian model.

@gostevehoward
I agree with your views on assertions: when used carefully, in places where they reveal problems much earlier, they're well worth it, even though they add clutter to the code. The epsilon check in the PR makes sense in light of that, well, as an exception rather than assertion, because it's a problem with the input rather than the code.
If you'd move the call to assert_all_finite(elbo_vars.elbo) to just after the loop over pixels, rather than calling it within the loop, I don't think we'd need to worry about performance. (Generally the loops over pixels are the hotspots.) Would that provide feedback early enough about the problem? The debug macro is a decent solution too, but it might be worth hearing about a problem slightly later in order to avoid introducing yet another flag.
I'd rather fix the code than add assertions of course, but maybe that's not the choice. I don't think these NaNs have to be constant problem, or even a problem that keeps reappearing as the code changes. Please go ahead merge this PR whenever you're happy with it.

The term in the Hessian in question has the form Var(G) / E[G] ^ 4.  Here, G is modeled as a lognormal.  The lognormal's variance is proportional to the mean squared.  So yes, our parameterization allows this term to go to infinity.
This seems to make some intuitive sense to me.  We are approximating the distribution observed pixels with a Poisson distribution whose variance is the same as its mean.  Its mean cannot be driven to zero without any non-zero observation having zero probability (and associated extreme curvature in any direction that makes it nonzero).  But we don't really believe this, and there are basically two ways to resolve it:

Say no observation is truly zero (keep epsilon > 0)
Say our model never truly has zero variance (use a normal rather than a Poisson model, or otherwise add "dark variance")

It's not obvious to me that Celeste cannot work with epsilon == 0, only that in some cases you get numerical problems with a poorly modeled object when it is.  (Please correct me if I'm mistaken.)  As such, I would not want to enforce epsilon == 0 in the code but rather let the user set it to something other than zero to improve misfits.  But if that's a minority opinion I'll defer to you guys.

Steve and I just talked. Another problem we thought of is that if the
Poisson rate parameter is 0, but some x_nbm > 0 (e.g. 1 photon), then the
model log probability is negative infinity. So I think we're leaning
towards requiring epsilon > 0 (or better yet, for numerical stability,
epsilon > 1e-4). That condition is sufficient (but not necessary, as you
note) to keep the elbo well defined.
On Wed, Sep 28, 2016 at 10:15 AM Ryan<EMAIL_ADDRESS>wrote:

The term in the Hessian in question has the form Var(G) / E[G] ^ 4. Here,
G is modeled as a lognormal. The lognormal's variance is proportional to
the mean squared. So yes, our parameterization allows this term to go to
infinity.
This seems to make some intuitive sense to me. We are approximating the
distribution observed pixels with a Poisson distribution whose variance is
the same as its mean. Its mean cannot be driven to zero without any
non-zero observation having zero probability (and associated extreme
curvature in any direction that makes it nonzero). But we don't really
believe this, and there are basically two ways to resolve it:

Say no observation is truly zero (keep epsilon > 0)
Say our model never truly has zero variance (use a normal rather
than a Poisson model, or otherwise add "dark variance")

It's not obvious to me that Celeste cannot work with epsilon == 0, only
that in some cases you get numerical problems with a poorly modeled object
when it is. (Please correct me if I'm mistaken.) As such, I would not want
to enforce epsilon == 0 in the code but rather let the user set it to
something other than zero to improve misfits. But if that's a minority
opinion I'll defer to you guys.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jeff-regier/Celeste.jl/pull/315#issuecomment-250233904,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIieC1_oYOO3oTKEr5GL2pEIraRBvZR1ks5quqC5gaJpZM4KGDHZ
.

On Wed, Sep 28, 2016 at 10:43 AM, Jeffrey Regier<EMAIL_ADDRESS>wrote:

Steve and I just talked. Another problem we thought of is that if the
Poisson rate parameter is 0, but some x_nbm > 0 (e.g. 1 photon), then the
model log probability is negative infinity.

Yes, this is what I was trying to say.

So I think we're leaning
towards requiring epsilon > 0 (or better yet, for numerical stability,
epsilon > 1e-4). That condition is sufficient (but not necessary, as you
note) to keep the elbo well defined.

...and yet I came to the opposite conclusion.  :)  But like I said, I'll
defer if you both agree, I don't think it's that important to allow epsilon
= 0.  (There is a flag now that allows you to render images without it by
simply not adding it to the expected brightness, which is good enough for
my purposes.)

On Wed, Sep 28, 2016 at 10:15 AM Ryan<EMAIL_ADDRESS>wrote:

The term in the Hessian in question has the form Var(G) / E[G] ^ 4. Here,
G is modeled as a lognormal. The lognormal's variance is proportional to
the mean squared. So yes, our parameterization allows this term to go to
infinity.
This seems to make some intuitive sense to me. We are approximating the
distribution observed pixels with a Poisson distribution whose variance
is
the same as its mean. Its mean cannot be driven to zero without any
non-zero observation having zero probability (and associated extreme
curvature in any direction that makes it nonzero). But we don't really
believe this, and there are basically two ways to resolve it:

Say no observation is truly zero (keep epsilon > 0)
Say our model never truly has zero variance (use a normal rather
than a Poisson model, or otherwise add "dark variance")

It's not obvious to me that Celeste cannot work with epsilon == 0, only
that in some cases you get numerical problems with a poorly modeled
object
when it is. (Please correct me if I'm mistaken.) As such, I would not
want
to enforce epsilon == 0 in the code but rather let the user set it to
something other than zero to improve misfits. But if that's a minority
opinion I'll defer to you guys.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/jeff-regier/Celeste.jl/pull/315#
issuecomment-250233904>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIieC1_
oYOO3oTKEr5GL2pEIraRBvZR1ks5quqC5gaJpZM4KGDHZ>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jeff-regier/Celeste.jl/pull/315#issuecomment-250242150,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AESWPl9ImyR4BfyQr7fR99yS5rr7UZ4Cks5quqdIgaJpZM4KGDHZ
.

Here's a cleaned up version of those commits. I am enforcing epsilon > 0 per discussion with @jeff-regier . I think the logic was that maybe the model should be changed, but the model as it stands is liable to crash with epsilon == 0, so we should disallow it.
Maybe trimming tiles is actually the right answer, and once you trim tiles, the problem goes away. I'm learning about that now.
I tried one-off timed runs with the assertion in place and commented out and didn't observe a slowdown, but one-off timed runs are unreliable. Is there a more reliable perf benchmark to check such things?

FWIW, small data point, just adding a call to trim_source_tiles!() does not avert the NaNs when epsilon is set to zero. Not surprising, I think, since the threshold in trim_source_tiles! involves multiplying by epsilon, but I can't say I completely understand that function.

Right now it looks like bright pixels are those that exceed some fraction of epsilon (the sky intensity). @rgiordan -- Wouldn't it make more sense for them to exceed some multiple of sqrt(epsilon), since this is a Poisson model? e.g., 2 photons when the sky intensity is 1 isn't very bright, but 2000 photons when sky level is 1000 is clearly a star or a galaxy.
We could also add a bit of some smoothing inside the square root, e.g. + 1 or +10, at the cost of making the code a bit less intuitive.


Systemd support

Integrate with systemd enabled initramfs's. If possible, detect if the image is being built with systemd or base, and act accordingly. Also, support systemd-networkd auto configuration based from the ip= variable, and also support custom .network files. This all should be done with little to no configuration needed from the user.

Initial support for systemd was added in the version 0.0.2.


Points chunk loading

Hi, I'm playing stoneblock 1.0.27 and I'm having a "issue" with flux points on my server. This is a semi public server where people by default don't have access to chunkloaders, but chunks with points/plugs are being chunk loaded. There is no option on the config file to disable this. That is a problem for me since I can't have every chunk on every base loaded even for people that are not contributing to the server but are using flux networks to transfer energy and have their base loaded 24/7.

Ive got this problem too Is there anyway to stop the flux plugs/points chunkloading themselves

@Dinip12 @DirtyDerv Are you running the latest version 3.0.17 as there is a fix in that version, but I'm waiting to here from people if it's working for them, so please test it if you get the chance!

ok I'll try it on the test server
On Sun, 2 Dec 2018, 20:45 Ollie Lansdell<EMAIL_ADDRESS>wrote:

@Dinip12 https://github.com/Dinip12 @DirtyDerv
https://github.com/DirtyDerv Are you running the latest version 3.0.17
as there is a fix in that version, but I'm waiting to here from people if
it's working for them, so please test it if you get the chance!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SonarSonic/Flux-Networks/issues/270#issuecomment-443540462,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AT5huxJ3laLijrzlkiIhrodJ2U4D79WKks5u1DvfgaJpZM4YYOgC
.


Syntax error is gone when adding new line

monaco-editor version: 0.23.0
Browser: Chrome Version 90.0.4430.93 (Official Build) (32-bit)
OS: Windows 10
When typing a syntax error :

And then adding new lines and typing a new syntax error:

I see that the first syntax error is gone and never returns , even when I move the focus back to the first word.

This is very confusing. can you please fix that? it will be very appreciated.

@galyech The error checking function seems fine to me. How can your error be reproduced?

Thanks for your quick reply
we use the monaco editor for running Kusto queries.
here's a link to our demo environment where it reproduces. please let me know if you are able to reproduce it.
I also see it in other website that uses Kusto over monaco. can it be related to the language setting?


adding feature like "find usages" which search for occurrences across files for a method/function in VSCode

Visual Studio Code version 1.27.2
Find all References only list references in the current file. I need to find all references across files in a project.
Is it possible ?
Something like find usages
If you right click a symbol and select "find usages". If the current symbol is a function, then "find usages" searches for all places where this function is called. If the current symbol is a variable, then "find usages" searches for all places where this variable is used etc etc.

@rinoldsimon What language are you using?

@RMacfarlane  Ruby on Rails

Thanks @rinoldsimon. The Find All References feature for Ruby isn't built into VSCode by default, but added by an extension. Please reopen this issue on the extension you're using

even it doesn't work for Javascript files

@rinoldsimon Hmm, can you describe exactly what you're seeing or give a small code example? I'm able to use Find All References to find something across files


Add Home Accessory missing after you remove it.

After I added a home accessory, it was all good but I then realized that I had added it at the Home level, not at the room level.  so I removed it using Eve,  but now when I go to add the accessory back again to the Room, it is no longer available in the list to choose from :(

Latest version of homebridge should not have this issue; you'll add the bridge itself then you are free to move accessories between rooms without deleting and re-adding.

@nfarina yes I am using your new version ALWAYS. I would never log an issue unless I was using the latest. I also mentioned above that I have done
rm -r homebridge,
npm install homebridge

@nfarina, thanks for updating the npm install homebridge..  thats much better now.
"nfarina published 15 hours ago"  new https://www.npmjs.com/package/homebridge
the new version comes via npm install, thanks.   I will close the issue.


Use pylib as a dependency of the rustpython binary in order to get a Lib path

This should make sure that even if installed from crates.io, rustpython has access to the python standard library,
and it also allows access to the stdlib even when -I is passed, since the lib location is a ./configure option
in CPython rather than it always assuming that PYTHONPATH will be set.

I verified using cargo package -l that only the files we want should be packaged into the crate; just the python files not under a test/ directory


Fix for the .PHONY targets ...

I removed only the 'g' flag and all works perfect.
The two other commits where necessary to create the vsix package without error/warning messages.
Regards.

Hey, nice contribution!!! 👏🏻
Would you mind removing the package-lock.json file and undoing the changes to yarn.lock?
We are probably using different versions of yarn and npm.
Since you did not install or upgrade any deps, let's make sure they will remain unchanged.

Yes, i will try. :-)

I deleted the package-lock.json. The yarn.lock is the same as yours. Please try again. Regards.

Please, undo the yarn.lock changes.
The changes there are redirecting the packages to the npm registry, and it will be completely rewritten next time someone runs yarn.lock or yarn install.

thanks for the help, this was included on #17

Thank you !


Static initialization

It's time to do this properly.
We have to actually evaluate the program. With CHECKCAST implementation I have found other cases where current static initialization detection fails.

False alarm. Was due to another bug.


Feature Request: Debugging of AngularJS projects

I don't know if this is possible or am asking for too much, but is it possible to have the debugger debug angularjs? I am talking of the same debugging experience as the one I get when using it to debug nodejs

You can do client side debugging using the chrome debugger extension
https://marketplace.visualstudio.com/items/msjsdiag.debugger-for-chrome


MNIST without training the weights

Is the code
"python model.py mnist256test -e 1"
performed to test WANN on MNIST without training the weights?
But I just get an accuracy of 0.0568.

Are you sure everything is setup right? When I call this in the WANN_tool directory I get

But that command is to use the trained weights. If you are interested in untrained weights, you could use the sweep command to look at accuracies of different single values:

I run the code:

To my knowledge, this code will load the model the weights from "champions/mnist.out".
If adding the arugment -f zoo/mnist256.wann.json, it will load the weights from "zoo/mnist256.wann.json".
So, what is the difference between the weights from the out file and json file?
After reading your response, I also try:

which means the models architecture with or without adding"-f zoo/mnist256.wann.json" is the same, the only difference is the weights.
Therefore, could you tell me why the result of using the weights from "champions/mnist.out" is so bad?

"champions/mnist.out" is only the topology, in a giant square weight matrix. every weight is set to 0. Well...almost. it looks like the initial weights were still set, though they are normally rewritten before evaluation (every non-nan weight is set to the shared weight). This is why it is so bad, being a bit worse than chance, it looks like an almost completely inactive ANN -- except for a couple pixels that are still hooked up to the output layer.


[Bug]: Plugin disabling itself

/mv version -p output
some internal error occurred
Server logs
https://gist.github.com/MaouGoku/44261e89a63eb7d4e946c7981161336b
Server Version
1.16.5

Bug Description
while starting the server the plugin will fail to enable itself
cant use commands of the plugin
Steps to reproduce
dunno
Agreements

[X] I have searched for and ensured there isn't already an open or resolved issue(s) regarding this.
[X] I was able to reproduce my issue on a freshly setup and up-to-date server with the latest version of Multiverse plugins with no other plugins and with no kinds of other server or client mods.

Mohist is not a supported platform. The reason for this is that Mohist, as mentioned above, often causes errors that would not occur on a regular Bukkit server.


ArangoDB as datasource for gephi

Is there a way to use ArangoDB as datasource for gephi? I tried https://github.com/datablend/gephi-blueprints-plugin/wiki . But it is only working with the indirection over rexster with included plugin blueprints-arangodb-graph.
I think this is very inelegant option with a lot overhead.
I wish some way, that I'm able to add a blueprints arango db plugin to gephi and then I'm able to choose a ArangoDB as datasource. Maybe in combination with gephi-blueprints-plugin!? Ideas?

Any progress on this issues ?

not directly, but we're introducing arangoexport, which has cytoscape support: https://www.arangodb.com/2017/02/arangoexport-tool-exporting-data-arangodb/

Any release date for 3.2 ? We just started using arangodb for POC.

We're planning to be ready in Q2

So in conclusion what is the best way to use ArangoDB as datasource for gephi? Is it still the blueprint route?

I also noticed Arangodb not on this list: tinkerpop.apache.org/

This seems to be a more general question that directly related to the Tinkerpop provider.
Closing this as the code base and versions supported have changed significantly. Please reopen if you continue to experience this issue.


setpoint_accel plugin in px4

Hey guys,
I was wondering if the setpoint_accel plugin is supported by px4 firmware now. I was a little confused because:

According to this https://github.com/mavlink/mavros/blob/master/test_mavros/README.md,
2, I followed the exact same procedure for sending out setpoint_accel as setpoint_velocity, but the SITL and Pixhawk both didn't seem to respond to it. Whereas setpoint_velocity works perfectly fine for me.

Thank you!
Best Regards,
Francis

I would say that's a duplicate of #3452, closing.


Max field not present in outputted schema

For some reason I've noticed some properties (at least, it's the case for max) are not present when you output a schema:
s = new SimpleSchema({
  name: {
    type: String,
    max: 100
  }
});

// s.schema('name').max -> undefined

This is problematic because I want to be able to access max to validate form fields client-side, among other things.

Actually it seems that most properties defined in the schema rules section aren't available on the schema? Do I have that right? If so, why not? And how can they be made available?

@SachaG Some props are type-based while others are top-level. In other words, if you do a oneOf field, max would be within each oneOf while label would be the same for all. Internally, every schema field is actually stored as a oneOf with 1 or more types.
Depending on how you're using the return, it might be better to use getDefinition('name') rather than schema('name'). There is also mergedSchema(), which will merge in the subschemas.
Also, this is how autoform gets an object with the props merged:
  getFieldDefinition(ss, name) {
    const def = ss.getDefinition(name);
    if (!def) return;

    return {
      ...def,
      ...(def.type && def.type[0]) || {},
    };
  }

That should arguably be moved into the SS package and documented. It assumes that the first allowed type is the primary one. If you're not using oneOf, it would work just fine.
I realize a lot of this is not well documented in the readme. If anyone has time to do a docs PR with a proper explanation, I'd be grateful.

Ok, so to get the max I actually have to do:
s.getDefinition('name').type[0].max

The way I had pictured it, you would have a way to access the original full schema (I thought s._schema would do this, but it doesn't). I agree that this getFieldDefinition function would be super useful, maybe alongside a getSchema to get every property at once.

I think I'm running into another related issue because I override/extend my fields a lot. Since max is attached to a type, this gets overwritten by the new type because of https://github.com/aldeed/node-simple-schema/issues/144 and so max disappears.
To be honest it wasn't very intuitive at all that max, min, etc. would be considered to be attached to a type, as I've never used oneOf at all.

I don't think I released it yet, but a recent PR added schema.get(key, prop), which I think is what you're really looking for here. It probably should be improved to be schema.get(key, prop, oneOfIndex = 0) so that someone could get the prop value from a different oneOf if using multiple types.

Created a new issue for the remaining thing here: https://github.com/aldeed/simple-schema-js/issues/209


tr_shader: use dummy stage renderer if stage cannot be rendered, fix crash with stahl map

The stahl map have those materials:
textures/stahl/sfx_05_blue
{
	qer_editorimage textures/stahl/sfx_05b_blue
	cull none
	surfaceparm nodlight
	surfaceparm nolightmap
	surfaceparm nonsolid
	surfaceparm trans
	qer_trans 0.75
	{
		map textures/stahl/sfx_05b_blue
		blendFunc add
	}
	glowmap textures/stahl/sfx_05b_blue
}

textures/stahl/sfx_05_red
{
	qer_editorimage textures/stahl/sfx_05b_red
	cull none
	surfaceparm nodlight
	surfaceparm nolightmap
	surfaceparm nonsolid
	surfaceparm trans
	qer_trans 0.75
	{
		map textures/stahl/sfx_05b_red
		blendFunc add
	}
	glowmap textures/stahl/sfx_05b_red
}

You see they both use a legacy doom3-like glow map stage after a legacy quake3-like color map.
For some unknown reasons we fail to collapse the glow map with the color map.
Collapsing this glow map with the color map may be a bug to fix or a feature request to implement, but in all cases, we should not crash on badly crafted data.
Even if in the future we manage to properly collapse the glow map with the color map, one nasty individual may distribute this kind of purposedly wrong material to crash player's engine:
textures/broken/broken1
{
	glowmap textures/stahl/sfx_05b_red
}

textures/broken/broken2
{
	{
		map textures/stahl/sfx_05b_red
		blendFunc add
	}
	glowmap textures/stahl/sfx_05b_red
	glowmap textures/stahl/sfx_05b_red
	glowmap textures/stahl/sfx_05b_red
	glowmap textures/stahl/sfx_05b_red
}

So we better tell the renderer to actually process the stage with a dummy renderer than going to smash some stack.

LGTM


Improve memory usage of access_check_after_actions

On one hand, perhaps the correct move is to reduce the depth we allow, but maybe there's a way we can find a route from a prior solution that doesn't rely on the A* method (or on saving all the states we've seen, etc).

The unfortunate thing is that these aren't just a matter of max states evaluated but of states generated into the temp heap. My last cli run needed to evaluate 3k states, but had 27k left in the heap at the end of it.
We should have some way to discard states we aren't likely to use, perhaps states that leave the goal community (which requires that we expand community to all spots). What would we do with states that haven't reached the goal community yet, though, once we have a state that gets there? Or perhaps we could just evict states since we have a maximum iteration limit anyway.


Error flet build apk or aab -vv

VERBOSE: Obtaining dependency information for python-dotenv>=0.13 from https://files.pythonhosted.org/packages/6a/3e/b68c118422ec867fa7ab88444e1274aa40681c606d59ac27de5a5588f082/python_dotenv-1.0.1-py3-none-any.whl.metadata VERBOSE: Using cached python_dotenv-1.0.1-py3-none-any.whl.metadata (23 kB) VERBOSE: Collecting watchfiles>=0.13 (from uvicorn[standard]<1,>=0->flet==0.21.2) VERBOSE: Using cached watchfiles-0.21.0.tar.gz (37 kB) VERBOSE: Installing build dependencies: started VERBOSE: Installing build dependencies: finished with status 'error'

Can you share more info? (Your requirements.txt for ex)

Hello, thank you for responding, the code I want to compile is just a simple login window without any functionality, I still attach the code here...
import flet as ft

def main(page: ft.Page):
	page.title = "Flet counter example"
	page.vertical_alignment = ft.MainAxisAlignment.CENTER

	page.add(
			ft.Column(
					controls=[
						ft.Row(controls=[ft.TextField(label="Email", width=300)],
						       alignment=ft.MainAxisAlignment.CENTER),
						ft.Row(controls=[ft.TextField(label="Password", width=300, password=True)],
						       alignment=ft.MainAxisAlignment.CENTER),
						ft.Row(controls=[ft.TextButton(text="login")], alignment=ft.MainAxisAlignment.CENTER),
						ft.Row(controls=[ft.TextButton(text="Google")], alignment=ft.MainAxisAlignment.CENTER)],
					alignment=ft.MainAxisAlignment.CENTER,
					horizontal_alignment=ft.MainAxisAlignment.CENTER,
					expand=True)
	)

ft.app(main)

@ndonkoHenri
this is what is in my requirements.txt
flet == 0.21.2

Could you please use the template to submit an issue and provide a full build log.


Add support for parsing null values from YAML

This PR updates YAML deserializer to support null value parsing. Possible null representations are meant to cover the options from https://yaml.org/type/null.html.

This issue confused me a little. We really should handle nulls. YamlDotNet custom serialization does not have that much documentation, so I went digging a bit, and found that the issue is that we consume all string fields in the custom serializer, whether or not they are a match for the regex.
What we want to do is only consume fields that do match the regex. I.e.
if (parser.Accept<Scalar>(out var scalar) && scalar != null && _envRegex.IsMatch(scalar.Value))
{
    parser.MoveNext();
    value = _envRegex.Replace(scalar.Value, LookupEnvironment);
    return true;
}

I've pushed a commit to that effect. Please verify that it works for your issue as well.
Thanks for pointing this out and writing a test, it might have had other consequences as well.

I can confirm the updated method works for my use case. No problem!


Implemented Login/Signup with JWT Authentication (Server side)

#16 As per this issue
I've successfully completed the following tasks:
Implemented user registration endpoint (v1/auth/signup) with input validation and MongoDB storage.
Created login endpoint (v1/auth/login) with database credential verification.
Integrated JWT authentication with token generation, storage, and verification.
Please let me know if you'd like to test or review.

Hey @Mr-mahato, there is conflict in code, please pull the code from master and select Accept incoming (not current) from master option.

is it still conflicting to merge?

Also pull the changes from master branch whenever you are adding changes.

Hello @abhijeetnishal I see this issue not completed yet. Can I collab with @Mr-mahato. If yes please assign this to me and please mention collabing instructions.

Hey @Abhi-0001, i guess @Mr-mahato is still working on this issue. I have added some changes in review of this PR so wait for him to finish.

i am sorry being late for solving this issue , will you ckeck it once.

i am sorry being late for solving this issue , will you ckeck it once.

No issues @Mr-mahato, it's fine.

Hey @Mr-mahato, the code looks good to me some changes are there but will be done later also, good job👍.
This PR fixes #16


Border detector - correction of misplaced LEDS when border detector is active

If border detector is on and active (borders found), then led colors are little bit moved, because border is not calculate at all.
Little correction is missing...
Misplaced colors on top and bottom example.:

Correct mapping examples:

Copy of http://forum.stmlabs.com/showthread.php?tid=11053&pid=87716#pid87716, just for evidence on github :)
Thankes :)

we have now a better border detector! think can be closed....

Closed
open a new issue if this is still a problem.


Doesn’t work with pandoc-citeproc

Ignoring the metadata from included files means the references aren’t included in the final document.
Inserting references
This is the case both for

Explicit references
A reference to a bibliography

See the manual for instructions on pandoc-citeproc.
Inserting bibliography
Inserting a bibliography is a separate concern. There are two options,

Single combined bibliography
Per-include bibliographies

There are difficulties, especially if the individual included files are to work on their own, too.

pandoc-include needs to handle the reference-section-title field somehow. Likewise, if the last part of a document is a section header (which pandoc-citeproc will treat as a
If an header element is present with an id of refs the corresponding section will be used for the bibliography; multiple bibliographies are unlikely to work in this case.

Recommendations
Introduce a class input for including a file and merging displayed bibliographies
c.f. \input vs \include in LaTex.
This will remove any headers in the document with label refs, or the final header if it is the last entry in the file.
With include. run pandoc-citeproc on each included file first
Process the included files recursively with pandoc-citeproc, before including their outputs into the parent document.
(Note that pandoc-crossref must be called before pandoc-citeproc.)

Bibliography printing seems to work best if there’s a reference-section-title option in the metadata, rather than a heading at the end of a file.


Cache which rule belongs to a given route+params

Something else that stood out while profiling a Yii2 application was the huge amount of calls to UrlRule::createUrl.
Currently, every time a url is generated from a route (for example, by Html::a()), UrlManager iterates over all existing url rules until a matching rule is found. Imagine your application has 50 url rules, and you have 100 links on a page: in the worst case this would result in 5000 different calls to createUrl.
This doesn't seem neccessary at all. Once we have determined that a certain url rule matches with the route ['car/view', 'id' => $id], all subsequent calls to UrlManager::createUrl with that same signature (route name + parameter names) can instantly use the rule we matched earlier.
This patch does just that, by using $route . ',' . implode(',', array_keys($params)); as cache key and storing the matched rule (or the fact that none of the url rules match) with that key.
Profiling results for a page containing around 1000 different links: a few extra kilobytes of memory to store the matches, but a 16% performance increase.
Before:
yii\web\UrlRule::createUrl 	43,309 	calls
Total Incl. Wall Time (microsec):	1,671,670 microsecs
Total Incl. CPU (microsecs):	1,662,765 microsecs
Total Incl. MemUse (bytes):	20,533,208 bytes
Total Incl. PeakMemUse (bytes):	21,317,528 bytes
Number of Function Calls:	237,350

After:
yii\web\UrlRule::createUrl 	1,202 	calls
Total Incl. Wall Time (microsec):	1,399,313 microsecs
Total Incl. CPU (microsecs):	1,374,664 microsecs
Total Incl. MemUse (bytes):	20,541,008 bytes
Total Incl. PeakMemUse (bytes):	21,324,616 bytes
Number of Function Calls:	183,039

This will produce unexpected results for the following set of rules:
[
    [
        'pattern' => 'posts',
        'route' => 'user/activity',
        'defaults' => ['type' => 'post'],
    ],
    [
        'pattern' => 'photos',
        'route' => 'user/activity',
        'defaults' => ['type' => 'photo'],
    ],
]

@klimov-paul is this a valid use case? The second rule should never be used, neither when creating nor when parsing urls.

Why?
These rules mean:

for url '/posts' use controller 'User', action 'activity' and fill 'type' param to be 'post'
for url '/photos' use controller 'User', action 'activity' and fill 'type' param to be 'photo'

Or have I written something wrong?

More reliable version created at #8205


Make the read connection anonymous.

What should be added?
I would like to have the read connection made always anonymous, not the current account. This could solve an issue that is caused by how account switching works.
Pros and cons of this solution

This allows to not reconnect the read connection when changing accounts.
Whisper handling would have to be moved to the write connection.
The biggest problem: Would break Twitch's "you can't join if you're banned" feature.

This would also mean you don't show up in channel's chatters lists which is not desireable

Additionally, when a channel is joined, the server communicates user-specific settings for that channel, for example whether the user is a moderator there (which Chatterino uses to show the mod buttons). Changing it to anonymous would mean we would have to remove the mod button or show it all the time, or implement a complicated mechanism that calls /mods or similar.

Yeah I don't think there are any real pros that outweigh the cons in this switch, won't fix

Looked recently at the code responsible for handling IRC messages and:

This would also mean you don't show up in channel's chatters lists which is not desireable

We already send JOINs and PARTs on both write and read connections, so I think nothing would change if we were to JOIN channels only on write connection and correct me if I'm wrong, but wouldn't we still show up in chatters list?
Proof that we JOIN the same channel twice:

Additionally, when a channel is joined, the server communicates user-specific settings for that channel (USERSTATE message),

Played a lot with USERSTATE recently and from what I know you can receive that message after either JOINing a channel or sending a message.
We would still get USERSTATE after JOINing channels on the write connection and in addition to that, we can still get USERSTATE after we send a message (fun fact: we receive it even if we're not JOINed to the channel).
So given that, I think there's actually no cons, or rather no cons that we can't solve but pros as described by mm2pl in issue body are worth performing the switch imho. The logic of how do we handle certain IRC messages would just need to be adjusted.
@pajlada let me know what you think and if what I said makes sense please reopen and I can assign myself and try to make this work.

The biggest problem: Would break Twitch's "you can't join if you're banned" feature.

This is still true, so I still don't think this is a functionality we should look to add.

I don't really understand the reasoning for not being able to join the chat when banned and I don't think chatterino should follow exactly how twitch chat does it, because that's not what we do always anyways.
If this feature is really really really really really important we can on the write connection see that we can't join and are banned and just stop showing messages in that split.
The point of doing the read connection anonymous is to make people be able to switch accounts without having to reconnect to chat and miss messages.

@pajlada please have a look at #3107. That rate-limit I described in the issue has been in docs for quite some time already. It was "cosmetic" until twitch suddenly fixed that today, so we had no problems until yesterday.
For that issue, throttling would have to be implemented. Thing is - with having to JOIN many channels on both connections, it'd be ridiculously slow as waiting to fully join all the channels on both connections.
Example: I have 62 unique chats added to my Chatterino. It means that I'd need to send 124 JOINs. With a future fix it'll need to be split into 7 batches of JOIN messages with 10 seconds of cooldown before executing next batch, resulting in 60 seconds of wait before I can JOIN all the chats on both connections.
If we'd make only 1 connection JOIN channels on the user's account, it'd reduce that time to 30 seconds. While it's still a lot, it's way better in my opinion. It'd also grant us all other benefits described by @mm2pl in the issue an my recent comment.
While I fully understand and respect your opinion/concerns about the point 3. making Chatterino the "ban evasion app", I think that JOINing as little chats as possible is more important than that.
I'll reopen this for the time being to keep the conversation going and make issue more noticable as it's relevant given the current situation.

I am HIGHLY in favor of this, solves basically all issues I had with the recent JOIN rate limit changes.
This would not only make starting chatterino and especially switching accounts finally not completely suck anymore, but also make issues like #1308 a lot less relevant, since no messages would be lost on switching accounts etc., instead only if the read connection actually terminates, which, at least in my experience, is a very infrequent issue.
And, reiterating what others have said, since chatterino has an anonymous connection mode anyways, I really dont see a huge issue in banned channels being readable while the user is connected with their real account, after all banning someone from your chat is basically just about stopping them from sending messages. If someone wants to read messages in a chat he is banned in, it really doesn't take chatterino to do that, even just opening twitch in a private browser window would be enough.


Add ability to set basePoseMatrix directly or provide external camera

Currently, in this place:

https://github.com/Looking-Glass/looking-glass-webxr/blob/fc5b610b860e0f15f70dff2c98c0c17ea58bc051/src/LookingGlassXRDevice.js#L98-L102
the pose matrix is calculated from target/trackball values.

However, this makes it rather hard and awkward to override the camera pose externally (e.g. through animation, regular OrbitControls, ...).
Would be great if this could be turned off and one could instead just pass a pose matrix + focalDistance in.

Might be even better to simply allow passing in a regular camera to use (and then use also near/far clipping etc. from it, another area that's currently problematic to control).

Would like to bump this - not being able to control the camera is an issue for any kind of loader. E.g. when loading arbitrary objects one wants to set camera, fov, fit into the view, load cameras from the file, ... and that is all hard/impossible right now.

Hey Herbst!
So, it is possible to control the holographic camera with code, we've got an example using r3f's useFrame hook to set the camera position based on a sin wave. You can set the config settings dynamically so things like depthiness, focus, number of views etc can all be controlled with code.
react-three-fiber example
My thinking here is that this would solve the issue of exposing the base pose matrix, does this fit what you're looking for?
I'll look into adding near/far clip to the settings exposed with the config

Somehow my response here didn't get sent -
I know that the data can be set in that format. However, that only maps a subset of possible camera poses (e.g. tilt, non-standard matrices, ...), and still makes it pretty hard to convert from a known cam to the format looking glass wants.
Last but not least, cameras that already have events set up (e.g. clicking and dragging things around) also require external control, not just the base matrix.


Normalize LoadCache interfaces

Updations:

The lifecircle(including creation and deletion) of all kinds of LoadCaches are directally managed.
Add UT for LoadManager.

Man you can really write code.


Use server's preferred key agreeement (take 2)

In contrast to upstream Go, we will send an HelloRetryRequest and accept an extra roundtrip if there is a more preferred group, than the one the client has provided a keyshare for in the initial ClientHello.
Cf. https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/
Supersedes #157

Yes, that aligns with BoringSSL's behaviour. To specify equal preference, we need a different interface.


valid Anagram

Description
you are given two words and you need to find if the first word is anagram of other. Output will be yes if it is anagram, and no if not.
anagram of word is a word that is formed by jumbling the letters of word.
Domain
Competitive Programming
Type of Contribution
No response
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of LearnCPP.

/assign

/assign


feat: add VSCode debugging with CodeLLDB

Description
Added the debugging which is used in Pola-rs. Removed ./vscode from git-ignore due to it needing to be used for setting up the .launch.json file, settings.json, etc.

Can't seem to get this working on my computer right now, if anybody would like to try cloning and trying to debug, feel free to!