Significantly slower compression (@21) with non-aligned inputs

When doing some testing where ZSTD is involved, I noticed that adding just a few hundred bytes to the end of a large input would significantly impact compression time.
Basically what I do is:

Copy a 1k static buffer into a single contiguous buffer up to the size I want
Compress that contiguous buffer with ZSTD_compress(...) with a compression level of 21
Decompress compressed buffer into a new buffer.

Test code:
FB_ROUNDTRIP_ZSTD(1 * 1024 * 1024);
FB_ROUNDTRIP_ZSTD(1 * 1024 * 1024 + 23);
FB_ROUNDTRIP_ZSTD(2 * 1024 * 1024);
FB_ROUNDTRIP_ZSTD(2 * 1024 * 1024 + 64);
FB_ROUNDTRIP_ZSTD(33 * 1024 * 1024);
FB_ROUNDTRIP_ZSTD(33 * 1024 * 1024 + 128);

Output:
Creating contiguous buffer (1048576)...done 0.002302s
Compressing...done 0.015497s
Decompressing...done 0.003197s
Creating contiguous buffer (1048599)...done 0.000638s
Compressing...done 0.191606s
Decompressing...done 0.003058s
Creating contiguous buffer (2097152)...done 0.000771s
Compressing...done 0.020405s
Decompressing...done 0.005225s
Creating contiguous buffer (2097216)...done 0.000727s
Compressing...done 0.818459s
Decompressing...done 0.005411s
Creating contiguous buffer (34603008)...done 0.012068s
Compressing...done 0.137107s
Decompressing...done 0.086206s
Creating contiguous buffer (34603136)...done 0.012254s
Compressing...^CPress any key to continue . . .

I have to kill it once it goes into compressing the 34603136 buffer because it takes minutes.
In fact, it seems like all the compression levels other than 21 don't really show any significant differences between compression time, though this testing is obviously quite ad-hoc and anecdotal, but it is quite consistent.
This might just be some kind of weird pathological case because of how I am constructing the buffer out of the same 1k chunk of data, except the last chunk will be truncated, but I thought it was worth mentioning something here in case this is an edge case that could be patched up or something.

Hi @Jake-Shadle
Thanks for the notification,
yes, you are right, this is something we should look into.
It's quite possible this is an edge case to take care of.
We might need a sample to better investigate the issue. Is it accessible ?

Sure, I can put something together later tonight, will just need to disentangle what I have into a standalone sample. Thanks for the quick response!

I couldn't reproduce the problem. What version of zstd did you use? Please provide your file.

Latest update in "dev" branch includes a fix by @inikep which should fix this issue

fixed in v0.8.1


End User auth using Auth0 and GitKit

Tracking issue

Hi,
Congrats on the project, and I wanted to ask a follow up question as to how you want to structure End User Auth. We have a way of issuing developer (and operator) certifiacets using Vault's dynamic PKI mechanism. This, combined with an edge mutual-TLS proxy for our Kubernetes clusters allows us to grant access to, for example, debug endpoints of our services (a /statusz or the Golang /debug/request).
I was wondering whether the auth manager is considering using client TLS certs for End User auth, maybe through some SPIFEE naming convention. For example:
spiffee://internal.improbable.io/users/michal
We thought about using OIDC identity tokens  similarly to Kubernetes OIDC auth but it has practical drawbacks: you need the proxy to do a complicated OAuth2 flow for browsers (for human operators) to be able to use it. Alternatively, a Proxy-Authentication header can be used, but that kinda defeats the purpose of mutual TLS.
What are your thoughts on doing this in Istio?

That's a very good question.
For the End User Auth, we planned to support OIDC identity tokens, so the auth will be JWT+TLS. I agree it has drawbacks, but it is much easier for non-developer users to use (no need to get certificate through CSR to CA). For developers, we may support certs with user-accounts as identities (but it is still on discussion).

Also see this for how we want to support debugging in the short term:
https://github.com/istio/istio/issues/242

@lizan , are you working on this?

Yes, I'm proposing a Workgroup for this:
https://groups.google.com/forum/#!topic/istio-security/pK0oUikOZuw

Does end user auth also pertain to external systems accessing a Kubernetes cluster through the Ingress?  Being able to apply policy decisions about callers into a cluster isn't obvious from an implementation perspective and seems pertinent to both end-users and non-cluster external clients.

Are there any updates in this area?  I know there has been a lot of movement in the Istio development space and I want to make sure this is still a priority.  Thanks!

Yes this is still on the track. It is currently in a pre-alpha stage along with istio auth policy. Feel free to join security SIG meeting to get development updates.


LR and dataset sampling

Hey, I really appreciate your amazing work on this project.
I would be grateful if you could clarify the learning rate and dataset sampling for the semantic segmentation downstream task.
In your paper, you state that you use learning rate of 0.001. However, this has to be explicitly specified in segcontrast framework, otherwise the learning rate of 2.4e-1 will be used. When I specify --lr 0.001 parameter for downstream fine-tuning of the provided pretrained model, I obtain the results in 2nd row of the table (I've skipped the experiments noted with -).
However, if I omit the --lr 0.001 argument, or in other words, if I use a learning rate of 2.4e-1, I am able to get results that are closer to those reported in the paper (last row in the table).

0.1%
1%
10%
50%
100%

Paper
38.59
51.42
60.34
61.42
61.47

Reproduced w/  --lr 1e-3
27.09
32.76
37.57
-
-

Reproduced w/ --lr 2.4e-1
36.66
47.36
55.80
59.62
60.40

Could you please clarify the learning rate that you used for the experiments reported in the paper? How does standard deviation looks like between multiple independent runs?
Finally, since the segcontrast framework randomly selects a training subset, do you fix a seed between different runs in order to always train with the same data?

Hi! Thanks for the interest in our work.
As you mentioned the learning rate used in the paper for the downstream task was indeed 0.001 however we also changed from SGD optimizer to AdamW and used no scheduler (note that the original segcontrast code does use the Cosine Annealing scheduler. I guess the segcontrast repo by default uses SGD but you can change it to the AdamW optimizer in this line, replacing from line 287-310 to this 3 lines
optimizer = torch.optim.AdamW(optim_params, lr=self.params.lr)

self.optimizer = optimizer
return optimizer

Sorry for that, I will add those changes to the segcontrast shortly, but by changing thoses lines that I mentioned you should be all set to reproduce TARL results. :)

Hi @hbzhou530 did you remove the scheduler during fine-tuning? This is also another change, learning rate, AdamW optimizer and NO learning rate scheduler.

To avoid further confusion, I have just created a branch in the segcontrast repo with the hyperparameters and optimizer used for the TARL paper.

Thank you for your quick response. After re-checking through your new branch, the accuracy is reproduced (38.07@0.1%). There should be no other problems.  Thx again!


Always filter jasmine from stack traces.

@facebook-github-bot shipit

Thanks for importing. If you are an FB employee go to Phabricator to review.

Thanks for importing. If you are an FB employee go to Phabricator to review.


TERM of "screen" (tmux) makes unselected goal headers invisible

normal console launch

$ echo $TERM
xterm-256color

$ tmux
$ echo term
screen

Aaaah now I noticed the dots too this is basically a dup of #50

Yep, caused by the switch to pancurses, I will be tracking updates on this issue over at #50 if you don't mind.


introduce readthedocs

with the config files the documentation can be viewed
on readthedocs.io

With readthedocs we can generate and host the documentation. You can checkout a demo here.
What do you think?

LGTM, more exposure is always good. The question is, do we want to support this when the rendering differs from the github one?

What rendering differences do you mean? I do not think we use the github flavored markdown in the documentation. Until we stick to simple markdown it shouldn't be a problem. If we want more complex documentation and markdown is not enough in the future we can switch to rst, in that case Sphinx  (supported by readthedocs) can be used to generate the documentation.
In the background mkdocs is called to generate the docs, you can do it locally too to view the results.

Sounds good.


Why does CI action test_all check out git repo + submodules?

Just noticed this, e.g. here.  Since this is downloading build artifacts, not building from sources, why check out all these git repos?

@GMNGeoffrey @pzread

Side-note: If this is changed, you may want to set IREE_ERROR_ON_MISSING_SUBMODULES=OFF :)

I believe I tried without the checkout and we have tests that depend on source files both from IREE and from submodules. We could likely try to identify some subset, but I think the correct fix is to instead create installable tests

And it's not just one oddball test or something. Like all the lit tests are run against .mlir source files, for instance

I see. Maybe at least we can drop the git submodules ?

Unfortunately not trivially. We depend on source files from submodules as well. It is at least lit from LLVM and it might only be that. So we could hack together a sparse checkout, but I didn't investigate more deeply at the time. I still think the right solution is installable tests, but a workaround wouldn't be the worst thing.

ok. thank you for the answers! closing this issue now.


Rev gatk public dependency to 4.alpha.2-182-g5d2f859-20170315.140748-1

@lbergelson please review

@davidbenjamin please review, since this modifies a tool you wrote


Dont overwrite pageName when tracking flights widget click event

pageName param in flights_omniture script shouldnt be overwritten when the pageName value is already present. This messed up statistics for flights widget in Essential Information
Jira ticket: https://lonelyplanet.atlassian.net/browse/LPMC-70

:+1:


Again! Error (not the same)

`Sorry!
An error was encountered while processing your request:
Invalid return protocol`
`'use strict'
module.exports = {
appID: 252490,
contextID: 2,
bots: {
bot_1: {
    },
},
steamApiKey: '',
SteamApisKey: '',
domain: 'localhost:3000',
SteamApisCompactValue: 'safe_ts.last_30d', // Use safe price calculated from 30 days of data, more info: https://steamapis.com/developers (Market Items - Optional Query Parameters "compact_value")
site: {
    header: 'CSG0.Trade', // Name/header/title of website. Prefix for  <title></title> (For more: /index.html line: 9)
    steamGroup: '#',
    copyrights: 'Copyright © csg0.trade 2017',  // Copyright text
},
website: 'localhost',    // Website URL, follow the example (do not add / at the end)
websitePort: 3000,    // Website PORT, don't change it unless you're using a reverse proxy
tradeMessage: 'Trade offer from csg0.trade | If you did not request this offer or the offer looks invalid please decline.', // Quite obvious
rates: {
    ignoreItemsBelow: 0.05, // Ignore items below this price (price * rate < ignoreItemsBelow) - shows (Too Low) for user
    trashPriceBelow: 0.2,   // Items below this price are considered trash, the trash rate modifier will be applied
    // Items
    user: {
        key: 1,
        knife: 0.95,
        rare_skin: 0.95,
        weapon: 0.9,
        misc: 0.85,
        trash: 0.7,
    },
    bot: {
        key: 1.05,
        knife: 1,
        rare_skin: 1,
        weapon: 0.95,
        misc: 0.9,
        trash: 0.8,
    },
},

}
It is only happening for localhost
`

https://github.com/pepzwee/node-csgo-web-tradebot/blob/master/config.js#L26
Missing http://, please follow config instructions.


Explore how pool deposits can be tracked in the database

From https://github.com/input-output-hk/cardano-db-sync/issues/406#issuecomment-755142757 @xdzurman says:

To put the pool deposit (500 ADA) somewhere in the database, after a pool is retired. Currently it can't be explicitly linked to the reward address it belongs to.

The pool deposit is returned to the stake pool (via its registered reward account) on the epoch in which it is reaped (ie the epoch listed in the pool retirement certificate). This is shown in "Figure 40: Pool Reap Inference Rule" of the Shelley ledger spec. It is therefore implicit in the protocol.
Note that if the reward account is not registered, the deposit goes to the treasury.
Note also that a pool retirement certificate does not guarantee that a pool will be reaped, as the operator may issue a new registration certificate (rendering the retirement void) or a new retirement certificate (changing the epoch).
The deposit amount is according to the poolDeposit protocol parameter. Note that if a pool is reaped on the same epoch that this parameter is changed, the old value is used (see "Figure 44: Epoch Inference Rule" of the spec).
As an example, say Alice issues a retirement certificate for her pool for epoch 300. Provided she doesn't issue any pool certificates, then on the 299 to 300 epoch boundary, the reward address registered in her pool certificate will be credited by the deposit value as it is in epoch 299.

The pool deposit is returned to the stake pool (via its registered reward account) on the epoch in which it is reaped (ie the epoch listed in the pool retirement certificate). This is shown in "Figure 40: Pool Reap Inference Rule" of the Shelley ledger spec. It is therefore implicit in the protocol.
Note that if the reward account is not registered, the deposit goes to the treasury.
Note also that a pool retirement certificate does not guarantee that a pool will be reaped, as the operator may issue a new registration certificate (rendering the retirement void) or a new retirement certificate (changing the epoch).
The deposit amount is according to the poolDeposit protocol parameter. Note that if a pool is reaped on the same epoch that this parameter is changed, the old value is used (see "Figure 44: Epoch Inference Rule" of the spec).
As an example, say Alice issues a retirement certificate for her pool for epoch 300. Provided she doesn't issue any pool certificates, then on the 299 to 300 epoch boundary, the reward address registered in her pool certificate will be credited by the deposit value as it is in epoch 299.

 There are plans afoot to improve this, but what we have now we will have to live with.

 There are plans afoot to improve this, but what we have now we will have to live with.

Any progress on this?

there will just be a single entry for that epoch. what we have now we will have to live with.

Does that mean it already work? I still can't find the pool deposits.

Pool deposits can be seen with
select * from tx where deposit > 0 ;

Deposits of 2000000 lovelace (2 ADA) are stake key registration deposits. The ones for 500000000 lovelace (500 ADA) are the stake poll registration deposits.
When a pool is de-registered, the deposit is refunded. At the epoch boundary where that pool is reaped. the pool deposit goes back to the stake address. If the stake address does not exist, the deposit goes back to the reserves.

@xdzurman Is there anyting left unresolved here? Can this ticket be closed?

You can close this.

I might be a tad late to the party, but would you mind sharing how would one track a balance of an account, for example?
Calculating  outputs + reward + reserve +  treasury - inputs - withdrawal won't do the trick and there doesn't seem to be a nice and easy way around this.
A good candidate could be stake1uyluup0rh6r2cc7kcw8nudqz990ezf5ltagxmw3u8deukvqwq7etq (rewards account for an already retired pool). Different explorers show this in a different manner, but I think it's currently not possible without any kind of workaround / additional cumbersome computing. Things become even more blurry when taking edge cases into account. With all that in mind, wouldn't it be beneficial to explicitely track reaped info along with account and epoch in the dbsync?

@1000101 Please make that a separate ticket.


libre: 3.10.0 -> 3.11.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/baresip/re/releases.
meta.description for libre is: A library for real-time communications with async IO support and a complete SIP stack
meta.homepage for libre is: https://github.com/baresip/re
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.11.0 with grep in /nix/store/24lj9kq1hcsizvjknqvd88mgywbvf6al-libre-3.11.0
found 3.11.0 in filename of file in /nix/store/24lj9kq1hcsizvjknqvd88mgywbvf6al-libre-3.11.0

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath
baresip
libre
librem

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/24lj9kq1hcsizvjknqvd88mgywbvf6al-libre-3.11.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libre https://github.com/r-ryantm/nixpkgs/archive/66f6ebe46c670875b698eebde3e6be68147a7d03.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/66f6ebe46c670875b698eebde3e6be68147a7d03#libre

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/24lj9kq1hcsizvjknqvd88mgywbvf6al-libre-3.11.0
ls -la /nix/store/24lj9kq1hcsizvjknqvd88mgywbvf6al-libre-3.11.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package failed to build:

baresip

2 packages built:

libre
librem

Maintainer pings
cc @elohmeier @7c6f434c for testing.

Apparently we need a baresip bump first (or maybe together)

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/baresip/re/releases.
meta.description for libre is: A library for real-time communications with async IO support and a complete SIP stack
meta.homepage for libre is: https://github.com/baresip/re
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.12.0 with grep in /nix/store/4h9c1659sx5bz9v0dvngxm9ap9aa0jwg-libre-3.12.0
found 3.12.0 in filename of file in /nix/store/4h9c1659sx5bz9v0dvngxm9ap9aa0jwg-libre-3.12.0

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

4 package rebuild(s)

First fifty rebuilds by attrpath

baresip
libre
librem

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/4h9c1659sx5bz9v0dvngxm9ap9aa0jwg-libre-3.12.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libre https://github.com/r-ryantm/nixpkgs/archive/ef1bc185bd7b248578a365c8e9ddcc6ceed99398.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/ef1bc185bd7b248578a365c8e9ddcc6ceed99398#libre

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/4h9c1659sx5bz9v0dvngxm9ap9aa0jwg-libre-3.12.0
ls -la /nix/store/4h9c1659sx5bz9v0dvngxm9ap9aa0jwg-libre-3.12.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package failed to build:

baresip

2 packages built:

libre
librem

Maintainer pings
cc @elohmeier @7c6f434c for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/baresip/re/releases.
meta.description for libre is: Library for real-time communications with async IO support and a complete SIP stack
meta.homepage for libre is: https://github.com/baresip/re
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.13.0 with grep in /nix/store/mh1znzd9r4hq5dnsmbp6dy2gfnxpv47j-libre-3.13.0
found 3.13.0 in filename of file in /nix/store/mh1znzd9r4hq5dnsmbp6dy2gfnxpv47j-libre-3.13.0

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

4 package rebuild(s)

First fifty rebuilds by attrpath

baresip
libre
librem

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/mh1znzd9r4hq5dnsmbp6dy2gfnxpv47j-libre-3.13.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libre https://github.com/r-ryantm/nixpkgs/archive/c3e7fae2c3a8b73e9b3bcabc24c7a1db3fc8d516.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/c3e7fae2c3a8b73e9b3bcabc24c7a1db3fc8d516#libre

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/mh1znzd9r4hq5dnsmbp6dy2gfnxpv47j-libre-3.13.0
ls -la /nix/store/mh1znzd9r4hq5dnsmbp6dy2gfnxpv47j-libre-3.13.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package failed to build:

baresip

2 packages built:

libre
librem

Maintainer pings
cc @7c6f434c for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/libre/versions.
meta.description for libre is: Library for real-time communications with async IO support and a complete SIP stack
meta.homepage for libre is: https://github.com/baresip/re
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.14.0 with grep in /nix/store/c0bia6nfwv14cxlyny3j8cbc4q04wpvy-libre-3.14.0
found 3.14.0 in filename of file in /nix/store/c0bia6nfwv14cxlyny3j8cbc4q04wpvy-libre-3.14.0

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

4 package rebuild(s)

First fifty rebuilds by attrpath

baresip
libre
librem

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/c0bia6nfwv14cxlyny3j8cbc4q04wpvy-libre-3.14.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libre https://github.com/r-ryantm/nixpkgs/archive/ef4b442ca9b785a2d4c360832011061f592d8aab.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/ef4b442ca9b785a2d4c360832011061f592d8aab#libre

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/c0bia6nfwv14cxlyny3j8cbc4q04wpvy-libre-3.14.0
ls -la /nix/store/c0bia6nfwv14cxlyny3j8cbc4q04wpvy-libre-3.14.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

baresip

2 packages built:

libre
librem

Maintainer pings
cc @7c6f434c for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/baresip/re/releases.
meta.description for libre is: Library for real-time communications with async IO support and a complete SIP stack
meta.homepage for libre is: https://github.com/baresip/re
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.15.0 with grep in /nix/store/88ji20x1v0b4l0r4mm6izjgbnqv9qsml-libre-3.15.0
found 3.15.0 in filename of file in /nix/store/88ji20x1v0b4l0r4mm6izjgbnqv9qsml-libre-3.15.0

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

4 package rebuild(s)

First fifty rebuilds by attrpath

baresip
libre
librem

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/88ji20x1v0b4l0r4mm6izjgbnqv9qsml-libre-3.15.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libre https://github.com/r-ryantm/nixpkgs/archive/8853a0269ec4e936590f54ae16ca4a1766c823d6.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/8853a0269ec4e936590f54ae16ca4a1766c823d6#libre

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/88ji20x1v0b4l0r4mm6izjgbnqv9qsml-libre-3.15.0
ls -la /nix/store/88ji20x1v0b4l0r4mm6izjgbnqv9qsml-libre-3.15.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

baresip

2 packages built:

libre
librem

Maintainer pings
cc @7c6f434c for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/baresip/re/releases.
meta.description for libre is: Library for real-time communications with async IO support and a complete SIP stack
meta.homepage for libre is: https://github.com/baresip/re
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.16.0 with grep in /nix/store/3gccsfckwhlqhrzzzy966qmc8lk7ny77-libre-3.16.0
found 3.16.0 in filename of file in /nix/store/3gccsfckwhlqhrzzzy966qmc8lk7ny77-libre-3.16.0

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

4 package rebuild(s)

First fifty rebuilds by attrpath

baresip
libre
librem

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/3gccsfckwhlqhrzzzy966qmc8lk7ny77-libre-3.16.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libre https://github.com/r-ryantm/nixpkgs/archive/babe7b700e8888ffad9cd36213fb256c4fb0b6c9.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/babe7b700e8888ffad9cd36213fb256c4fb0b6c9#libre

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/3gccsfckwhlqhrzzzy966qmc8lk7ny77-libre-3.16.0
ls -la /nix/store/3gccsfckwhlqhrzzzy966qmc8lk7ny77-libre-3.16.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

baresip

2 packages built:

libre
librem

Maintainer pings
cc @7c6f434c for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/baresip/re/releases.
meta.description for libre is: Library for real-time communications with async IO support and a complete SIP stack
meta.homepage for libre is: https://github.com/baresip/re
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.17.0 with grep in /nix/store/2kf5wv3036x2wqg5l902gnlgbvfx412q-libre-3.17.0
found 3.17.0 in filename of file in /nix/store/2kf5wv3036x2wqg5l902gnlgbvfx412q-libre-3.17.0

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

4 package rebuild(s)

First fifty rebuilds by attrpath

baresip
libre
librem

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/2kf5wv3036x2wqg5l902gnlgbvfx412q-libre-3.17.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libre https://github.com/r-ryantm/nixpkgs/archive/faf310d348b1f20f2ae8d52ba3d1565c309e3cc9.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/faf310d348b1f20f2ae8d52ba3d1565c309e3cc9#libre

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/2kf5wv3036x2wqg5l902gnlgbvfx412q-libre-3.17.0
ls -la /nix/store/2kf5wv3036x2wqg5l902gnlgbvfx412q-libre-3.17.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:x: 1 package failed to build:

baresip

:white_check_mark: 2 packages built:

libre
librem

Maintainer pings
cc @7c6f434c for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/baresip/re/releases.
meta.description for libre is: Library for real-time communications with async IO support and a complete SIP stack
meta.homepage for libre is: https://github.com/baresip/re
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.18.0 with grep in /nix/store/h1kvccfxjmv9rf06wdr2f24m1n3vzgkg-libre-3.18.0
found 3.18.0 in filename of file in /nix/store/h1kvccfxjmv9rf06wdr2f24m1n3vzgkg-libre-3.18.0

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

4 package rebuild(s)

First fifty rebuilds by attrpath

baresip
libre
librem

Instructions to test this update (click to expand)

Either download from the cache:
nix-store -r /nix/store/h1kvccfxjmv9rf06wdr2f24m1n3vzgkg-libre-3.18.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nixpkgs-update-cache.nix-community.org/' \
  --option trusted-public-keys '
  nixpkgs-update-cache.nix-community.org-1:U8d6wiQecHUPJFSqHN9GSSmNkmdiFW7GW7WNAnHW0SM=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The nixpkgs-update cache is only trusted for this store-path realization.)
For the cached download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libre https://github.com/r-ryantm/nixpkgs/archive/ff407c6d570cd8bcc6c48929aace6432adbd2489.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/ff407c6d570cd8bcc6c48929aace6432adbd2489#libre

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/h1kvccfxjmv9rf06wdr2f24m1n3vzgkg-libre-3.18.0
ls -la /nix/store/h1kvccfxjmv9rf06wdr2f24m1n3vzgkg-libre-3.18.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:x: 1 package failed to build:

baresip

:white_check_mark: 2 packages built:

libre
librem

Maintainer pings
cc @7c6f434c for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.


AsyncCommand updates CanExecute somewhat late and/or not at all

Not sure why this is happening, but I can't figure it out.
My command is defined like this:
public AsyncCommand ToggleCheckedCommand { get; }

// constructor
public MyViewModel()
{
    ToggleCheckedCommand = new AsyncCommand(ToggleCheckedAsync);
}

private async Task ToggleCheckedAsync(object _)
{
    var response = await ServerApi.DoWebRequestAsync();
    if (response.Success)
        ...
}

If I debug the app and break at await ServerApi.DoWebRequestAsync(), and mouseover ToggleCheckedCommand, Execution is null and IsExecuting is False. If I perform the web request and continue to the next line, if (response.Success), Execution and IsExecuting assume the expected values.
If I unit test my viewmodel and mock ServerApi, so that it returns instantly,  Execution is null and IsExecuting is False throughout the test (as seen when debugging and breaking at the same lines). This makes the test fail, since I'm checking for whether or not the command is disabled during execution.
Is this something you can reproduce? Using v1.0.0-eta-02.

This was happening because the command was starting the delegate before it updated its properties. So, if you were to check the properties from within the command (before the first await), you would see the old values. The UI layer would never see them, since they would be updated by the time ICommand.Execute returned.
1.0.0-eta-03 changes this behavior by delaying the delegate execution until the properties have been updated. This unit test will catch regressions.


"Move symbol to..." refactor does not honor Import Format setting.

Environment data

Pylance version: v2024.9.101
OS and version: Windows 10
Python version (& distribution if applicable, e.g. Anaconda): 3.12

Repro Steps

change "Import Format" setting to "relative".
create a python module and define a symbol in it and a reference to that symbol.
Refactor -> Move Symbol to new file.

Expected behavior
Symbol definition is moved to new file, and a relative import for the symbol is generated in the original file:
from .new_file import symbol
Actual behavior
Absolute import for the symbol is generated in the original file:
from new_file import symbol

Thanks for reporting, I can reproduce it.


Add Ryan Brink to Contributors list

@brink-ry, I'm quite elated about your PR. I wanna evolve this project to addresses various problems faced by first-time contributors. I'd love to learn about your journey in open source community, the problems, pain points you had etc.
Could you explain how you felt when you went through the tutorial, made a PR and learned that I merged it?


IcmpSendEcho2 FARPROC vs PIO_APC_ROUTINE

This applies to both IcmpSendEcho2 and IcmpSendEcho2Ex:
Docs for these functions indicate that the third argument, ApcRoutine, should be of type PIO_APC_ROUTINE instead of FARPROC on any modern version of Windows:

On Windows Vista and later, PIO_APC_ROUTINE_DEFINED must be defined to force the datatype for this parameter to PIO_APC_ROUTINE rather than FARPROC.
On Windows Server 2003, Windows XP, and Windows 2000, PIO_APC_ROUTINE_DEFINED must not be defined to force the datatype for this parameter to FARPROC.

Currently, this crate defines this argument as type Option<FARPROC>. I believe this should be changed to Option<PIO_APC_ROUTINE> for easier use and to avoid confusion.
On a similar note, I'm not sure if this can be done or is worthy of it's own issue, but the RequestOptions argument takes one of two different types depending on platform:

A pointer to the IP header options for the request, in the form of an IP_OPTION_INFORMATION structure. On a 64-bit platform, this parameter is in the form for an IP_OPTION_INFORMATION32 structure.

Perhaps the signature could be changed on 64-bit systems to use the correct argument type here? As it stands, calling this function on a 64-bit platform is a bit of hassle. I can open a separate issue for this if it seems reasonable.

Transferring to the win32 metadata repo where these definitions originate.


Suggestion: Show last frame on twitter if possible

I'm not completely sure this is possible, but it would be nice if the image shown on the twitter preview was "the current radar" rather than "the beginning of the most recent loop"

Hmm. Interesting idea. It's not possible as far as I can tell, short of using the last image as the first image, but since GIFs loop that might not be a bad idea...
I'll investigate.


No gain using FP16 on a GV100

Hello!
Thank you for the nice implementation. I was wondering if you have tried to run the tacotron on a GV100 ...and if you did if you got a speed-up.
My baseline is a 1080Ti and so far, I get a gain only because I can train with bigger batches. I run in the FP16 mode to use the tensor core and yet it does not go faster. In fact, it goes slightly slower than with FP32. From what I saw from the implementation, all I have to do is set fp16 to true. Am I missing something?
Thank you in advance

That is similar to what we currently perceive. We're working on improving it.

Any update on this?


Ensure Notebook Model Dirty State Can Be Triggered Before Session Start

This PR fixes #10416.
Issue: we were waiting until a session was started  before calling the resolving the modelReady promise. This promise was awaited in a few places to get a reference to the notebook model, one of which was to hook up model contentChange (and kernelChange) events in notebookInput.
This was originally done because there is always a kernelChange event fired when a notebook is opened, so we didn't want to set the document to dirty incorrectly.
Tracking the first kernel change is straightforward, however, which is part of my change here.
Now, users should be able to open a notebook, immediately edit the notebook, and save it, before the session is loaded for the kernel.

Coverage increased (+0.002%) to 33.956% when pulling 42e8fd5e294d457fd9a0d1628fbadc2015cbc44c on fix/nbDirtyStateFix into 9680b1e2cf02d5dbbb4f0740ceee1f796cd1cd1f on master.


Order of goal location array

Hi,
I'd like to know the order of the pose element in the position array. Is it (x,y,o) or (x,o,y)?
https://github.com/facebookresearch/habitat-lab/blob/cafea28a2d685e02b8ffe339d7dd556a0b1ea42d/examples/shortest_path_follower_example.py#L71

It's a position, so (x, y, z).

Hi, thanks for answering my question. But based on my experiment, I have to give the goal position in the format of (x, orientation, y) to the get_next_action() method of ShortestPathFollower. I don't see any translation of goals[0].position from (x,y,o) to (x,o,y), so I assume it should be (x, o, y)?

Neither NavigationGoal.position nor get_agent_state(0).position has an orientation/rotational component.  Both are simply a 3D position (x, y, z) where +Y is up.  The agent orientation is in get_agent_state(0).rotation while NavigationGoal has no orientation.

I see, thank you so much!


construct multivector from blade addition

Change-Id: Ib2e5fd58c9fff51a15afb5814c48b97d180a311f

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (f92f598) 96.42% compared to head (7c3aeda) 96.87%.

Additional details and impacted files
@@                              Coverage Diff                              @@
##           I6abd8a67a3b94f537b705da8b1a1f7179d5426f7       #7      +/-   ##
=============================================================================
+ Coverage                                      96.42%   96.87%   +0.44%
=============================================================================
  Files                                              1        1
  Lines                                             28       32       +4
  Branches                                           1        1
=============================================================================
+ Hits                                              27       31       +4
  Partials                                           1        1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


www.DOMAIN.tld results in "Site get failure: Site does not exist"

I can only run the tool for domain without www. prefix.
So if I open the Website with www. prefix I get the browser error because the certificat is only installed for DOMAIN.tld.
If I run letsencrypt with -d domain.tld -d www.domain.tld I get the error "Site get failure: Site does not exist"
What can I do to install certificate for www.domain.tld and domain.tld ?

+1 I have the same problem.

i also ran into the same problem: I am using a certificate with domain.tld and www.domain.tld for each website in plesk. Only the domain.tld is working.

me too

still exists in the plesk extension as the extension only creates certificates for domain.tld and not for www.domain.tld

Its right. After update of the plesk ext the error still exist. It is not posible to creat the certificates for www.domain.tld

Pls open the issue again

"www" prefix fix had clashed with other functionality and had been rolled back in last minute before publication. We've another idea to add option and allow explicitly define if "www" prefix is needed or not. Please wait for fix in the future releases.

As a workaround for the extension use sudo -u psaadm bash /usr/local/psa/admin/plib/modules/letsencrypt/scripts/le-run -d domain.tld -d www.domain.tld
Do not run it without sudo, it becomes inoperable by Plesk.
The CLI interface is not pretty, we should improve it next version.
And sure the issue should be fixed in UI.

+1 for a fast fix. Same issue here.

+1 having the same problem

It works fine now

CLI workaround is working, thanks for the fix.
Looking forward seeing it in the UI.

The issue is completely fixed with checkbox in UI.
Check the extension version 1.1


Angular 9 support

Hey there,
I just updated ng-snotify to support Angular 6.1 to 9.x.
Semver
I matched ng-snotify version with Angular version :

6.0.0 matches Angular 6.1.x
7.0.0 matches Angular 7.2.x
8.0.2 matches Angular 8.2.x
9.0.0 matches Angular 9.x

What's new
There are no breakings changes to report. I did the best I could with the use of semver. I made a lot of changes that improves, in my opinion, the maintainability and organization of the repository.
Here is the list of changes made (I didn't add them in the changelog because it doesn't concern the library):
v6.0.0

add Angular 6.1 support
bump ng-snotify version to match angular version
bump node-sass to 4.13.1
replace HttpModule with HttpClientModule
update dependencies

v7.0.0

add Angular 7.x support
bump ng-snotify version to match angular version
update dependencies

v8.0.0

add Angular 8.x support
bump ng-snotify version to match angular version
update dependencies
fix gulpfile.js by adding compiler-cli
remove redundant JSDoc

v8.0.1

add ci configuration with puppeteer
update karma, jasmine, protractor

v8.0.2

use ng-packagr instead of gulp to build library
change folder organization :

application: previously in example is now in the src folder
library: previously in src folder is now in the projects/ng-snotify

update angular.json file to match with new folder organization
add husky to manage git hooks easily (configuration file: .huskyrc)
add prettier to check and format the source code (configuration file: .prettierrc)
add lint-staged to run arbitrary scripts against currently staged files (configuration file: .lintstagedrc)
add commitizen which is a command line utility that makes it easier to create commit messages following the conventional commit format specification (configuration file: .czrc)
Use git cz instead of git commit to use commitizen.
add commitlint to check if your commit messages meet the conventional commit format (configuration file: .commitlintrc)
update travis pipeline
reformat file names to match with kebab case
add cpx to copy assets (styles) in lib dist before packaging

v8.0.3

fix lib:build script

v9.0.0

add Angular 9.x support
bump ng-snotify version to match angular version
update dependencies
update ng-packagr configuration to copy assets
remove unused cpx dependency
fix sass files
add production configuration for ng-snotify library

#86 #85 #78 #

@smarlhens Thank you so much! I'll publish new version later this day

Hi just a quick question. in changing the directory in package json, ng-snotify is  currently on node_modules so the file path must be
file:node_modules/ng-snotify/dist/ng-snotify/ng-snotify-9.0.0.tgz.
still having an issue with ng snotify position. ive already posted. please let me know if i miss something.
Thank you
#angular9
#ng-snorify9. 0.0


MiniZip unzip.c hava some bug, it  need to be make modifications

//    if (len > UINT16_MAX)
//        return UNZ_PARAMERROR;
s->pfile_in_zip_read->stream.next_out = (Bytef*)buf;
s->pfile_in_zip_read->stream.avail_out = (uInt)len;

if (s->pfile_in_zip_read->raw)
{
    if (len > s->pfile_in_zip_read->rest_read_compressed + s->pfile_in_zip_read->stream.avail_in)
        s->pfile_in_zip_read->stream.avail_out = (uInt)s->pfile_in_zip_read->rest_read_compressed +
            s->pfile_in_zip_read->stream.avail_in;
}
else
{
    if (len > s->pfile_in_zip_read->rest_read_uncompressed)
        s->pfile_in_zip_read->stream.avail_out = (uInt)s->pfile_in_zip_read->rest_read_uncompressed;
}

@nmoinvaz Any word on this?

I don't see the problem. I am also not developing the old branch any longer. I will accept pull requests on it though.


Fix missing silent diagnostics

This fixes issue #691 for F# and C#

[x] F# errors noe always being reported

[x] F# warnings are not always being shown

[x] C# warnings are now always being shown

Basically two problems

Some F# evaluations were failing (error diangostics produced) but this wasn't being noticed

The C# and F# Kernels were pushing diagnostics through DiagnosticsProduced (which is for logging) but they should also be producing StandardErrorValueProduced (which is what Jupyter and others want for diagnostics).

I've checked things in Jupyter notebooks and the results are correct.

@jonsequitur This is an important fix for usability, as without it we can't tell when F# code is failing to parse/type-check correctly.

I don't think publishing diagnostics as StandardErrorProduced events is the right approach here.  Semantically, they're not standard error, and they are showing in VS Code.
Since Jupyter doesn't have a diagnostic concept, it sounds like within the Microsoft.DotNet.Interactive.Jupyter layer, we should consume DiagnosticsProduced events and publish them into one of Jupyter's channels.

Since Jupyter doesn't have a diagnostic concept, it sounds like within the Microsoft.DotNet.Interactive.Jupyter layer, we should consume DiagnosticsProduced events and publish them into one of Jupyter's channels.

Yes, ok, I can change it to do this

@jonsequitur I adjusted the fix to this, I believe more along the lines you wanted.
The DiagnosticsProduced event is now a DisplayEvent - it seems to fit well as the formatted errors are somewhat subtly different and belong well in FormattedValues.  This will also allow us to format the diagnotics as HTML sometime in the future.
I adjusted the Powershell kernel to populate this as well for the one place it produced DiagnosticsProduced.

@jonsequitur
The revised fix makes DiagnosticsProduced carry extra information for the formatted errors.  This is necessary because the formatted diagnostics we get from Roslyn/FCS vary somewhat from the simple ToString on the "Diagnostics" array in that event, e.g. they contain the error numbers and so on.  So we need to format the errors.  Previously we did that be slamming text into the failure message.   That's no good for warnings.
However adding this information changes the JSON contract for DiagnosticsProduced because extra information is now present. I think this is the right change because it's OK for extra values to be present in the JSON, even if it is ignored by the consumer (VSCode in this case)?
I've adjusted the JSON contract - thanks for the helpful messages about how to do that!

The DiagnosticsProduced event is now a DisplayEvent

I think this makes sense semantically. One thing worth discussing is a more explicit separation between display events that get stored in the .ipynb versus those that don't. Most language service events shouldn't, and while that mapping can live in the Jupter- and VS Code-specific layers, it does feel like an intrinsic difference that, though not very clearly modeled, has been erased by this change.
To sum up, prior to this change:

DisplayEvent types (which do get saved in the .ipynb file):

StandardErrorValueProduced
StandardOutputValueProduced
DisplayedValueProduced
ReturnValueProduced

Language services events (which don't get saved in the .ipynb file):

HoverTextProduced
CompletionsProduced
DiagnosticsProduced

Also, could you add a screen shot of the new output in Jupyter?

Can you post screenshots of what this experience looks like in both Jupyter and VS Code?  Otherwise I like it.

Can you post screenshots of what this experience looks like in both Jupyter and VS Code? Otherwise I like it.

C# warning in Jupyter

C# compilation error in Jupyter

C# Exception in VS Code

C# Warning in VS Code

Note, hover tip is correct
C# compilation error in VS Code

The F# ones are all the same
Note that in VS Code the compilation diagnostics show as red/yellow-squigglies and "Problems" but not in the status line after the attempted execution of the cell, which just shows Compilation error.  This could perhaps say "Compilation error - see diagnostics in 'Problems' tab" but that would need a fix in VS Code I think, it might be better if one of you made that.  I suppose the fix would be to add the extra message text here:
export function toVsCodeDiagnostic(diagnostic: Diagnostic): vscode.Diagnostic {
    return {
        range: convertToRange(diagnostic.linePositionSpan)!,
        message: diagnostic.message,
        severity: toDiagnosticSeverity(diagnostic.severity)
    };
}

OK I added that text on the status line

From chat with @jonsequitur
@dsyme says:

One query - the current PR suppresses DiagnosticsReported event when there are no diagnostics (Count = 0).  Is that right, or should we still be reporting that event ?

@jonsequitur says:

It's probably fine to not emit the event at that point. Question would be does the UI rely on an empty event to clear the prior diagnostics.

@dsyme says

And if not delivering a zero would force the IDE to flicker the errors (remove them all when a request is submitted)

Besides this issue this PR is ready

@jonsequitur @brettfo  I fixed this, so we now send empty diagnostics as before

One query - the current PR suppresses DiagnosticsReported event when there are no diagnostics (Count = 0). Is that right, or should we still be reporting that event ?

Note that in VS Code the compilation diagnostics show as red/yellow-squigglies and "Problems" but not in the status line after the attempted execution of the cell, which just shows Compilation error.

The current behavior shows the details of the compiler error in the output and I think we should likely keep that, since it prevents cell execution.
Similarly, I think the warning output in Jupyter is a bit alarming, because warnings should not prevent cell execution. We might consider using Display and some custom HTML styling (maybe with a ⚠ ) rather than the Jupyter error channel.

@jonsequitur OK I fixed the tests and adjusted the error text on the cell status error back in VS code

@jonsequitur this is ready I believe

I think this bears further discussion: https://github.com/dotnet/interactive/pull/713#issuecomment-674297962
If DiagnosticsProduced is going to be a DisplayEvent, which not e.g. HoverTextProduced?
Related to that, did you verify that these don't get saved into the .ipynb file?

If DiagnosticsProduced is going to be a DisplayEvent, which not e.g. HoverTextProduced?

To me such hierarchical classifications are meaningless and I don't particularly see their role.  What's the point of them?  My position is that imposing and maintaining hierarchical classifications is 98% a waste of time for the software industry :-)
Anyway I adjusted it to use DisplayEvent because, well, its Jupyter processing most resembles other DisplayEvents.  But we already have other cases where display events do and don't carry data and do/don't vary slightly.
I can take that away with a little extra code duplication, I don't think it matter, we should just get rid of DisplayEvent and friends altogether.

Related to that, did you verify that these don't get saved into the .ipynb file?

The warning diagnostics get saved in the ipynb as stream output, which I believe is what we'd expect:
    {
     "name": "stderr",
     "output_type": "stream",
     "text": [
      "\n",
      "input.fsx (1,1)-(1,36) typecheck warning This construct is deprecated. AppDomain.GetCurrentThreadId has been deprecated because it does not provide a stable Id when managed threads are running on fibers (aka lightweight threads). To get a stable identifier for a managed thread, use the ManagedThreadId property on Thread.  https://go.microsoft.com/fwlink/?linkid=14202\n",
      "\n"
     ]
    },

Anyway I adjusted it to use DisplayEvent because, well, its Jupyter processing most resembles other DisplayEvents. But we already have other cases where display events do and don't carry data and do/don't vary slightly.

(So please just tell me which way you'd like it - subclass of DisplayEvent or not - I don't think it matters too much either way)

The warning diagnostics get saved in the ipynb as stream output, which I believe is what we'd expect:

I think we would expect this when diagnostics arise from a code submission but not when they arise transiently while just typing.
While I agree that the DisplayEvent supertype is a bit of extra OOP goop, it currently represents a pragmatic behavioral distinction between what I think most people will generally regard as the "program output" (including console output, visualizations, cell return values), and "tooling" (editor features and language services). The host does ultimately own the handling of this distinction so removing DisplayEvent altogether would probably be the cleanest approach, but a good deal of host code for both Jupyter and VS Code will need to be reverified.
So in sum I would say let's not inherit DisplayEvent for now, with the plan to remove it in a future PR.

So in sum I would say let's not inherit DisplayEvent for now, with the plan to remove it in a future PR.

Okey dokey I'll change that

The warning diagnostics get saved in the ipynb as stream output, which I believe is what we'd expect:

I think we would expect this when diagnostics arise from a code submission but not when they arise transiently while just typing.

In Jupyter the waning diagnostics do only appear when the code is submitted for execution.
As an imperfect comparison point, when Python execution emits (dynamic) warnings then they are in the output streams, so:

gives:
   {
     "name": "stderr",
     "output_type": "stream",
     "text": [
      "c:\\users\\dsyme\\appdata\\local\\programs\\python\\python37-32\\lib\\site-packages\\ipykernel_launcher.py:4: UserWarning: This is a warning message\n",
      "  after removing the cwd from sys.path.\n"
     ]
    }

I mean, it's a dynamic warning not a compilation warning, but I think it's ok to regard compilation warnings in this way all in all

brettfo changed the base branch from master to main 1 hour ago

👍

@jonsequitur I updated the base class, please check the latest changes (and we need to check they go green)

it currently represents a pragmatic behavioral distinction between what I think most people will generally regard as the "program output" (including console output, visualizations, cell return values), and "tooling" (editor features and language services).

Right, diagnostics fall in this gap (outputs on stderr for Jupyter and command-line tools, outputs to tooling windows in IDE)
Anyway, updates are done, I'll be on vacation tomorrow so hopefully you can approve this tonight once it is green?

@jonsequitur Right, all greeen and ready

Yay, thanks!

Thank you, good sir.


expiration in deprecate_info frequently breaks release pipeline

When releasing Azure CLI, version bump PRs (such as https://github.com/Azure/azure-cli/pull/27790) are frequently broken by expiration in deprecate_info. Urgent fixes are required to unblock the release pipeline.

https://github.com/Azure/azure-cli/pull/18133
https://github.com/Azure/azure-cli/pull/21892
https://github.com/Azure/azure-cli/pull/25344
https://github.com/Azure/azure-cli/pull/25664
https://github.com/Azure/azure-cli/pull/26477

Possible solutions

Avoid using expiration in deprecate_info, so that version bump PR won't be affected by it.
Introduce detection in CI before version bump.

Thank you for opening this issue, we will look into it.


BUG: Tolerant intersection

This PR stops intersection from wrapping grids for the following situation:
The grid is being split in two at either edge due to the point being a value of (base + period).
This is not at all a neat solution but it yield the desired result.  Any alternate solutions are welcome.
Further context in #1662

Not sure why the travis build failed.

Thanks @cpelley - looks like you've got a solution which fits all of the existing tests and fits your requirements, nicely done!
I'm very conscious that this has added a lot of complexity to the determination of subsets, which essentially means that this will be the last time that anybody can fully grasp the subset computation comfortably in their head. For that reason, I think this needs a whole lot more commenting, documentation of the overall aim of subsets, and I would suggest splitting some of the indexing lines into sensibly named (aka self documenting) variable definitions.
Because of the complexity, I currently cannot be certain that you have tested all of the cases that you have added, so I will defer reviewing the tests until the logic is a little easier to review.
:+1: in principle on finding a solution to the problem, and I'm happy to help moving it forwards with this PR.

Thanks for your comment @pelson.  I'll make changes based on your comment ASAP.

Done, cheers @pelson, ready for review.

ping :)

ping x2
Is there anything stopping this PR from getting a look into?

This is still a complex, hard-to-follow change so a lot of my confidence in this change is going to come from the testing. (Hence the comments about untested code paths.)
It'd be great if Cube._intersect_modulus could be re-factored to break it down into "bite-size" functions... but if you don't have time for that then I'm OK with merging as it stands.

It'd be great if Cube._intersect_modulus could be re-factored

For example:
$ flake8 --max-complexity=10 lib/iris/cube.py
...
lib/iris/cube.py:2204:1: C901 'Cube._intersect_modulus' is too complex (17)
...

Thank you @rhattersley for your time on reviewing this.  I totally agree about the complexity, hence my description in the PR.  I'll certainly ensure complete test coverage as you have quite rightly suggested.  With regards to refactoring, I'll have a look to see if there are quick refactors possible without too much controversy.  I'll open a new ticket to capture this requirement if I don't think the refactor is complete (it certainly needs it as I found it difficult enough to follow the logic before I introduced my changes, let alone now).
flake8 - Nice, I didn't know about this tool.  I'll read up about what heuristics it uses to determine complexity.  Sounds VERY useful.
Cheers @rhattersley, I'll get back to you ASAP

I have added a test and modified an existing one so now both paths are tested.
Now looking at the possibility of a refactor, will let you know if I get anywhere ASAP

I have a made I think a pretty good refactor (makes a lot more sense now).
  Ready now.

You happy with the refactor @rhattersley ?
I think intersection should eventually be pulled out into its own module but I have approach the refactor from the perspective of increasing code clarity, simplification and removing duplication.  I think this approach is most important right now.

Thanks for the refactor. It's a definite improvement.
If you fix the typo and squash the commits I'm :+1: to merge.

Oops. Just realised it could do with a what's new entry. Feel free to leave it as a separate commit - whatever's easier.

Done, cheers @rhattersley


Introduce annotation literals for easy inline creation of annotations

I think we should introduce helper classes for users and integrators to be able to instantiate an annotation with given parameters programatically.
This is quite common in CDI, see for instance NamedLiteral qualifier (placed in separate class only because CDI doesn't "own" Named class, that javax.annotation)
or the @ApplicationScoped annotation which is not a qualifier. And many more...
CDI also offers a util class to easily implement this - AnnotationLiteral.
I think we could easily leverage that and have a nice QoL improvement.
For instance user wanting to get hold of a named ME instance via Instance object in CDI could then do Instance<Object>.select(ManagedExecutor.class, NamedInstance.NamedInstanceLiteral.of("myExec")) as opposed creating another anonymous class to be able to reference the qualifier from code.
Will send PR shortly.

+1, I had just made a helper method for this in OpenLiberty but having a spec-provided literal creator method will be nice

to be consistent with other CDI literals, I think the name should just be NamedInstance.Literal.of("myExec").  For example, all the qualifier annotations in javax.enterprise.inject follow the pattern of <CLASS>.Literal.INSTANCE

Not all of them, it varies based on whether the spec owns the annotation or not.
And ultimately it is a matter of choice, I am fine swapping it to just Literal.


Add support for background image layer at named maps

A definition for background layers with an image (options -> image is not empty at layer opts) is missing to be able to support them.
Up to you the format, if a new type, having a specific property instead of color, or any alternative you see best.
Relates to https://github.com/CartoDB/cartodb/issues/4130

Related to https://github.com/CartoDB/Windshaft/issues/269


No way to set default locale dynamically?

Do I have to set default locale in nuxt.config?
The case with my project is that the locale consists of both language and country.   i.e  en-UK
So I set defaultLocale to null in nuxt.config
I capture user country from their IP @ nuxtServerInit, and I try to dispatch i18n/setLocale, 'en-UK' right after.
Unfortunately app.i18n.locale always returns null, and the whole project just crashes.
Is there any way to achieve my goal with nuxt-i18n?

This question is available on Nuxt community (#c252)

Same problem. Anyone have solution?

There is feature request for it that should probably be re-opened #207

There is now setLocale API (in version 6.x) which might work for this (hopefully, depends on the order of things happening).


Add option to substitute on the target machine if local build

Signed-off-by: Magic_RB<EMAIL_ADDRESS>

Draft :)

Isn't using substitutors on the target machine inherently better, shouldn't that just be the default/always enabled?

thats up to mathew to decide

I've decided not to enable it by default, since it's too risky that the remote will have a low upload bandwidth. Part of the reason someone would want to build locally is because they don't want to be hampered by the remote, so it's best to leave this up to the user rather than decide for them.

This passed CI https://hercules-ci.com/github/MatthewCroughan/nixinate/jobs/37


[website] Use a responsive Sphinx theme

http://docs.libuv.org/en/v1.x/
Not an expert in Sphinx so I cannot help too much, but AFAIK there are responsive themes for Sphinx.
Or may be I'm the only who reads API documentations when traveling via subway :)

Site looks fine to me in mobile safari, text is nice and readable.
Then again my phone is huge so YMMV :)

This is NOT a responsive design. Two columns when in portrait mode is not "nice". Two completely different text sizes (in left and right column) is not "nice":

The "search" field and "GO" button are not usable:

The hyper mini "previous | next" buttons behind another layer (with print options) is not "nice" not even usable:

I'll see is there is a better theme we can use. I initially chose this one
because it's built-in and color-matches well with the logo.
On Apr 2, 2016 13:57, "Iñaki Baz Castillo"<EMAIL_ADDRESS>wrote:

http://docs.libuv.org/en/v1.x/
Not an expert in Sphinx so I cannot help too much, but AFAIK there are
responsive themes for Sphinx.
Or may be I'm the only who reads API documentations when traveling via
subway :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/libuv/libuv/issues/801

Check this one out: http://notes.saghul.net
On Apr 3, 2016 07:49, "Saúl Ibarra Corretgé"<EMAIL_ADDRESS>wrote:

I'll see is there is a better theme we can use. I initially chose this one
because it's built-in and color-matches well with the logo.
On Apr 2, 2016 13:57, "Iñaki Baz Castillo"<EMAIL_ADDRESS>wrote:

http://docs.libuv.org/en/v1.x/
Not an expert in Sphinx so I cannot help too much, but AFAIK there are
responsive themes for Sphinx.
Or may be I'm the only who reads API documentations when traveling via
subway :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/libuv/libuv/issues/801

http://notes.saghul.net

Looks ugly but seems responsive :)


Convert to use compose watch

This PR converts the project to use Compose Watch. A few notable points...

The Dockerfile introduces a few additional stages because we need to actually build the image with the source code in a dev-ready mode, rather than expecting the files to be present via the bind mounts
The Compose file dropped all bind mounts and swapped for watch config
Documentation (in Dockerfile, Compose file, and README) should all be updated

Feel free to clone, checkout the project, and validate it works for you. Thanks!

Tested it on Mac and works like a charm.
Watch enabled
Syncing "backend" after changes were detected
Syncing "client" after changes were detected


initialWorkingDirectory is not working with Hyper v3.0.0 (stable)

Updated Hyper to 3.0.0 (stable). I've noticed initialWorkingDirectory config is not picked up. Defaults to user directory.

I have noticed that a full reload (after opening hyper) will cause it to work.

@ecarlson94 It works but you have to do it every time you open Hyper.

yes, that "fixes" it for me as well, but it's pretty annoying.

for me, a full reload doesn't make it work.

#67

I am using Hyper 3.0.2

...and Full Reload woks for me:

Having the same issue with Powershell on Win10. The full reload seems to also fix an issue where splitting the screen doesn't always carry the cwd over.

I tried to pinpoint this issue and this is what I found: https://github.com/zeit/hyper/issues/3770
Bug seems to be located in hyper codebase, so there is nothing to fix here - but I suggest we still keep the issue open until it was fixed so people can find it easier here :)

If you switch to the canary release channel of Hyper, this bug is fixed 🎉
Open your Hyper preferences and set the updateChannel key to canary:
module.exports = {
  config: {
    // choose either `'stable'` for receiving highly polished,
    // or `'canary'` for less polished but more frequent updates
    updateChannel: 'canary',

    hypercwd: {
      initialWorkingDirectory: '~/dev'
    }
  }
}

Not working for me on Canary 3.0.2 on windows.
The full reload trick does work for me, but is obviously not ideal. :)

on macOS as of version 3.1.0-canary.4 the issue seems to be resolved.


Detect image base64 content by magic too

What happened?

lib
pic

svg

ink

resvg

What should have happened?

Files starting with /9j/4AAQSkZJRgABA should be interpreted as xlink:href="data:image/jpeg;base64,/9j/4AAQSkZJRgABA as firefox, chrome, inkscape, xwsvg, Qtsvg does it.

Copyright
source https://commons.wikimedia.org/wiki/File:Nauru-EEZ-fr.svg
author User:Kimdime
license https://en.wikipedia.org/wiki/Threshold_of_originality
Version and Operating System:

Inkscape Version: 0.92.4 or 1.1dev
resvg version: 0.9.0
rsvg Version: 2.40.21
Operating System: Ubuntu 18.04

confirm that it is fixed, thanks


Upgrade netty version in Ballerina

Purpose
$subject.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@222dd11). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master   #14324   +/-   ##
=========================================
  Coverage          ?   64.27%
  Complexity        ?      425
=========================================
  Files             ?     2187
  Lines             ?    96939
  Branches          ?    12967
=========================================
  Hits              ?    62309
  Misses            ?    29674
  Partials          ?     4956

Continue to review full report at Codecov.

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

I think we need to update the netty version in gradle also


watch.json not created

Describe the bug

I was trying to add anime to the list using anime watch --new but got an error showing that watch.json is not present and when I checked at the path C:\Users\USERNAME\AppData\Roaming\anime downloader, I only found config.json.
To reproduce

anime watch --new

LOG
C:\Users\USERNAME>anime watch --new
anime: anime-downloader 5.0.17
ERROR: [Errno 2] No such file or directory: 'C:\\Users\\USERNAME\\AppData\\Roaming\\anime downloader\\watch.json'

turns out it was already reported here but no fix was deployed.

Reinstall anime downloader from github, I think I fixed it.


CMake: make libebl independent of libdw

#2555 added a search for libebl into FindLibDw.cmake. The problem is that distros only provide libebl as a static library which makes the search for libdw fail when linking dynamically.
Since libebl is necessary for static builds only, this separates its search into FindLibEbl.cmake and require it from static builds.
In addition, libebl is not necessary on all systems (e.g. Alpine doesn't have it), so we make its requirement optional. This may cause some trouble when running a static build on a system with libdw but without libebl but since those two are usually packaged in the same package, that shouldn't occur often.

Checklist

[ ] Language changes are updated in man/adoc/bpftrace.adoc and if needed in docs/reference_guide.md
[ ] User-visible and non-trivial changes updated in CHANGELOG.md
[ ] The new behaviour is covered by tests

cc @haosdent


Raise exception when 'from_array' is given a dask array

[ ] Tests added / passed
[x] Passes black dask / flake8 dask

@jakirkham Let me know if you want a test. I don't see any from_array specific tests so not sure where the best place is.

Let me know if you want a test.

That would be great. Could you please add one in dask/array/tests/test_array_core.py?

I don't see any from_array specific tests so not sure where the best place is.

Hmm...that's concerning. Could you please raise an issue for this?

Ah I didn't realize the tests were separated that way. I was only looking in dask/tests. I'm sure there are from_array tests in dask/array/tests/.

Yeah, if you search for def test_from_array_*, there are a few different cases tested. They are a bit scattered though.

So test was added but there is one failure in dask/array/tests/test_optimization.py:test_gh3937. The issue is that asarray is given a list of dask arrays. asarray looks like:
    if isinstance(a, Array):
        return a
    elif hasattr(a, "to_dask_array"):
        return a.to_dask_array()
    elif isinstance(a, (list, tuple)) and any(isinstance(i, Array) for i in a):
        a = stack(a)
    elif not isinstance(getattr(a, "shape", None), Iterable):
        a = np.asarray(a)
    return from_array(a, chunks=a.shape, getitem=getter_inline, **kwargs)

This will hit the stack if statement which will convert everything to a dask array which it then passes to from_array.

Where is it calling from_array in stack?

Could we just move that from_array into the else case? I don't think any other case needs it.

We could, but then chunks, getitem, and **kwargs are not being used.

They don't seem to be used by anything else anyways.

The following seems to pass tests for me locally
diff --git a/dask/array/core.py b/dask/array/core.py
index bb40549c..286dbcbc 100644
--- a/dask/array/core.py
+++ b/dask/array/core.py
@@ -3580,7 +3580,7 @@ def asarray(a, **kwargs):
     elif hasattr(a, "to_dask_array"):
         return a.to_dask_array()
     elif isinstance(a, (list, tuple)) and any(isinstance(i, Array) for i in a):
-        a = stack(a)
+        return stack(a)
     elif not isinstance(getattr(a, "shape", None), Iterable):
         a = np.asarray(a)
     return from_array(a, chunks=a.shape, getitem=getter_inline, **kwargs)

Yeah I think the application of from_array to anything other than the result of np.asarray here is unintentional. It's probably best for us to go ahead and clean that up now to avoid similar mistakes in the future.

Sounds good. Done. Thanks @jrbourbeau.

Thanks @djhoese! 😄


Retrieving synced blocks from blocks.log

Problem:
I've synced up my local nodeos (running in a docker container) to the Mainnet and would like to inspect the actual data that's on each block/transaction/action. One way to do this would be through rpc calls, but doing this for millions of blocks is very slow (even with pool/async etc).
Question:
Is it possible to work directly with the blocks.log file that's written during the syncing process? By blocks.log I'm referring to the 30GB+ file that lives in /root/.local/share/eosio/nodeos/data/. If so, how should I read (wrt encoding and file handling) the .log file if I'm working in python?
Any pointers would be greatly appreciated. Thanks!

It's always possible to interpret the blocks.log file, but it would be considerably difficult to do so in Python.  You would have to replicate the entirety of fc library variants for the fundamental types, then create Python struct interpretations of every block-related class, including packed transactions and blocks themselves.
It would be considerably easier to enable the mongo_db_plugin, replay your chain, and query your mongodb.
If you're really determined to read the file yourself, start with eos/libraries/chain/block_log.cpp and work your way through the append() method and everything it invokes to serialize a block.


How do you iterate the streams ?

The Context struct returns just the pointer to the stream which is the first element in the streams array.
Is there a way to just return a slice instead

sounds like I want to do something like:
func (ctxt *Context) Streams(i uint) *Stream {
	offset := (unsafe.Sizeof(unsafe.Pointer(ctxt.streams)) * uintptr(i))
	return (* Stream)(unsafe.Pointer(uintptr(unsafe.Pointer(ctxt.streams)) + offset ))
}

but this seems to return garbage data

I'm aware of the issues with the repo. I will attend to them when I get some time. Thanks for the pull requests.

@giorgisio  thanks for merging. I don't do much golang so please look over the changes if they are idiomatic. I'm just working on some Ffmpeg stuff and thought it would be nicer to work in Golang.
Thanks for the head start on the work here.
It would be cool if could figure out how to just return a slice https://github.com/golang/go/wiki/cgo#turning-c-arrays-into-go-slices
As that would be way simpler to work with.
I'll spend some more time on it.


ValidationError doesn't fail with exit code 1

Prerequisites

[x] I have checked the existing issues to ensure this is not a duplicate.
[x] I am running the latest version of Tailcall.

Describe the bug
TC server when pointed to an invalid file, throws an validation error but exits with status code 0.
Steps to reproduce

Create the following file test.graphql
schema @schema {
  query: Query
}

type Query {
  users: [User] @http(path: "/users")
}

Run the check command on the file
  tc check ./assets/jsonplaceholder.graphql
  Validation Error
    • No base URL defined [Query, users, @http]

  echo $?
  0 # should be 1

Expected behavior
Fail with exit code Err.
Actual behavior
Fails with exit code OK.
Environment information:

Operating System: All
Tailcall Version: 0.9.0
GraphQL Client/version NA

Additional context
Learn more about exit codes here — https://rust-cli.github.io/book/in-depth/exit-code.html
**

/bounty $50

/bounty $50

/attempt #333

@tusharmath what exit code would you like it to emit?

/attempt #333

@ayewo we could use 78. We could use the exit code crate for this also — https://docs.rs/exitcode/latest/src/exitcode/lib.rs.html#89

@tusharmath
I'm curious which style of working is your project adopting with Algora:

let the first contributor that uses the /attempt command to work on an issue; or
let anyone attempt an issue right away. Multiple contributors can use the /attempt command.

The upside of style 2 is that you get multiple contributions on a single issue (as is the case here) but you only pay one person. The downside for contributors obviously is that if their work is not accepted they get nothing for their time.
FWIW, the Remotion project uses style 1 which avoids the scenario described in style 2.

I would prefer one.

Bounties at this price range and difficulty generally are style 2

Agree with @kremedev

Bounties at this price range and difficulty generally are style 2

Nope, this is not codified anywhere. The style of working is entirely up to each project to decide which is why I asked to confirm.

I'm just telling what I have seen so far

fixed in #336


Do not emit BOM for UTF-8 (Solve #88)

Actually someone else needs to decide, i'm not in the D−YAML team.

i'm not in the D−YAML team.

Now you are.
@majiang any chance you can add a test for this?

I can write somewhere a unittest which writes to a temporary file and assert its content, will it be enough? I don't understand how tests are done for this project enough.


Request bundle: @crawlo/graphql

NPM package name
@crawlo/graphql
Version
latest
External that exclude from bundle, separated by comma (for example "pg-native,pg-android")
No response
Bundler
esbuild
Bundle options

[X] minify

Package @crawlo/graphql@latest has been published:
https://www.npmjs.com/package/@autobundle/crawlo_graphql
Bundle size: 261 kB
We are going to close this request, please reopen if have any issue


Fixes are disabled for VR

We only have a working crashlogger. We need to start fixing all the patches.
PS E:\Documents\source\repos\vr_address_tools> python .\vr_address_tools.py -f ..\buffout4 analyze -d
Unable to read ..\buffout4\buildvr\vcpkg_installed\x64-windows-static-md\include\fmt/chrono.h:  'charmap' codec can't decode byte 0x8d in position 4172: character maps to <undefined>
Finished scanning 5,486 files. rel_ids: 0 offsets: 0 results: 83
92771,0x142861af0,,1,src\Patches/BSMTAManagerPatch.h:97
224250,0x141d17460,,1,src\Fixes/CreateD3DAndSwapChainFix.cpp:35
274004,0x146722280,,1,src\Patches/BSPreCulledObjectsPatch.h:274
367479,0x141d4aaa0,,1,src\Warnings/CreateTexture2DWarning.cpp:114
405150,0x140b933b0,,1,src\Patches/InputSwitchPatch.cpp:100
410310,0x14280a3c0,,1,src\Patches/BSPreCulledObjectsPatch.h:406
446402,0x1467222c0,,1,src\Patches/BSPreCulledObjectsPatch.h:279
450339,0x1458e08a0,,1,src\Patches/WorkshopMenuPatch.h:560
643948,0x140b935c0,,1,src\Patches/InputSwitchPatch.h:194
678241,0x141d49fa0,,1,src\Warnings/CreateTexture2DWarning.cpp:98
678816,0x1458e0460,,1,src\Patches/WorkshopMenuPatch.h:294
712982,0x140b93020,,1,src\Patches/InputSwitchPatch.h:200
713154,0x146722290,,1,src\Patches/BSPreCulledObjectsPatch.h:273
768994,0x1428bbb10,,1,src\Fixes/UnalignedLoadFix.h:22
768994,0x1428bbb10,,1,src\Fixes/UtilityShaderFix.h:19
932019,0x146722298,,1,src\Patches/BSPreCulledObjectsPatch.h:275
997287,0x142809ee0,,1,src\Patches/BSPreCulledObjectsPatch.h:398
1104804,0x1467222d8,,1,src\Patches/BSPreCulledObjectsPatch.h:278
1142692,0x14280a160,,1,src\Patches/BSPreCulledObjectsPatch.h:414
1167260,0x14280a690,,1,src\Patches/BSPreCulledObjectsPatch.h:271
1252712,0x1438c7888,,1,src\Patches/BSPreCulledObjectsPatch.h:281
1514918,0x1458e0818,,1,src\Patches/WorkshopMenuPatch.h:562
1581182,0x1458df7a8,,1,src\Patches/WorkshopMenuPatch.h:302
Found 23 items

Update after latest address finds:
PS E:\Documents\source\repos\vr_address_tools> python .\vr_address_tools.py -f ..\Buffout4\ analyze -d
Finished scanning 62 files. rel_ids: 0 offsets: 0 results: 85
92771,0x142861af0,,1,src\Patches/BSMTAManagerPatch.h:97
274004,0x146722280,,1,src\Patches/BSPreCulledObjectsPatch.h:274
405150,0x140b933b0,,1,src\Patches/InputSwitchPatch.cpp:100
410310,0x14280a3c0,,1,src\Patches/BSPreCulledObjectsPatch.h:406
450339,0x1458e08a0,,1,src\Patches/WorkshopMenuPatch.h:560
643948,0x140b935c0,,1,src\Patches/InputSwitchPatch.h:194
712982,0x140b93020,,1,src\Patches/InputSwitchPatch.h:200
713154,0x146722290,,1,src\Patches/BSPreCulledObjectsPatch.h:273
932019,0x146722298,,1,src\Patches/BSPreCulledObjectsPatch.h:275
997287,0x142809ee0,,1,src\Patches/BSPreCulledObjectsPatch.h:398
1104804,0x1467222d8,,1,src\Patches/BSPreCulledObjectsPatch.h:278
1142692,0x14280a160,,1,src\Patches/BSPreCulledObjectsPatch.h:414
1167260,0x14280a690,,1,src\Patches/BSPreCulledObjectsPatch.h:271
1252712,0x1438c7888,,1,src\Patches/BSPreCulledObjectsPatch.h:281
1514918,0x1458e0818,,1,src\Patches/WorkshopMenuPatch.h:562
1581182,0x1458df7a8,,1,src\Patches/WorkshopMenuPatch.h:302```

Finished scanning 65 files. rel_ids: 0 offsets: 0 results: 94
53721,0x140f46000,0x140fc43e0,1,src\Patches/InputSwitchPatch.h:263
92771,0x142861af0,,1,src\Patches/BSMTAManagerPatch.h:97
231868,0x14039abe0,0x140381310,1,src\Warnings/ImageSpaceAdapterWarning.cpp:53
274004,0x146722280,,1,src\Patches/BSPreCulledObjectsPatch.h:274
405150,0x140b933b0,,1,src\Patches/InputSwitchPatch.cpp:58
410310,0x14280a3c0,,1,src\Patches/BSPreCulledObjectsPatch.h:406
446402,0x1467222c0,,1,src\Patches/BSPreCulledObjectsPatch.h:279
450339,0x1458e08a0,,1,src\Patches/WorkshopMenuPatch.h:497
643948,0x140b935c0,,1,src\Patches/InputSwitchPatch.h:194
678816,0x1458e0460,,1,src\Patches/WorkshopMenuPatch.h:294
712982,0x140b93020,,1,src\Patches/InputSwitchPatch.h:200
713154,0x146722290,,1,src\Patches/BSPreCulledObjectsPatch.h:273
768994,0x1428bbb10,,1,void Install src\Fixes/UtilityShaderFix.h:19
768994,0x1428bbb10,,1,void Install src\Fixes/UnalignedLoadFix.h:23
887475,0x14280a7e0,0x1427e1940,1,src\Patches/BSPreCulledObjectsPatch.h:269
932019,0x146722298,,1,src\Patches/BSPreCulledObjectsPatch.h:275
997287,0x142809ee0,,1,src\Patches/BSPreCulledObjectsPatch.h:398
1104804,0x1467222d8,,1,src\Patches/BSPreCulledObjectsPatch.h:278
1142692,0x14280a160,,1,src\Patches/BSPreCulledObjectsPatch.h:414
1167260,0x14280a690,,1,src\Patches/BSPreCulledObjectsPatch.h:271
1252712,0x1438c7888,,1,src\Patches/BSPreCulledObjectsPatch.h:281
1349441,0x140b397a0,0x140b5bab0,1,src\Patches/InputSwitchPatch.h:261
1514918,0x1458e0818,,1,src\Patches/WorkshopMenuPatch.h:499
1581182,0x1458df7a8,,1,src\Patches/WorkshopMenuPatch.h:302
Found 24 items


Agency show page should not include empty fields

simple conditionals in the view will fix this.

fixed on production.


Remove checks of worksheet name when uploading Actuals.

The worksheet name changes with different ways of saving the Oracle report.
There is no risk in removing this checks, because there are several other robust checks when the worksheet is read.


Add/Update the relevant smart contracts (create AdminSpokeConnector, etc), deploy them to dev-net, run the deploy script against dev-net.

Deploy contracts to tenderly devnet, and use AdminConnector to bypass AMB stuff
ToDo list

[ ] forge deploy script structure
[ ] deploy connext diamond
[ ] deploy messaging contracts

Integrating forge-deploy package into monorepo to deploy contracts to devnet.

Still working through deployment using forge-deploy.


CT Checkpoint updater

Towards #88
CT checkpoints contain a timestamp, used amongst other things, to measure CT logs MMD. That means that a checkpoint needs to be updated every X amount of time, irregardless of whether or not new entries have been integrated.
Today, Tessera only updates checkpoints (with a new timestamp) when new entries are integrated. We need a new mechanism to allow CT logs to update their checkpoints, even if no new entries have been integrated.
Option 1: Support this in personalities only, with a fully decoupled checkpoint writer.

That means that there will be at least two checkpoints writer: one from Tessera, one from the personality. We need a mechanism to ensure that Tessera's and the personality's checkpoint writers don't step on each other. Otherwise, a personality checkpoint writer might rollback a Tessera checkpoint update.

For buckety storage systems supporting preconditions, we could rely on preconditions
For non buckety storage systems, that might be more of a problem, and might require the personality to get a lock on Tessera's internal storage systems.

Another downside is that a personality would have to fiddle with Tessera's internal storage, which, even if it's just the checkpoint, isn't great.
If there are multiple servers, there will be multiple Tessera checkpoints writers as well, which is fine since Tessera make sure that they don't step on one another.
There would also be multiple personality checkpoints, but it's less of a problem if these step over each other. They could be staggered over time for instance. Otherwise, preconditions - when they are a feature, would help.

Option 2: Support this as a Tessera option

This is really a CT requirement (other checkpoints don't include timestamps), so it should probably be a ct_only option.
Every Tessera storage system implementation would implement its own updater, and handle locks, shall they want to support this option. We might be able to provide a mixin, but it's not 100% straightforward.

Tessera's Alpha release will support CT on AWS and GCP, both of which use buckety storage systems, and allow for preconditions (as of a few days for AWS! https://aws.amazon.com/about-aws/whats-new/2024/08/amazon-s3-conditional-writes/). So option 1 should be enough to start with. But given the known limitations, we might as well go for option 2 directly?
I'm happy to work on either implementation, but I'm interested to know what others think about this.

I'll just float an in-between option:
Option 3

Tessera has a function CreateCheckpoint()
Personalities can call this at whatever interval their policy dictates where a new checkpoint needs to be created

I'm not in love with this option, but it avoids the personality needing to own the write logic for checkpoints (option 1), and it avoids business policy logic needing to find its way into Tessera (option 2).

I'm not a fan of these options as they stand:

Breaks the division of responsibilities between Tessera and the personality (Tessera owns the checkpoint resource) and is a layering violation (personalities should not have to know details of how writes are accomplished in the relevant Tessera storage backend).

As you say, this pushes complexity into Tessera which shouldn't be there as it's a CT thing.

Another option could be to expose method which personalities can use to request a new checkpoint to be generated. e.g. Integrate(force bool) which triggers an immediate integration (rather than waiting for the next scheduled one), and passing true requests that a new checkpoint is written even if the tree doesn't grow as a result of the integrate.

Do you mean exposing this as a Tessera API on top of Add()?  Why would we want to export this method for all clients, if the only use case is CT?


Incorrect rendering of an escaped asterisk within emphasis block

-- https://docs.microsoft.com/en-us/uwp/winrt-cref/winrt-type-system
Markdown and CommonMark specs seem to agree that backslash escapes should work in this case:

https://daringfireball.net/projects/markdown/syntax#backslash
https://spec.commonmark.org/0.28/#backslash-escapes

cc @dend @mairaw

@cillroy something you can take a look at?

It seems to have been fixed since then.


Rename asyncop.cpp to task.cpp

@jasonsandlin,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot