Autocrafting a RS interface fails while running with the latest (beta 1.10-1.10.2-1.2.1) DW20 mod pack.

Issue description:
The autocrafting system is getting stuck into the "Machine in use" phase while trying to craft the RS interface on a Crafter+Solderer.
What happens:
The crafting monitor says: Machine in use.
What you expected to happen:
The autocrafting should go through and create the interface.
Steps to reproduce:

Setup a basic RS storage configuration (controller, grid, disk storage+disk, crafting monitor).
Connect a Crafter+solderer and add an interface pattern into the crafter.
Provide the RS system with an importer, and exporter and a basic processor.
Request an interface.

Version (Make sure you are on the latest version before reporting):

Minecraft: 1.10.2
Forge: <IP_ADDRESS>5
Refined Storage: 1.2.14
DW20 mod pack: 1.10-1.2.1-1.10.2 (beta)

Does this issue occur on a server? no
It should be noted that this issue only occurs in the DW20 pack. The crafting is working fine in a MC+RS build.

Having the same issue on 1.11. It can insert to an empty chest, but not to a vanilla furnace, then it just says "machine in use".

maybe it is side orientated?

@Joshwoo70, I tried it with the top and one of the sides. If you think it might be related I can try the rest of the sides and the bottom. Also, I should mention that this only happens with the interface, everything else that I autocraft works as expected. I will try to pinpoint the exact mod(s), if any, that are introducing this behavior and get back to you.

I can't reproduce it any more. It might be fixed in one of the other commits I made today.


structured extraction docs + bug fixes

made some basic edits on structured extraction to highlight starter guide
also fixed async

@jerryjliu you should install pre-commit :)


Find a new keybinding to launch OmniSharp from atom

From the 0.190 release notes:

There is now an application:add-project-folder command to add a project folder to the current window. It is bound to Cmd-Shift-O on Mac and Ctrl-Alt-O on Linux and Windows. You can also access it from the File menu
Source

It is probably poor form to override the editors own keybindings. After a quick test it seems OmniSharp "wins", so it still starts with Ctrl-Alt-O. Disable the omnisharp-atom plugin and Ctrl-Alt-O starts adding project folders as expected.
Could also be solved by automatically starting OmniSharp. :wink:

Here's a screenshot of the keybindings settings page. We'll definitely need to make the change at some stage.

If we still want to use O to represent OmniSharp. Perhaps we could change it to ctrl-alt-shift-o? So the change is an additional shift key press.

Perhaps if #123 gets addressed, we may no longer need to start it manually.

We should probably still address this fairly soon.  What combination do we want to use?

The keybind ctrl-alt-o has no effect at all on linux. I have to use the menu to toggle the server.

What about just alt-o? Or ctrl-shift-o ?
:+1: on addressing this soon.

I like ctrl-shift-o

ctrl-shift-o opens a folder on Windows/Linux.
https://github.com/atom/atom/blob/master/keymaps/win32.cson#L17

We have auto-start enabled in v0.4.5 now. So this is only going to be an issue when auto start is disabled

Sooo funnily enough, now that we have a dependency on atom-yeoman, it too uses ctrl-alt-o, which ironically means it breaks our toggler.

@david-driscoll should change the binding on atom-yeoman :tongue:

yeah... I should.

It should be done now.


Demo in the source of 0.10.0 is not working properly

Hey,
when I download the zip of the source code and compile the less file, then the demo is not working properly.
The month view of the calendar is not actually opened, you need to start clicking between the week, day, etc views to get the calendar shown.
It was like that even before the release, while looking at the top of the master branch.
Downloading and testing the demo in the code of 0.9.2 works fine.

The demo is running 0.10.0 fine. Please can you upload your code that reproduces the bug you are experiencing to a plunkr or something similar. Thanks.

Hey, thanks for the reply. Figured out the problem:
In the index.html the following prevents the calendar from initial display:
<style type="text/css">
      [ng-cloak] {
        display: none;
      }
</style>

Hey,
Thanks for the answer.
I am talking about the index.html in the source code.
It does not load as described above when using all the default multiple js includes:

    <script src="src/directives/mwlCalendar.js"></script>

    <script src="src/filters/calendarTruncateEventTitle.js"></script>

    <script src="src/filters/calendarLimitTo.js"></script>

    <script src="src/services/calendarConfig.js"></script>

    <script src="src/services/calendarTitle.js"></script>

    <script src="src/services/calendarHelper.js"></script>

    <script src="src/services/calendarDebounce.js"></script>

    <script src="src/services/moment.js"></script>

    <script src="src/directives/mwlCollapseFallback.js"></script>

    <script src="src/directives/mwlDateModifier.js"></script>

    <script src="src/directives/mwlCalendarYear.js"></script>

    <script src="src/directives/mwlCalendarMonth.js"></script>

    <script src="src/directives/mwlCalendarWeek.js"></script>

    <script src="src/directives/mwlCalendarDay.js"></script>

    <script src="src/directives/mwlCalendarSlideBox.js"></script>```

It only works when using the provided builded file, which is not what I'm looking for:

`<script src="dist/js/angular-bootstrap-calendar-tpls.js"></script>`

Thanks for your time.

Using the source files is only really meant for development purposes, I don't quite get what your use case it for directly using the source files. At a guess I'd say it's because your directive template paths are wrong, does src/templates exist in your path? Without a plunker that reproduces your problem there isn't much I can do to help.

Hello, this plunker shows the non closing item (working fine in 0.9.2).
PS : I made the few changes of event mapping to match the new version

@anthonyvialleton I've created a new issue for your problem. By default the calendar will auto open the current date. You can stop this behaviour by setting auto-open="false" on the calendar.

Perfect! And what for your Demo and the plunker ?

It will be fixed in 0.10.1

My issue is reproducing when referencing the templates by filename, rather than being in the template cache. Exactly what is happening in the index.html in the source.

Does the src/templates path actually exist and point to the directive templates? A plunker would really be helpful to show me what you mean otherwise I'm just guessing.

Closing as this has gone stale. If you can provide a plunker then I'll happily assist in helping you otherwise there's not much I can do and no one else is getting this problem.


Add ability for topmodel's index page read from a "subdirectory" of an S3 bucket

r? @jocelynsarah

lgtm


[Core] Clipboard not working in 1.9

Hi everyone,
I noticed my clipboard functionality stopped working and managed to verify it with this simple script:
from kivy.core.clipboard import Clipboard
print Clipboard.get_types()
Clipboard.put('Great', 'text/plain')
print Clipboard.get('text/plain')

The output:
>>> text/plain
>>> None

(Also note that get_types() actually seems to return a string here, rather than a list.)
Kivy: 1.9 dev, new packaging build by @tito
Provider: [Clipboard   ] Provider: sdl2(['clipboard_nspaste'] ignored)
Possibly related task (?): #2743
Thanks as always,
Patrick

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/9678247-core-clipboard-not-working-in-1-9?utm_campaign=plugin&utm_content=tracker%2F42681&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F42681&utm_medium=issues&utm_source=github).

This seems to be because the sdl2 clipboard is almost just a dummy provider though the basic functions are implemented. I'll take a look.

Okay, the direct issue is that the sdl2 clipboard doesn't implement get and put, just copy and paste - these are the intended interface. However, I get segfaults when calling these.

closed via https://github.com/kivy/kivy/commit/ea615a4f60ffcd49e5580438532355c296061ed6


KTX loading incorrectly ignores srgb meta data

When loading KTX files that contain RGBA_SRGB data, parseFnT in image.cpp will correctly identify the srgb type and set it to true. However, the next step in imageParseT creates the output image container and makes no effort to copy this parameter to the output image. The contents of the file are loaded using memcpys, so no data transform occurs, the meta data is simply lost.
if (!parseFnT(imageContainer, &reader, _err) )        /// <<< ======= image container has srgb set
{
	return NULL;
}

ImageContainer* output = imageAlloc(_allocator        /// <<< ======= output does not
	, imageContainer.m_format
	, uint16_t(imageContainer.m_width)
	, uint16_t(imageContainer.m_height)
	, uint16_t(imageContainer.m_depth)
	, imageContainer.m_numLayers
	, imageContainer.m_cubeMap
	, 1 < imageContainer.m_numMips
);

Locally, I've added:

Looks fine. Send PR.


Reproducing the published results

I would like to know which data should I use to reproduce the results in Table 4, first column (nu = 1.e-3, T=50, N=1000) of ref https://www.jmlr.org/papers/volume24/21-1524/21-1524.pdf. By looking at https://drive.google.com/drive/folders/1UnbQh2WWc6knEHbLn-ZaXrKUZhp7pjt- , I presume I have to use NavierStokes_V1e-3_N5000_T50 and split the dataset in 1000 train and 4000 test elements. Is that correct?
Also, I noticed in master for fourier_3d.py you have added an MLP layer and removed the batch-norm. is that the same network configuration used in the above paper?

Sorry for the delay. In the paper we used 1000 for training and next 1000 for test. In original paper we didn't have MLP, it is added for better performance.


Entities leave group on ReplaceComponent

Hi, thank you for this very useful framework.
I started experimenting with this philosophy recently and got stuck on a simple task.
I have a PositionComponent defining a group (of all entities with such component) and a System adding/removing a GameObject view whenever an entity enters/exits this group.
The system does so registering callbacks on the group's OnEntityAdded/OnEntityRemoved;
Now, to move the entity, I replace the PositionComponent, but since "replace" actually destroys and recreates, the entity leaves and re-enters the group, causing the GameObject to be destroyed and re-instantiated.
I am actually pooling the GameObject but even just activating/deactivating has some unnecessary footprint.
Also, I find counter-intuitive that updating a position causes the entity to leave the group of "movable entities".
Studying the source, I couldn't find a clean way to listen only OnEntityUpdated (and no OnEntityAdded/OnEntityRemoved) when the component is being replaced.
Nor a way to avoid the entity leaving it's group.
Can this be done or am I blind to the correct phisolophy?
Thanks in advance for your help.

Hi,
I would suggest to listen for OnEntityAdded only and define a second Component for destroying. If OnEntityAdded is called, you proof for a view and if there isn't one you add it. You can do adding and destroying with very simple ReactiveSystems.

What you suggested is actually what I'm currently doing but creating a new component (and system) seemed more like a workaround than the intended way to do such a simple thing.
Searching more on the web I found one of the developer proving me wrong.
Thanks a lot for your answer.


landed in an un-syncable state

Was trying out this app for the first time, made like a test thingy in my local machine. Took the docker-compose file from #7 and it worked well for a while. The locally kept files synced with the docker ones, persisted between restarts as well. But after a few changes, seems like I landed in this un-syncable state where I've lost a few set of rows & this doesn't sync anymore.
Exporting and importing doesn't work as well. Any suggestions?
https://user-images.githubusercontent.com/8632659/166166160-ae0c02f0-78b2-4d65-9007-955d4082f063.mov
Note: This has nothing to do w/ the PR - I just wanted to clarify I used it NOT from master.

I had the same issue - opening the app in an incognito/private session (so it didn't use the cache, etc) fixed it and things looked good for me. Since it all was good, I just cleared cache/cookies on my non-incognito window and re-opened Actual's web UI and logged back in. Once done, I was all set to go again.

@SlothCroissant, you're right! Clearing the indexed db for actually get rid of the error at least, but I've do have lost considerable amount of entries, not sure where the sync messed up for me 😭

So, I cp-ed some of the older timestamped backups to db.sqlite to see if I could recover my lost data, but that didn't work.
Just wanna not lose this again - does anyone know which files to safely to store so it behaves like a backup all the time?
ls -l user-files/110d687f-4db8-4d3f-b9c6-d87652e8c25a/*
-rw-r--r--  1 me  staff  389120 May  1 16:46 user-files/110d687f-4db8-4d3f-b9c6-d87652e8c25a/cache.sqlite
-rw-rw-rw-  1 me  staff  380928 May  1 16:46 user-files/110d687f-4db8-4d3f-b9c6-d87652e8c25a/db.sqlite
-rw-r--r--  1 me  staff  380928 May  1 16:39 user-files/110d687f-4db8-4d3f-b9c6-d87652e8c25a/db.sqlite.bk
-rw-rw-rw-  1 me  staff     480 May  1 16:41 user-files/110d687f-4db8-4d3f-b9c6-d87652e8c25a/metadata.json

user-files/110d687f-4db8-4d3f-b9c6-d87652e8c25a/backups:
total 2232
-rw-r--r--  1 me  staff  380928 May  1 14:52 29213a23-b484-42c1-957b-296efdd06e36.sqlite
-rw-r--r--  1 me  staff  380928 May  1 16:35 54228c6a-1a17-479e-bcfa-e0777848d691.sqlite
-rw-r--r--  1 me  staff  380928 May  1 15:07 f06437b8-1da3-47a2-bad5-15745d2a922d.sqlite

I've landed myself into the same state as @dixitk13 so I am very interested in the recovery process too 👀

Hmm. The desktop app has automatic backups. That's what is nice about the desktop app -- it's all just normal files so that's easy to do.
Backups on the server is very new and not super well-tested.
This version of the server is also not as well-tested as the closed source one. I would LOVE any help debugging this. If you are a developer and in this state, can you help?
Resetting sync should always work. What it does is call this method to upload a "user file": https://github.com/actualbudget/actual-server/blob/master/app-sync.js#L226
That overwrite the "base" version of your file on the server and creates a new "sync group". From then on, you can start syncing again. It's basically a "fresh start" when it comes to syncing and should fix any problems. Had no problem with this in the closed-source server.
I would add some logging in that method and see what's happening. Any errors in the console? Any errors in the server? etc

OH, I'm pretty sure I know what this is. Also see:
https://github.com/actualbudget/actual-server/issues/15
This is all due to the server not serving the app with the right headers. It's not enabling SharedArrayBuffer so it's using an old really unstable code path. I'll look into this soon

Particularly https://github.com/actualbudget/actual-server/issues/23#issuecomment-1115675099

Hey @dixitk13
This should be fixed in version 20.10.25 which is our latest version. If you still have issues with this, let me know and I will re-open your issue.
Cheers
Rich


Default branch name -> "main"

As a policy, the Bytecode Alliance is changing the default branch names in all repositories, to be more inclusive. We would like for all projects to rename the default branch to main by June 26. (We mention June 26 because there is some suggestion that GitHub may be adding the ability to make this process more seamless, particularly for people with current checkouts. We're willing to wait for the availability of that feature, but not indefinitely, hence the June 26 timeline.) This is a tracking issue.

[x] Change branch name, remove old branch (and change GitHub default branch)
[x] Update any build scripts or CI scripts that reference the old default branch name
[x] Update documentation

Done in commit 548926ab1a483b397ceee3cc6e5c027b8c1d8a49.


Add back load_tmx_map_from()

Hi! I'm trying out Bevy and (similar Amethyst) it passes a &[u8] to load the file. As of version 0.11, I have no idea how can load maps as implementing ResourceReader for loading from byte arrays would have to be intricate to then be able to load the remaining files from disk.
Is there any chance to add back this super useful method? If not, how can I load the main tmx from bytes and the rest of the files using FilesystemResourceReader?

In the bevy_ecs_tilemap crate, somebody introduced a BytesResourceReader, see https://github.com/StarArawn/bevy_ecs_tilemap/pull/425. Does that help or would you still suggest we should add back load_tmx_map_from?

Huh, I guess I should've gone to the main branch before posting this. That along with what's in #265 is a good enough solution to me. I still don't see why the helper method had to go, but at least there's a reasonable alternative. Thanks!

I still don't see why the helper method had to go, but at least there's a reasonable alternative. Thanks!

load_..._from was a hacky method to only load completely embedded maps from some source. That is still possible in 0.11, it's just a bit more manual work. Perhaps we could add it back as the BytesResourceReader solution.

Personally, it wouldn't do much good unless it would support supplying another ResourceReader for the remainder of files. I know I asked how I could use it with the FilesystemResourceReader, but since I can easily use a more portable solution from the beginning, I prefer portability.

Personally, it wouldn't do much good unless it would support supplying another ResourceReader for the remainder of files.

Yeah, that's something load_tmx_map_from could not do and it may be useful to have.

I know I asked how I could use it with the FilesystemResourceReader, but since I can easily use a more portable solution from the beginning, I prefer portability.

What do you mean by this? I don't understand.
Now that I think about it, we could implement ResourceReader for anything that implements for<'a> Fn(&'a Path) -> Result<R, E> where R: Read, E: Error + Send + Sync + 'static, which would allow easily defining a ResourceReader inline in the Loader declaration, removing a lot of boilerplate and simplifying the process altogether, something like this:
let mut loader = Loader::with_cache_and_reader(
    DefaultResourceCache,
    |path| { if path == "my-map.tmx" { Ok(that_map) } else { Err(MapLoadingError) }
);

What do you think about this?

What do you mean by this? I don't understand.

I was just explaining why I wouldn't use it. It's not important.
What's important is your suggestion which is actually pretty cool! That I would definitely use!

Thanks :) I'll try to PR it whenever possible. I'm currently really busy with exams so it probably won't be done until ~2weeks from now.

This has been merged for a while now, so we can safely close this issue.


[bug] [question] apt reports changed origin to 'Pulp 3' ? at htttp://packages.microsoft.com/repos/code

Describe the issue
i may have missed an announcement?
$ sud oapt-get upatte
E: Repository 'http://packages.microsoft.com/repos/code stable InRelease' changed its 'Origin' value from 'code stable' to 'Pulp 3'
E: Repository 'http://packages.microsoft.com/repos/code stable InRelease' changed its 'Label' value from 'code stable' to ''

When did the issue occur?
just now
If applicable, what package did you attempt to install, and from which repo?
Steps to Reproduce
sudo apt-get update
Actual Result
warning
Expected Result
code-insiders updated
Additional context
i am running code-insiders on ubuntu-mantic+proposed w mainline kernel 6.7.0-rc2 (self-signed)

@razielanarki thanks for the bug report. Looks like this is a bug and we should have a fix out shortly. Apologies.

@razielanarki thanks for the bug report. Looks like this is a bug and we should have a fix out shortly. Apologies.

On my PC with Ubuntu I unfortunately accepted the change proposed by APT: is there any security implications? Can I rest assured?
Thank you

@Teo80 there's not a security implication per se, the repo signatures are your safeguard against that. But you'll have to accept the change again when the fields go back to their expected value (which we're actively working to fix).

I'm still experiencing this issue on Ubuntu 22.04.3 LTS. When downloading the InRelease file manually it still says:

Also still have the issue, Debian Bullseye (cleaned all metadata)

@chr1s-code/@helge00,
Can you confirm which repos/URLs you're checking? When I check the Ubuntu 22.04 and Debian 11 repos, I see the correct origin/label reflected
$ curl -s https://packages.microsoft.com/ubuntu/22.04/prod/dists/jammy/InRelease | head -n 10
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Origin: microsoft-ubuntu-jammy-prod jammy
Label: microsoft-ubuntu-jammy-prod jammy
Suite: jammy
Codename: jammy
Date: Fri, 17 Nov 2023 23:17:41 +0000
Architectures: amd64 arm64 armhf all
Components: main
mbearup@thebearup0:~/src/tmp$ curl -s https://packages.microsoft.com/debian/11/prod/dists/bullseye/InRelease | head -n 10
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Origin: microsoft-debian-bullseye-prod bullseye
Label: microsoft-debian-bullseye-prod bullseye
Suite: bullseye
Codename: bullseye
Date: Sat, 18 Nov 2023 09:07:19 +0000
Architectures: amd64 arm64 armhf all
Components: main

@mbearup - right, it is correct now; maybe just some CDN/caching issues.

Could you confirm which repos you're trying to sync? I tried our Ubuntu 22.04, Debian 11, and code repos, and I see the correct origin/label reflected in each
$ curl -s https://packages.microsoft.com/ubuntu/22.04/prod/dists/jammy/InRelease | head -n 10
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Origin: microsoft-ubuntu-jammy-prod jammy
Label: microsoft-ubuntu-jammy-prod jammy
Suite: jammy
Codename: jammy
Date: Fri, 17 Nov 2023 23:17:41 +0000
Architectures: amd64 arm64 armhf all
Components: main
$ curl -s https://packages.microsoft.com/debian/11/prod/dists/bullseye/InRelease | head -n 10
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Origin: microsoft-debian-bullseye-prod bullseye
Label: microsoft-debian-bullseye-prod bullseye
Suite: bullseye
Codename: bullseye
Date: Sat, 18 Nov 2023 09:07:19 +0000
Architectures: amd64 arm64 armhf all
Components: main
$ curl -s https://packages.microsoft.com/repos/code/dists/stable/InRelease | head -n 10
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Origin: code stable
Label: code stable
Suite: stable
Codename: stable
Date: Fri, 17 Nov 2023 14:14:32 +0000
Architectures: amd64 arm64 armhf all
Components: main

I saw the same issue just now, but a 2nd run worked so some CDN wonkyness still.

I am having the same issue still:
Hit:18 https://packages.microsoft.com/repos/edge stable InRelease Get:19 https://packages.microsoft.com/repos/ms-teams stable InRelease [5931 B] E: Repository 'http://packages.microsoft.com/repos/code stable InRelease' changed its 'Origin' value from 'code stable' to 'Pulp 3' E: Repository 'http://packages.microsoft.com/repos/code stable InRelease' changed its 'Label' value from 'code stable' to '' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. Do you want to accept these changes and continue updating from this repository? [y/N]
lsb_release -a No LSB modules are available. Distributor ID:	Ubuntu Description:	Ubuntu 22.04.3 LTS Release:	22.04 Codename:	jammy
`cat /etc/apt/sources.list.d/vscode.list
THIS FILE IS AUTOMATICALLY CONFIGURED
You may comment out this entry, but any other modifications may be lost.
deb [arch=amd64,arm64,armhf] http://packages.microsoft.com/repos/code stable main
`

@Silvergti could you confirm which IP you're hitting for packages.microsoft.com? I no longer see the issue repro'ing, but I can check if there's an issue with an individual mirror.

@mbearup:
host packages.microsoft.com
packages.microsoft.com is an alias for apt-geofence-parent.trafficmanager.net.
apt-geofence-parent.trafficmanager.net is an alias for csd-apt-neu-d-4.northeurope.cloudapp.azure.com.
csd-apt-neu-d-4.northeurope.cloudapp.azure.com has address <IP_ADDRESS>

@Silvergti when I pull the metadata from that mirror, I see the correct values. If you're still seeing the issue, it may be due to layers of caching along your network path.
$ curl -s http://csd-apt-neu-d-4.northeurope.cloudapp.azure.com/repos/code/dists/stable/InRelease | head -n 10
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Origin: code stable
Label: code stable
Suite: stable
Codename: stable
Date: Wed, 15 Nov 2023 11:13:39 +0000
Architectures: amd64 arm64 armhf all
Components: main

Hello @mbearup
That might have been the case, indeed.
I am getting the same as you (never ran this when it wasn't working):
$ curl -s http://csd-apt-neu-d-4.northeurope.cloudapp.azure.com/repos/code/dists/stable/InRelease | head -n 10
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Origin: code stable
Label: code stable
Suite: stable
Codename: stable
Date: Wed, 15 Nov 2023 11:13:39 +0000
Architectures: amd64 arm64 armhf all
Components: main

Thanks!
Re-tried again and it is working now.

This is the resource apt tries to load
`$ curl -s https://packages.microsoft.com/repos/code/dists/stable/InRelease | head -n 10
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Origin: Pulp 3
Suite: stable
Codename: stable
Date: Mon, 20 Nov 2023 10:14:43 +0000
Architectures: amd64 arm64 armhf all
Components: main
Acquire-By-Hash: no`

@chr1s-code can you confirm which IP address you're hitting? I can no longer repro, but glad to check an individual mirror if you still see the issue.

This command solves problem on local machine:
sudo apt-get clean

Just run into the bug.

@romansh can you tell us what repo you're attempting to use and what IP address your system resolves to for packages.microsoft.com? It's possible we have an edge node that didn't get an update.

Same here. Debian. Messages are
❯ sudo apt update
Get:1 http://packages.microsoft.com/repos/code stable InRelease [3,533 B]
Hit:2 https://deb.debian.org/debian bookworm InRelease
Hit:3 https://download.docker.com/linux/debian bookworm InRelease
E: Repository 'http://packages.microsoft.com/repos/code stable InRelease' changed its 'Origin' value from 'code stable' to 'Pulp 3'
E: Repository 'http://packages.microsoft.com/repos/code stable InRelease' changed its 'Label' value from 'code stable' to ''
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N] ^C

@janvanoorschot can you tell us what IP address packages.microsoft.com resolves to on the system with the problem?

@romansh can you tell us what repo you're attempting to use and what IP address your system resolves to for packages.microsoft.com? It's possible we have an edge node that didn't get an update.

deb [arch=amd64,arm64,armhf] http://packages.microsoft.com/repos/code stable main
ping packages.microsoft.com
PING csd-apt-weu-d-2.westeurope.cloudapp.azure.com (<IP_ADDRESS>) 56(84) bytes of data.

@jasonzio
 dig packages.microsoft.com

; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> packages.microsoft.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32646
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;packages.microsoft.com.		IN	A

;; ANSWER SECTION:
packages.microsoft.com.	2840	IN	CNAME	apt-geofence-parent.trafficmanager.net.
apt-geofence-parent.trafficmanager.net.	2840 IN	CNAME csd-apt-weu-d-3.westeurope.cloudapp.azure.com.
csd-apt-weu-d-3.westeurope.cloudapp.azure.com. 2840 IN A <IP_ADDRESS>

;; Query time: 12 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>) (UDP)
;; WHEN: Mon Nov 20 19:30:11 CET 2023
;; MSG SIZE  rcvd: 175

sudo apt-get clean
sudo apt-get update.
Everything is working as expected now.

There seems to be some CDN caching issues. Curl'ing the Release file twice gives different results, once valid and once invalid.
root@myhostname:/root# curl https://packages.microsoft.com/repos/vscode/dists/stable/Release
Origin: vscode stable
Label: vscode stable
Suite: stable
Codename: stable
Date: Fri, 17 Nov 2023 14:10:38 +0000

<snip>

root@myhostname:/root# curl https://packages.microsoft.com/repos/vscode/dists/stable/Release
Origin: Pulp 3
Suite: stable
Codename: stable
Date: Mon, 20 Nov 2023 10:12:25 +0000

<snip>

@foorak @romansh @janvoorschot
Think I have this beaten into submission for now. Starting to deploy a fix to ensure this particular CDN caching issue doesn't repeat. Thanks for your patience and for giving us the info we needed to find the issue.

I also got the error a couple of minutes ago, but ran it again now and it's gone. Thanks for fixing it so fast.

I have this running for some time, it is a random change in IP address, only <IP_ADDRESS> is wrong:
I am located the the Netherlands...
$ host packages.microsoft.com
packages.microsoft.com is an alias for apt-geofence-parent.trafficmanager.net.
apt-geofence-parent.trafficmanager.net is an alias for csd-apt-weu-d-4.westeurope.cloudapp.azure.com.
csd-apt-weu-d-4.westeurope.cloudapp.azure.com has address <IP_ADDRESS>
$
$ while true; do date; wget https://packages.microsoft.com/repos/code/dists/stable/InRelease -O - 2>&1 | egrep 'Resolving|Origin:'; sleep 30; done
Mon 20 Nov 21:15:06 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: Pulp 3
Mon 20 Nov 21:15:37 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:16:07 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:16:37 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:17:07 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:17:37 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: Pulp 3
Mon 20 Nov 21:18:07 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:18:37 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:19:07 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:19:37 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:20:08 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: Pulp 3
Mon 20 Nov 21:20:38 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:21:08 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:21:38 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:22:08 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:22:38 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:23:08 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:23:38 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:24:08 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:24:39 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:25:09 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:25:39 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:26:09 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:26:39 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: Pulp 3
Mon 20 Nov 21:27:09 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:27:39 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:28:09 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:28:39 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:29:10 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: Pulp 3
Mon 20 Nov 21:29:40 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: Pulp 3
Mon 20 Nov 21:30:10 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:30:40 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: Pulp 3
Mon 20 Nov 21:31:10 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: Pulp 3
Mon 20 Nov 21:31:40 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:32:10 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:32:40 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:33:10 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:33:41 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:34:11 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:34:41 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:35:11 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:35:41 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:36:11 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:36:41 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:37:11 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:37:42 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Mon 20 Nov 21:38:12 CET 2023
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Origin: code stable
Hope this helps...

@jasonzio problem fixed for me. Thanks!

Thanks to all. A fix has been deployed which should prevent this from recurring. If you see this happen again, please do let us know.
Again, thanks for your patience.

Seeing this across our estate this morning, from AWS WorkSpaces Ubuntu instances which we manage with Ansible:
TASK [ubuntu_generic : Ubuntu apt Configuration] *******************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Failed to update apt cache: E:Repository 'http://packages.microsoft.com/repos/code stable InRelease' changed its 'Origin' value from 'Pulp 3' to 'code stable', E:Repository 'http://packages.microsoft.com/repos/code stable InRelease' changed its 'Label' value from '' to 'code stable', W:This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details., W:https://pkg.osquery.io/deb/dists/deb/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details."}

trying to run the fix above doesn't work:
root@U-35ZOJRWXMSS74:/home/psadmin# apt clean
root@U-35ZOJRWXMSS74:/home/psadmin# apt update
Hit:1 http://<IP_ADDRESS>/updates/linux/apt jammy InRelease
Get:2 http://packages.microsoft.com/repos/code stable InRelease [3,589 B]
Hit:3 http://eu-west-2.ec2.archive.ubuntu.com/ubuntu jammy InRelease
Hit:4 http://security.ubuntu.com/ubuntu jammy-security InRelease
Hit:5 http://eu-west-2.ec2.archive.ubuntu.com/ubuntu jammy-updates InRelease
Hit:6 https://download.docker.com/linux/ubuntu jammy InRelease
Hit:7 http://eu-west-2.ec2.archive.ubuntu.com/ubuntu jammy-backports InRelease
Hit:8 https://dl.google.com/linux/chrome/deb stable InRelease
E: Repository 'http://packages.microsoft.com/repos/code stable InRelease' changed its 'Origin' value from 'Pulp 3' to 'code stable'
E: Repository 'http://packages.microsoft.com/repos/code stable InRelease' changed its 'Label' value from '' to 'code stable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N]

@ps-spb In your case the machine has already accepted the incorrect Origin "Pulp 3", and you therefore has to accept it again to revert it back to "code stable".
You can automate this via ansible with apt-get update --allow-releaseinfo-change

jasonzio would it be possible share the fix on the pulp side. As I'm having a similar issue internally :D

jasonzio would it be possible share the fix on the pulp side. As I'm having a similar issue internally :D

Try setting publish_upstream_release_fields=True on repositories that existed before the pulp_deb 3.0.0 upgrade.


Simplify Gossipsub validator fn Map

In Gossipsub we register the same function for all topics. Then this function has to parse the incoming topic and decide which dedicated validator fn to use.
Would it be simpler / possible to directly register validator fn A for topic A and remove all the parsing?
Ref: https://github.com/ChainSafe/lodestar/blob/c013fbf6c3c7b623a6f476cbd5a7544026e009c3/packages/lodestar/src/network/gossip/gossipsub.ts#L83-L91

Fixed with https://github.com/ChainSafe/lodestar/pull/2132


Update telegram-alpha to 3.6-109999,725

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

this one fixes the issue that was introduced in https://github.com/caskroom/homebrew-versions/pull/4896


Add plugin mechanism for extending render engine interfaces and objects

Desired behaviour
Add a mechanism for external projects to extend the render engine interface and implementation.
The present render engine plugin mechanism allows external projects to add custom render engines that implement part or all of the current render engine interface, but it does not allow the interface to be extended via plugins.
For example if you wanted to add a ForceVisual the current approach would be to add classes to the existing gz-rendering library and add a CreateForceVisual method to Scene (and equivalents for each render engine implementation). It would be useful to be able to add such objects in external projects without having to change the core libraries.
The use case I have in mind is for an plugin for an OceanVisual. The visual plugin requires a number of custom rendering objects that subclass from rendering::Visual and rendering::Geometry. My current implementation defines these directly in the system plugin, however it turns out that on some platforms the approach is sensitive to the order in which the plugins are loaded which can result in either the render engine being improperly initialised or the loader reporting missing symbols.
Alternatives considered
Define extensions directly in system plugins. This can be made to work, but is not robust and may fail on some platforms. It is also not very modular and does not enable custom rendering extensions to be easily shared.
Implementation suggestion
Add a mechanism analogous to RenderEngine, RenderEnginePlugin, RenderEngineManger that allows extension interfaces and their implementation to be defined in plugins and loaded at runtime. The extension manager should have a mechanism to check that required (render engine) dependencies are available and have been loaded before attempting to load extensions.
Additional context
I'll attempt to implement this approach in an external project (asv_wave_sim). If it works I'll factor out the extension mechanism and submit it as a PR. In the meanwhile if the team have any suggestions of recommendations on an approach that would be welcomed!

We discussed the idea of letting gz-rendering load its own plugins in https://github.com/gazebosim/gz-rendering/issues/482 for making gazebo visual plugins work but opted to implement it in gz-gazebo instead. I think it's still valuable to support loading plugins in gz-rendering. The proposed implementation approach sounds good.
From the use case described, it's sounds like it's different from the type of plugins in gz-gazebo or gz-gui, where the proposed gz-rendering plugins don't have standard interfaces (e.g. Configure, Update) that need to be implemented?

Some more detail about the use case:

One of the wave rendering approaches modifies a set of three textures each update step to encode the wave displacements and normal and tangent vectors. These are pushed from the CPU to the GPU using ogre staging textures and then applied to the ocean grid in the vertex shader. This part of the code requires require access to the classes in ogre-next and the gz-rendering-ogre2 plugin library.

There is a system plugin analogous to the ShaderParam plugin in gz-sim that is declared in the <visual> element of the model. This plugin implements the usual ISystemConfigure and ISystemPreUpdate interfaces. The problem is that if this plugin links to gz-rendering-ogre2 directly the render library may be loaded before it is correctly loaded and initialised by MinimalScene. This was causing segfaults on some platforms (macOS arm64).

The approach is to use two plugins for the visual: A system plugin as described in (2), an interface component that defines extensions to gz-rendering and a plugin loader, and a render engine extension plugin that links to ogre2 and gz-rendering-ogre2 that contains the implementation. The last plugin is not loaded by the system visual's PreUpdate method until the scene created by MinimalScene is valid.

There's a draft PR here with an implementation: https://github.com/srmainwaring/asv_wave_sim/pull/61. It works as intended however the code needs to be refactored and simplified as most of the functionality adapted from the gz::rendering::RenderEngineManager and gz::rendering::RenderEngine is not required, and we are not really creating a new type of Scene but rather creating an object factory for extending rendering types so the current naming is misleading.
As an aside there is also something unusual going on with the render engine singletons. The following are called after MinimalScene loads and initialises the metal render engine:
{
  auto engine = rendering::Ogre2RenderEngine::Instance();
  auto graphicsAPI = engine->GraphicsAPI();
  gzdbg << "Using graphicsAPI: "
      << GraphicsAPIUtils::Str(graphicsAPI) << "\n";
}
// outputs
// Using graphicsAPI: OPENGL

Which is the default, but incorrect as the Metal render engine has already been initialised and loaded.
{
  auto engine = rendering::engine("ogre2");
  auto graphicsAPI = engine->GraphicsAPI();
  gzdbg << "Using graphicsAPI: "
      << GraphicsAPIUtils::Str(graphicsAPI) << "\n";
}
// outputs
// Using graphicsAPI: METAL

Which is correct when using the Metal render engine.
The first case is used in gz-rendering in the ShaderParam code, and works there. It does not seem to work when used in a separate plugin. It is almost as if there are separate copies of the SingletonT<> in each plugin library?

thanks for explaining the use case and how the extension plugin is implemented. So My understanding is:

gz-gazebo gui loads MinimalScene (which dynamically loads gz-rendering-ogre2)
gz-gazebo gui then loads a visual plugin (WaveVisual) which has a RenderEngineExtensionManager
The RenderinEngineExtensionManager loads the extension plugin once a valid scene is found (extension plugin is linked against gz-rendering-ogre2)
The extension plugin has a few interface APIs (that users need to implement if writing a an extension plugin), e.g. Load, Init, ScenenodeFactory

// outputs
// Using graphicsAPI: OPENGL
Which is the default, but incorrect as the Metal render engine has already been initialised and loaded.

that's weird. The minimal scene is created and initialized using metal backend and this happens before the extension plugin is loaded or after?

It is almost as if there are separate copies of the SingletonT<> in each plugin library?

Note that I'm not exactly sure what the behavior is when the gz-rendering-ogre2 library is first dynamically loaded into memory and then we load another library that links against gz-rendering-ogre2. We had a bit of an issue with a similar situation in gz-sensors and ended up refactoring the code and removing the plugin loading functionality in https://github.com/gazebosim/gz-sensors/pull/90. But it seems like in this case, the render engine extension plugin actually loads and run but it appears to be accessing different singletons.

Yes, that's the gist of it.
In step 1. it's not guaranteed that gz-rendering-ogre2 will be loaded by MinimalScene before step 2 loads the WaveVisual as these may run on different threads (actually it's not assured that step 1 occurs before step 2 either).
I'm wondering whether the problem with the singletons is caused by the fact that RenderEngine does not have a virtual method anchored in the translation unit (it has all it's methods defined in the header - most are abstract but the destructor is defined inline). This can result a copy of RenderEngine::~RenderEngine() being created in each library / plugin that includes RenderEngine.hh (https://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers).
The fix is to add a .cc file for each interface class that defines one virtual method (say the destructor) so it could be as simple as.
#include "RenderEngine.hh"

RenderEngine::~RenderEngine() = default;

The fix is to add a .cc file for each interface class that defines one virtual method (say the destructor) so it could be as simple as.

Oh, I believe this may fix some other things I have been running in to.  I'm going to open a PR with just this fix.


[fix][pulsar-admin] Fix pulsar-admin not prompting message when there is a 500 error.

Motivation
When pulsar-admin occurs 500 error, it doesn't return the root cause message to the user, only prompt Internal Server Error.
The root cause is that: the broker side return 'TEXT_PLAIN' type message,
https://github.com/apache/pulsar/blob/9644448fa2d85701e47fb8b6bf90ac149f70cf56/pulsar-broker/src/main/java/org/apache/pulsar/broker/web/RestException.java#L77-L88
But client side tries to parse it as json type (line-222):
https://github.com/apache/pulsar/blob/9644448fa2d85701e47fb8b6bf90ac149f70cf56/pulsar-client-admin/src/main/java/org/apache/pulsar/client/admin/internal/BaseResource.java#L219-L224
https://github.com/apache/pulsar/blob/9644448fa2d85701e47fb8b6bf90ac149f70cf56/pulsar-client-admin/src/main/java/org/apache/pulsar/client/admin/internal/BaseResource.java#L272-L288
So if broker return 500, getReasonFromServer will throw exception 3 times and then use the original 500 message to the user.
So we need to keep the server to return JSON type data to keep consistent.
Modification

Change entity to return JSON type.
Remove getExceptionData, it will not use anymore.

Documentation

[x] no-need-doc

@Technoboy- Great improvement, but I'm just wondering how this will work when a newer client is used with an older broker version?

@Technoboy- Great improvement, but I'm just wondering how this will work when a newer client is used with an older broker version?

The client side has nothing changed. Newer clients with old brokers will keep the original behavior which means they are still getting Internal Server Error. when occurring 500 error.

I'm not sure if it's change can affect exist user who use HTTP REST API

I think it's nothing impact.


Fix travis

Fix travis and codecov after repo renaming

Codecov Report

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

@@            Coverage Diff            @@
##             master      #48   +/-   ##
=========================================
  Coverage          ?   76.08%
=========================================
  Files             ?       75
  Lines             ?     2835
  Branches          ?        0
=========================================
  Hits              ?     2157
  Misses            ?      678
  Partials          ?        0

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 1e4e502...1353d2e. Read the comment docs.


Request: Posibility to share the map/circles added?

Hi there
I am a veterinarian working for Animal Health and I am looking at the possibility of creating a circle/radious at a particular point where there has been an outbreak (e.g. Avian Flu) to establish a  a first contention area (protective zone - 3km) and a secondary one (surveillance zone - 10km) and a would like to be able to share that with other colleagues for disease controls purposes .
I have tried creating the zones, but if I copy and paste the URL resulting it will share the map but not the circles.
Can this be achieved?
Thanks in advance

Yes I have found that also ?


Pass transformOptions to getShallowDependencies.

We weren't passing transformOptions to getShallowDependencies, and therefore, when this method was called on a module, it would bust the cache and cause a retransform of the file. This was resulting in a complete retransforming of all files when the HMR Client connected to the packager.
Test Plan:
Put a console.log statement in transformer.js. Run the packager with --reset-cache, and open an app with HMR enabled. You will see the transformer log during the initial bundle request, but after the "[HMR Client] Client Connected" message, you will not see any logs.

cc @davidaurelio @satya164 @martinbigio

@facebook-github-bot shipit

Should have waited for tests to be green. They will finish before the internal ones so it's fine (if anything is wrong I'll have time to abort the land)


Collapsible challenge submission table UI

Modified submission table into a collapsible one.

Changes proposed in this pull request:

Modified challenge submission table into a collapsible one.
Fields like status, stderr_file, stdout_file, submission_result_file are displayed outside collapsible
rest data remains inside collapsible.

Link to live demo: http://pr-187-evalai.surge.sh

@sanketbansal, can you pass it's build?

@sanketbansal, can you pass it's build?

Looking for it

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@aa9b70c). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master     #187   +/-   ##
=========================================
  Coverage          ?   52.33%
=========================================
  Files             ?       63
  Lines             ?     3363
  Branches          ?      383
=========================================
  Hits              ?     1760
  Misses            ?     1510
  Partials          ?       93

Impacted Files
Coverage Δ

...lengesubmissions/challengesubmissions.component.ts
35.75% <100%> (ø)

Impacted Files
Coverage Δ

...lengesubmissions/challengesubmissions.component.ts
35.75% <100%> (ø)

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 aa9b70c...16ae337. Read the comment docs.

@sanketbansal resolve the conflicts.

@sanketbansal resolve the conflicts.

@lunayach  done please review


consolidate voter's UTXOs

to prevent a possible input bloat for spendies.
Already done in Planet A code

duplicated #21


ciri: OOM with local snapshots

cIRI gets killed with the following when local snapshots is enabled.
==18509==ERROR: AddressSanitizer failed to allocate 0x10000 (65536) bytes of memory at address 0x60d086f60 (error code: 12)
ERROR: Failed to mmap

how can i reproduce?
does that happen on startup or after a while?

Just run cIRI with LS and the LS files on the server and it'll eventually crash


fix: add retry on 503 errors

With this update I was able to create a local cache of the NVD in ~30 minutes. Prior to releasing ODC 9.0.0 this took ~2 minutes - so the number of users from the ODC community appear to be crushing the NVD API atm.

@jeremylong Thanks for fixing this on a holiday weekend!  My change was more of a hack to that one method because I wasn't familiar enough with code to attempt to make changes everywhere.   I didn't see a check for the Retry-After response header in your change.  You should use that in your retry logic if it's provided, and log it at DEBUG if the API responds with an explicit Retry-After; if the Retry-After is greater than 5 minutes, then log it at INFO so it's obvious to the end users that NVD is having a more serious issue.   Ignoring the Retry-After in the response could be viewed as a DOS and lead to NIST blocking networks.   I know because I do that on our firewalls, if we set a Retry-Time out and we see clients ignoring it, we will immediately block their IP.

I know about the Retry-After response - it is used in the default implementation. However, I validated that the 503s do not include this header. Good point and I probably should add the code to what has been implemented in case the NVD starts to respond with that header.

@danshome see #94 and #95.

@jeremylong I'm testing your changes now.  Has it been your experience that the new API is considerably slower?   I'm quite surprised they aren't supporting HTTP2 and haven't moved to ECC certificates; both would help significantly reduce the load on their systems.  It might be worth adding timings to your default logging.  It may come in handy to make the case to NIST that they need to do something about the performance of the new API.  If things are this slow now, they are going to get killed when they take the old API offline. I've already sent them several emails about my concerns.

@danshome I've been able to use the vulnz CLI to create the offline cache in less then 30 minutes.


ADD CRITICAL WARNING: No support for wildcard domains!

I have wasted a bunch of points from available limit testing this script. It totally fails whenever wildcard domains are used. Please add BIG FAT WARNING into readme pointing up the fact that wildcard domains are not supported so people stop wasting precious limits.

per #15, wildcard certificates are supposed to work. Can you share the command you were attempting to execute?


Updating hosts list in existing gateway causes unexpected results

Bug description
I have an existing Istio Gateway with a list of 6 domains and a SIMPLE tls cert. These domains all work fine. After adding a new domain to the list that also should work with the same (wildcard) certificate, the new domain returns curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to test.mydomain.com:443 from curl, while the existing domains continue to function properly.
Moving the new domain to a new item under the servers list (with only that domain in servers.hosts and all other settings (port, tls) the same) fixes the issue.
Expected behavior
Editing an existing gateway's host list should work as expected.
Steps to reproduce the bug

Create a gateway like this:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: mygateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - "mydomain.com"
        - "www.mydomain.com"
      port:
        number: 443
        name: https-mydomain
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: "mycert"

Verify these settings work as expected.
Update the Gateway with a new domain like:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: mygateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - "mydomain.com"
        - "www.mydomain.com"
        - "test.mydomain.com"
      port:
        number: 443
        name: https-mydomain
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: "mycert"

Verify that mydomain.com and www.mydomain.com continue to work while test.mydomain.com returns SSL errors.
Move the new domain to it's own item in the list, like:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: mygateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - "mydomain.com"
        - "www.mydomain.com"
      port:
        number: 443
        name: https-mydomain
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: "mycert"
    - hosts:
        - "test.mydomain.com"
      port:
        number: 443
        name: https-mydomain
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: "mycert"

Verify that all domains work correctly.

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
1.3.5
How was Istio installed?
Helm
Environment where bug was observed (cloud vendor, OS, etc)
AWS EKS

I attempted to reproduce:
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: tls
  namespace: istio-system
spec:
  secretName: tls-cert
  issuerRef:
    name: letsencrypt-staging
  commonName: MY_IP.xip.io
  dnsNames:
  - MY_IP.xip.io
  - MY_IP.nip.io
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: tls
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: tls-cert
    hosts:
    - MY_IP.xip.io
    - MY_IP.nip.io # Added later
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: tls
spec:
  hosts:
  - "*"
  gateways:
  - tls
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: httpbin
        port:
          number: 80

When I applied this, requests to xip.io worked. Then, I tried nip.io (not yet in gateway) and got the same curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection.
Then i added nip.io to the gateway, and nip.io worked. This was on Istio 1.6.
So it seems like the update to the gateway just didn't go through. This could be propagation delays, but seems unlikely. It may also be some bug in the older version that has since been fixed ,ro I failed to properly reproduce

I could not reproduce, this is on an old version, and there has been no updates in months, so I do not think we can move forward with this. If you still see this, please open a new issue. Thanks!


Add MINIMAL pragmas

From a quick look, the following classes would benefit from MINIMAL pragmas since they have recursive method definitions:

MonadState
MonadWriter

Maybe some others that I missed.

Shipped in 2.2.1 on Jun 2, 2014, but this issue was never closed. Resolving.


Bendy for bencoding

Description
Looks like this is the only library that allows Vec<u8> to be bencoded into bencode string, which we require for peer id when compact=1 and a few other cases around ip.
This PR introduces few implementations of ToBencode and FromBencode for TorrentFile, PeerStream and AnnounceReply so that bencoding works according to BitTorrent spec.
It also gives us more control over bencoding which we will likely need.

merged locally and pushed to dev


Fix Verge status bar position // Always show seconds on unlocked screen as for stock watchface

I am accepting the pull request for the Verge positions fix. Seconds will be reverted and a settings option will be provided.

Agree with that, I don't find how to send two separate pull request


Validate run arguments

This PR addresses underlying issues with Job Argument validation.

[x] duplicate argument name check
[x] missing recipe input argument
[x] populate job arguments with default recipe values

Pull Request Test Coverage Report for Build 902785368

54 of 54 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+7.6%) to 56.575%

Totals

Change from base Build 896908712:
7.6%

Covered Lines:
1652

Relevant Lines:
2920

💛  - Coveralls

@mostaphaRoudsari and @tymokvo I hope it's ok for me to merge this in just now as the tests pass and the changes are additive (ie: I'm not changing the schema or changing existing functions). Let me know if you would have like to give this the go ahead before merging and I will be sure to ping you in the next PR 🙌


[SPARK-47335][BUILD] Upgrade mvn-scalafmt to 1.1.1684076452.9f83818 & scalafmt to 3.8.0

What changes were proposed in this pull request?
The pr aims to upgrade mvn-scalafmt from 1.1.1640084764.9f463a9 to 1.1.1684076452.9f83818.
Why are the changes needed?

mvn-scalafmt
The last mvn-scalafmt upgrade occurred 1 year ago, https://github.com/apache/spark/pull/37727
The latest version of mvn-scalafmt  release notes: https://github.com/SimonJPegg/mvn_scalafmt/releases/tag/2.13-1.1.1684076452.9f83818

scalafmt
The latest version of scalafmt  release notes: https://github.com/scalameta/scalafmt/releases/tag/v3.8.0

Does this PR introduce any user-facing change?
No.
How was this patch tested?

Manually test.

./build/mvn scalafmt:format -Dscalafmt.skip=false

...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  2.216 s
[INFO] Finished at: 2024-03-10T20:30:11+08:00
[INFO] ------------------------------------------------------------------------

./dev/scalafmt

...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:56 min
[INFO] Finished at: 2024-03-10T20:19:46+08:00
[INFO] ------------------------------------------------------------------------

Pass GA.

Was this patch authored or co-authored using generative AI tooling?
No.

Please let me know if this is ready, @panbingkun .

Yeah, it's ready 😄


chore(ci): drop actions/cache@v2

We no longer need to use actions/cache.
Maven dependencies are cached via actions/setup-java
https://github.blog/changelog/2021-08-30-github-actions-setup-java-now-supports-dependency-caching/

I did wonder about that when I activated the caching in the other PR but didn't check. Thanks for undertaking this.


Add initContainer to change kubelet dir ownership

Towards https://github.com/giantswarm/giantswarm/issues/6622
Allows running pod as root. This is used in initContainer. exporter itself is running as giantswarm user

Closing in favor of https://github.com/giantswarm/k8scloudconfig/pull/571


Update gulpfile.js

Add support for .sass files next to .scss

Hi @tomvanderduin ,
Thanks a lot for that pull request, it's a very good point. I will use mostly all your changes except that I will add some more logic to it, but I won't merge it as is. It'll be included in the next release though.
Thanks again.


leaflet_map: Labels don't disappear on ie11

When moving between polygons hover labels don't disappear; similarly they stay in view when popUps appear.

Similar issue with multiple browsers (Safari, DuckDuckGo, Chrome) on mobile devices.

This is a known leaflet label issue: https://github.com/Leaflet/Leaflet.label/issues/114. Also doesn't look like there's an easy solution... :(

I enabled the 'Reset Map' button to close all open labels, which I think is as close as we're going to get.


Workaround internal compiler error

The associated type bound here is not interpreted correctly. This is likely due to the ICE described in rust-lang/rust#20413.
Note, that this may lead to a loss of type inference using that function.

The failure is an upstream bug in quickcheck. Build needs to be triggered again.

Thanks! I don't think that loosing type inference temporarily for this function is too problematic.


Error: No ViewManager defined for class RNSVGDefs.

I just want to set shadow for Android in React Native. And then I followed this link https://stackoverflow.com/questions/41320131/how-to-set-shadows-in-react-native-for-android.
The steps are from the github: https://github.com/879479119/react-native-shadow.

You need to configure react-native-svg as well. Follow steps in README here

@spicyboiledfish if you are using react-native >=0.47 , you should try to delete
this SvgPackage#createJSModules method


gF doesn't open visually selected file:line:column in pwd

Hello,
I have a LICENSE file in my present working directory and this text in my buffer:
LICENSE:9:15

Visually selecting the line (by typing V) and then typing gF raises this error:
Error detected while processing function fetch#visual..<SNR>340_dovisual:
line    2:
E447: Can't find file "LICENSE:9:15" in path
Press ENTER or type command to continue

Moreover, putting the cursor at the beginning of the line (on the L) and typing gF just opens the LICENSE file while completely ignoring the line and column information.
Thanks for your consideration. :sweat_smile:

The behaviour in visual mode is expected: you have to select the file name only (i.e. “LICENSE”) for it to work. That is how Vim’s built-in gF works, and vim-fetch tries to extend, but not modify, built-in behaviour. Think of the selection as telling Vim “all of this is the file name, never mind that it contains characters not in isf”.

putting the cursor at the beginning of the line (on the L) and typing gF just opens the LICENSE file while completely ignoring the line and column information.

This, however, is most definitely not expected behaviour. I will look into it. ASAP.

I cannot reproduce this – in my tests, gFworked exactly as expected, jumping to the specified line and column. Could you check  that you are actually executing vim-stay’s gF for me, please? Specifically, nmap gF should output:
n gF * :<C-u>call fetch#cfile(v:count1)<CR>

Also, do make sure that the file you want to jump to actually has 9 or more lines of content: if it is shorter, vim-stay doesn’˝ jump anywhere. If that is the case, I’ll need a log of what happens. With the cursor on “L”, do:
set verbosefile=/somewhere/you/will/find/it/stay.log
16verbose unsilent normal gF
set verbosefile=
```vim

and post the `stay.log` file (or its contents) somewhere where I can access it (pleas don’t paste it into the issue – it’s likely to be somewhere between huge and humungous in size :)).

Yes,  :nmap gF shows me:
n  gF          * :<C-U>call fetch#cfile(v:count1)<CR>

In normal mode, putting the cursor on L and typing gF does the right thing (it jumps to line 9, column 15).  However in visual mode, with LICENSE:9:15 selected, it does not work as shown in this log file created by these commands:
:set verbosefile=/tmp/stay.log
:16verbose unsilent normal VgF
:set verbosefile=

I hope this helps. :sweat_smile:

Good to hear it works in normal mode for you too :). For visual mode, you need to select only the file name part (i.e. ‘LICENSE’, not the ‘:9:15’ spec). This is how visual gF works in Vim without vim-fetch too: everything you select is considered to be the file name, line and column specs must come after that.

Closing as this is designated behaviour. Let me know if there is anything else I can help with.


Update to use @material-ui/core

As of today material-ui@next moved to @material-ui/core, think you could make a quick update with the fixed dependency?

Wow, that was quick. :smile:

Will you publish a new version on npm then?
Can't wait to update my code (actually pretty much done and just the icons are missing 😅)

@olee Same here :sweat_smile: v5.0.0 is up on npm now :package:


httping: 3.6 -> 4.1.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for httping is: Ping with HTTP requests
meta.homepage for httping is: https://vanheusden.com/httping
meta.changelog for httping is: https://github.com/folkertvanheusden/HTTPing/releases/tag/v3.7a
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.7a with grep in /nix/store/5xywa289qcad6myrln81x2m2q56a2cp7-httping-3.7a
found 3.7a in filename of file in /nix/store/5xywa289qcad6myrln81x2m2q56a2cp7-httping-3.7a

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

httping

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/5xywa289qcad6myrln81x2m2q56a2cp7-httping-3.7a \
  --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 httping https://github.com/r-ryantm/nixpkgs/archive/ad6ca4c20f22d6dce191d23b4220ee436de565e8.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/ad6ca4c20f22d6dce191d23b4220ee436de565e8#httping

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/5xywa289qcad6myrln81x2m2q56a2cp7-httping-3.7a
ls -la /nix/store/5xywa289qcad6myrln81x2m2q56a2cp7-httping-3.7a/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 built:

httping

Maintainer pings
cc @anthonyroussel for testing.

3.7a is alpha release and not stable release yet: https://github.com/folkertvanheusden/HTTPing/releases

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for httping is: Ping with HTTP requests
meta.homepage for httping is: https://vanheusden.com/httping
meta.changelog for httping is: https://github.com/folkertvanheusden/HTTPing/releases/tag/v4.1.0
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 4.1.0 with grep in /nix/store/355za28w549cfl07jrnl3y7v8nvwadw6-httping-4.1.0
found 4.1.0 in filename of file in /nix/store/355za28w549cfl07jrnl3y7v8nvwadw6-httping-4.1.0

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

httping

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/355za28w549cfl07jrnl3y7v8nvwadw6-httping-4.1.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 httping https://github.com/r-ryantm/nixpkgs/archive/3f059cf73a6543ad19bbd7e234c868bc31d55c4f.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/3f059cf73a6543ad19bbd7e234c868bc31d55c4f#httping

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/355za28w549cfl07jrnl3y7v8nvwadw6-httping-4.1.0
ls -la /nix/store/355za28w549cfl07jrnl3y7v8nvwadw6-httping-4.1.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 built:

httping

Maintainer pings
cc @anthonyroussel for testing.

Result of nixpkgs-review pr 328050 run on aarch64-linux 1

1 package built:

httping


[cpp-sparrow] Add cpp-sparrow

[x] Changes comply with the maintainer guide.
[x] The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
[x] Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx.
[x] The versioning scheme in vcpkg.json matches what upstream says.
[x] The license declaration in vcpkg.json matches what upstream says.
[x] The installed as the "copyright" file matches what upstream says.
[x] The source code of the component installed comes from an authoritative source.
[x] The generated "usage text" is accurate. See adding-usage for context.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is in the new port's versions file.
[x] Only one version is added to each modified port's versions file.

Hi @MonicaLiu0311,
I have been trying to understand why one of the builds fails but I really cannot the reason behind it.
The error message does not makes a lot of sense to me, especially given that the layout of this PR is identical to other PRs' such as https://github.com/microsoft/vcpkg/pull/37314/.
Could you help?

The usage test passed on x64-windows (header files found):
sparrow is header-only and can be used from CMake via:

    find_path(SPARROW_INCLUDE_DIRS "sparrow/buffer.hpp")
    target_include_directories(main PRIVATE ${SPARROW_INCLUDE_DIRS})

Thank you, @MonicaLiu0311.

The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.

This does not seem to be correct. This project is not associated with sparrow on repology, and first search results point to https://github.com/ropas/sparrow , not https://github.com/xtensor-stack/sparrow .
Would you accept xtensor-stack-sparrow ?

x-sparrow would work for us as the ownership might be shared beyond the xtensor-stack's organization.

Hm, x- has its own world of associations. Is xtensor- a candidate?

Is xtensor- a candidate?

We'd like to keep it for xtensor bindings on sparrow. Would cpp-sparrow be ok (as suggested by the last change)?

@ vcpkg team: Are we OK with cpp-sparrow?
Also, should we say this depends on https://github.com/microsoft/vcpkg/pull/37457 so that the patch is unnecessary? (I'm a bit uneasy patching a version that upstream explicitly picked)

The thing is that sparrow will be transfered to the man-group org when it's more stable. Would man-group-sparrow be acceptable?

The thing is that sparrow will be transfered to the man-group org when it's more stable. Would man-group-sparrow be acceptable?

Can't we just rename the port if/when that happens?

Does renaming the port makes the old name available again? If so, could name this port xtensor-stack-sparrow for now, and rename it when xtensor-stack/sparrow becomes man-group/sparrow?

Does renaming the port makes the old name available again?

No, in general people would have to update their references. But they'd have to do that referencing the github repo in the first place.

I am trying to understand the errors on Windows though I do not have a machine running this OS.

Hello @BillyONeal,
The project has been transferred to another organization, and this PR is now ready for another review. :slightly_smiling_face:

The naming concern remains. Would you accept man-group-sparrow to follow the [github organization]-[repo] convention?

I just have renamed the port accordingly.

Can we actually reconsider sparrow as a name since https://github.com/ropas/sparrow is a small, unmaintained OCAML project?

I would love this to be named sparrow. It would save us the trouble of having to tell people to use a different name on vcpkg.

The problem with the name sparrow is again, not in repology, and search hits lead to

ropas/sparrow
Sparrow-lang/sparrow

@AugP
@ras0219-msft
@data-queue
@JavierMatosD
and I discussed this today.
We affirm what we said back in March, there's too much potential for confusion and we want the name to be man-group-sparrow.

Ping @jjerphan

Closing this PR since it seems that no progress is being made. Please ping us to reopen if work is still being done.


Drop python 3.9 support

This resolves an issue with testing Python3.9

4 major versions os more than adequate and dropping 3.9 removes a lot of headache. You have my vote!


Role assignments using the "latest" authorization package is using an old API

I'm trying to run the following role assignment:
	_, err = authorization.NewRoleAssignment(ctx, "queue-receiver-permission", &authorization.RoleAssignmentArgs{
		Scope:              queue.ID(),
		RoleAssignmentName: pulumi.String("4f6d3b9b-027b-4f4c-9142-0e5a2a2247e0"),
		PrincipalId:        cluster.Identity.PrincipalId().Elem(),
		RoleDefinitionId:   pulumi.String(fmt.Sprintf("/subscriptions/%s/providers/Microsoft.Authorization/roleDefinitions/4f6d3b9b-027b-4f4c-9142-0e5a2a2247e0", subscriptionID)),
	}, pulumi.Provider(p))

When I'm using github.com/pulumi/pulumi-azure-nextgen/sdk/go/azure/authorization/latest
And I get the following error:
  azure-nextgen:authorization/latest:RoleAssignment (queue-sender-permission):
    error: Code="UnsupportedApiVersionForRoleDefinitionHasDataActions" Message="Assignments to roles with DataActions and NotDataActions are not supported on API version '2015-07-01'. The minimum required API version for this operations is '2018-01-01-preview'."

When I switched to github.com/pulumi/pulumi-azure-nextgen/sdk/go/azure/authorization/v20180901preview
The issue was resolved, but I'd expect "latest" will use the latest API..

@yarinm The latest alias always refers to the latest stable API versions, as most of the time we wouldn't want users to default to fragile/experimental/short-lived previews.
In this case, I'm not sure why Azure hasn't shipped a stable version since several years ago, but our criteria stay universal.


APM: add test tag for trace-agent benchmarks as this is required to run tests

What does this PR do?
Adds test build tag for benchmarks run

Motivation
unfortunately some of the tests are hidden behind a "test" build flag, this means the benchmark currently fails to run as it can't compile

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes
None, I verified this change locally

/merge


system macro call has incorrect working directory

It should probably have the working directory set relative to the file defining the macro

Debatable, we do have a __DIR__ which one can use to construct the absolute path. Perhaps a working_directory parameter?


Add a property to the tracker history to track all queries in order

Currently, the tracker history is split up by method (e.g. tracker.history.select, tracker.history.insert). It appears to me that there's no built-in way to get a list of all queries in the order that they were run.
I think it would make sense to add something like tracker.history.all, which would be a list of all queries.

What is the use case that you've stumbled with?

I'm writing tests for code that runs a number of queries, and I want to be able to check that they were run in the correct order.

True. However, when mocking a DB it's hard to objectively check the outcome, since it's there's no actual state, and the outcome is based on what the mock returns.
For example, if you have a function that updates a row and then selects it, when running integration tests with an actual DB, all you have to do is check that the function returns the updated data, and optionally check that the row was actually updated in the DB.
However, when mocking the DB with something like this:
tracker.on.update('update my_table set val = ? where id = ?').response(1);
tracker.on.select('select * from my_table where id = ?').response([{ id: 1, val: 2 }]);

The second handler will return the updated data regardless of the actual order the queries were run, and there's no canonical state to check to see if it was updated.
If the code mistakenly got changed from:
async function update() {
  await knex('my_table).update({ val: 2 }).where('id', 1);
  return knex('my_table).where('id', 1);
}

to
async function update() {
  const result = await knex('my_table).where('id', 1);
  await knex('my_table).update({ val: 2 }).where('id', 1);
  return result;
}

When running integration tests that use an actual DB, the test would fail, since the function would return the old value. However, when mocking as above, the function will return the updated value regardless, and there would be no way to test for this.

Ham, you did convinced me...
Actually there is such support already when using all scope...
It will register the calls with by the call order.
But i guess that this is not so convenient.
Let me think about a proper solution for this one.

See #33 for what I was envisioning.

I think that in test that you need to check the order you can use any statement which supports all types.

@aryehb, does it solves your requirement?

Ping?

Sorry for the delay.
This comment from @Fryuni sums up my response.
Using history.any would require using tracker.on.any() for all mocks, and would preclude using any of the other methods (e.g. tracker.on.select()).


fix json key for lsps1 in code snippet

funding_confirms_within_blocks was not updated in the JSON snippet.

Close in favor of #109 that makes the same change. Thx @niteshbalusu11 nonetheless!


unref unselected subchannels in PF

Currently, even PickFirst has selected a subchannel, it still holds others in the subchannel list.
It could happen that a subchannel is connected but not used by anyone due to these refs.
Therefore, in this PR, I made some slight modification to force PickFirst release those unselected subchannels.
This change is also important for Happy Eyeballs implementation.

This change is

Please check the details of each failed test.
If it's not related to your PR, please link in the issue number. If no one has filed it yet, please file one.

https://github.com/grpc/grpc/issues/16580

Basic Tests Node MacOS: https://github.com/grpc/grpc/issues/15245
Basic Tests C/C++ MacOS doesn't report test result, maybe because I restarted it after the PR was merged.


Svelte support

Language
Svelte syntax is much like .vue files, basically JS embedded in HTML.
Additional resources
Official website: https://svelte.dev

Check this https://github.com/pngwn/prism-svelte


fixed POST data getter

Seems like the Forms are submitted with an array('data'). This does not get called when saving, generating empty entries.

I am not so sure if this is needed... there is scope attribute in the form.html.twig {% set scope = scope ?: 'data.' %} ...


feat: relative fees for lnv2

Kicked off upgrade tests in https://github.com/fedimint/fedimint/pull/6002


Add rnpm support.

This makes installation that much easier.
Would only require a single line, like: rnpm install react-native-unified-contacts.
As far as I know rnpm works out of the box with most react native npm packages but because this is a workspace instead of a library package, it might not be able to handle this effectively. We might have to give it explicit instructions.

+1


'in' operator for List of Lists

I have the following list of lists:
ListItem (
ListItem ( 1 )
ListItem ( 6 ) )
ListItem (
ListItem ( 1 )
ListItem ( 4 ) )
ListItem (
ListItem ( 2 )
ListItem ( 5 ) )
I want to check if the list (2,5) is in that list. Using the 'in' operator doesn't return true nor false. It just gets stuck. The rule which has this condition never matches. I'm using the latest binaries released.
My intention was to make a list of coordinates. Perhaps there is a better representation for it. What do you think?
Thank you

The following expression evaluates to true for me: ListItem(2) ListItem(5) in ListItem(ListItem(1) ListItem(6)) ListItem(ListItem(1) ListItem(4)) ListItem(ListItem(2) ListItem(5))
Can you show me the exact rule in question which is causing you trouble so that I can attempt to debug further?

Is this version 3.5?

OK. Is it ok if I want to assign it directly in a map like so:
<mapCell>
  "List1" |-> BS
  "ListofLists" |-> Obs
  "check" |-> (_ => BS:List in Obs:List)
</mapCell>

Because what I'm getting is this
  "check" |-> (
    ListItem ( 1 )
    ListItem ( 5 ) =K
    ListItem ( 1 )
    ListItem ( 6 )) orBool (
    ListItem ( 1 )
    ListItem ( 5 ) =K
    ListItem ( 1 )
    ListItem ( 4 ) orBool (
    ListItem ( 1 )
    ListItem ( 5 ) =K
    ListItem ( 2 )
    ListItem ( 5 ) orBool false))

Ah, okay. Yes, this is a bug in the standard library for the maude backend in K. The simplest solution for you to get past this is to write the following rule in your semantics:
rule L1:List =K L2:List => L1 ==K L2


Helm upgrade fails with Error: failed to authorize: failed to fetch oauth token: unexpected status: 401 Unauthorized

Helm upgrade has started failing suddenly with failed to authorize
Running ADO pipeline on VMSS and az login --identity
It was working perfectly fine earlier, there was a sudden break at this step
Template:
az login --identity
kubectl config set-context --current --namespace=$(aksClusterNamespace)

for chart in auth  ; do
  echo "**************UPGRADING $chart*************************************"

  retries=4
  timeout=5m0s

  while [ $retries -gt 0 ]; do

    helm upgrade -f $(system.defaultWorkingDirectory)/infrastructure/kube/env_configs/$(envConfigFile) $chart oci://$(registryName).azurecr.io/bonsai/$chart/$chart --version ${{ parameters.RELEASE_TAG }} --namespace $(aksClusterNamespace) --set image.repository=$(registryName).azurecr.io/bonsai/$chart --set image.tag=${{ parameters.RELEASE_TAG }} --install  --atomic --cleanup-on-fail --wait --debug --timeout $timeout

    helmUpgradeExitCode=$?
    retries=$((retries-1))
    if test $helmUpgradeExitCode -ne 0; then
      # Something went wrong during helm upgrade command, potentially it timed out.
      if [ $retries -eq 0 ]; then
          echo "************ HELM UPGRADE FAILED FOR PACKAGE $chart WITH EXIT CODE ${helmUpgradeExitCode}. NO MORE RETRIES... ********"
          exit $helmUpgradeExitCode
      else
        # Helm Upgrade was not successful. Retry
        echo "************ HELM UPGRADE FAILED WITH EXIT CODE ${helmUpgradeExitCode}, RETRYING ${retries} MORE TIMES... ********"
      fi
    else
      # Helm Upgrade succeeded
      break
    fi

Error:
UPGRADING auth***********************
history.go:56: [debug] getting history for release auth
Error: failed to authorize: failed to fetch oauth token: unexpected status: 401 Unauthorized

What version of Helm are you using?

https://github.com/helm/helm/issues/10624

I still face this issue? Was there any solution?


Gold "answer" ID is not supposed to be 0 in the codah data set

For the CODAH dataset, since it is a multiple-choice question-answering task, we evaluate the
accuracy by measuring the exact match between the responses generated by LLMs and the provided gold
answers.
The ID of the gold answer is not supposed to be 0. The ID starts from 1. In the dataset (dataset/truthfulness/internal.json), the ID of certain gold answers is 0.
@HowieHwong

Hi @jinz2014,
Thank you for pointing out this issue. There was a typo in the prompt, and the index should have started from 0. We have corrected this typo and updated the internal.json file accordingly. Please refer to dataset.zip for the revised dataset.

Please take a look at the codes in trustllm/task/truthfulness.py for computing the metric.
def eval_internal_codah(self, data):

    for item in codah_data:
        response = item['res']
        prediction = re.findall(r"Answer: (\d+)", response)[0] if re.findall(r"Answer: (\d+)", response) else "0"

When the regular expression has no match, the prediction is 0..
Thanks

Yes, the evaluation needs to be changed accordingly to reflect the changes. I have changed the default indicator to be -1. Thank you for the reminder!


l3build: Option to halt on first failing test

It would sometimes be useful for the check system to halt on the first error: something like
build check --halt-on-error foo

which then requires optional arg parsing (see https://github.com/latex3/svn-mirror/issues/245).

Am 06.08.15 um 10:03 schrieb Joseph Wright:

It would sometimes be useful for the check system to halt on the first
error: something like
|build check --halt-on-error foo |
which then requires optional arg parsing (see #245
https://github.com/latex3/svn-mirror/issues/245).

probably, but I would suggest a short name like --halt

@FrankMittelbach Was based on the same option for engines, but can be negotiated once I work out how to do the underlying option parsing.

Am 06.08.15 um 10:14 schrieb Joseph Wright:

@FrankMittelbach https://github.com/FrankMittelbach Was based on the
same option for engines, but can be negotiated once I work out how to do
the underlying option parsing.

that's an argument in favor of your name ... mine was that I'm lazy and
don't like typing :-)

As at @wspr  says, do we really need to run all of the tests once we know something fails: should we just stop anyway?

I'd be in favour of by default stopping after the first that doesn't validate. OTOH, when running 20 tests, say, and 3 isolated ones fail, it is kind of nice to have those three diffs all available for querying after the fact. So I think we need both :)
If you want a low-tech solution, could just have build check and build checkall to distinguish these cases.

Can we also have a saveall target (or similar) that does texlua build.lua save <testfile> on each test file, but optimized to only unpack once?  Or something to only do that for some testfiles.  This would have been very useful to me when making changes to what packages send to the log.  The workflow then would be saveall then svn diff to check changes.

@blefloch  I suspect that can be covered by just save if I can move the engine argument from the end to an optional: something like save <file or files> will then be possible. As already noted, I first need to look seriously at aoptparse/argparse like functionality.

Am 06.08.15 um 10:43 schrieb Will Robertson:

I'd be in favour of by default stopping after the first that doesn't
validate. OTOH, when running 20 tests, say, and 3 isolated ones fail, it
is kind of nice to have those three diffs all available for querying
after the fact. So I think we need both |:)|

yes I  guess you need both but in my book the prio is the other way
around. Normally when I make a change I want to see side by side what
fails as often the first failure may not give enough info (so you are
likely to start fixing it just to learn that there is another failure
that invalids your approach)
So I'm more in favor of having the checkall being the default and the
one that stops being the one that is extra

If you want a low-tech solution, could just have |build check| and
|build checkall| to distinguish these cases.

therefore the low-tech fr me would be
build check     -> check all list results
build checkstop -> stop checking on first failure

I'm with @FrankMittelbach  on the default, hence suggesting --halt-on-error as an option. I think I can see how to implement this and --engine without needing 'full' argparse support (available for Lua but would mean adding a second Lua file as a dependency). The latter option might make more sense long-term, though, as it would mean we can continue to add options.

Agreed on the default as per Frank. Would prefer something less verbose than --halt-on-error though :)
Also agree with Bruno that saveall or similar would be useful. I'd be using it now to help migrate all my old unicode-math tests to my new build system, if it existed.

Regarding the default for checking and stopping (or not), I imagine that people's workflows (if they're anything like mine) are:

edit package, fix some bugs
build check (does everything without stopping)
breaks N tests
fix those new bugs
build check (everything now passes)
Futz around with document and code tidy-ups
build ctan

Now here's the thing. When build ctan re-checks the test suite, I'd like to know ASAP that one of my tests failed, and if that happened, the workflow above would loop back to an earlier step. So I'd argue that when performing build ctan, the default should be build checkstop or build check --halt-on-error or whatever it ends up being called :)
Of course, you can shoot me down and I won't complain, but I might request mildly for a way to customise it in the build.lua file.

All noted: I'll work on it over the coming days.

As detailed in https://github.com/latex3/svn-mirror/issues/245#issuecomment-128608082, suggested naming here is --halt-on-error/--halt-on-failure/-f: anything better occur to anyone? As also noted there, adding argparse-like functionality will allow use to extend check and save targets to cover multiple files. (That will require some internal changes, so first I'll add the parsing and then deal with things in stages!)


Webview safe-area-inset-* CSS variables are not available on initial page load.

Environment
  React Native Environment Info:
    System:
      OS: macOS High Sierra 10.13.6
      CPU: (8) x64 Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz
      Memory: 65.25 MB / 16.00 GB
      Shell: 5.3 - /bin/zsh
    Binaries:
      Node: 10.10.0 - /usr/local/bin/node
      npm: 6.4.1 - /usr/local/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
      Android SDK:
        API Levels: 26, 27, 28
        Build Tools: 27.0.3, 28.0.0
        System Images: android-27 | Google APIs Intel x86 Atom
    IDEs:
      Android Studio: 3.1 AI-173.4819257
      Xcode: 10.1/10B61 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.6.0-alpha.8af6728 => 16.6.0-alpha.8af6728
      react-native: 0.57.4 => 0.57.4
    npmGlobalPackages:
      react-native-cli: 2.0.1

Description
Inside a <Webview/> component, the env(safe-area-inset-*) css variables are not available until some arbitrary time after the page is loaded. However, they are immediately available in iOS Safari.
Reproducible Demo
https://github.com/ccorcos/react-native-demo/tree/safe-area-inset-bug
git clone https://github.com/ccorcos/react-native-demo.git
cd react-native-demo
git checkout safe-area-inset-bug
npm install
# Server the index.html file
python -m SimpleHTTPServer 8000
# Start react native
npm start
# Open Xcode and run the app.
open ios/chetapp.xcodeproj

This appears to be an issue with WebKit. I've created a demo without React Native here and submitted a webkit bug here. Please let me know if you have any ideas.

@ccorcos Thanks for the detailed bug report! It's not often we get such a well-prepared issue. :)
So this seems to be happening even without React Native, then? We can track it here, but I'd assume unless there's some workaround that we can implement, we'll have to wait for upstream to fix it.

Thanks 😄 Yeah, doesn't seem like we're going to fix this here. We can close it as it is tracked through webkit now.

@ccorcos Did you add viewport-fit=cover to your meta name="viewport" tag?
env() is depends on viewport-fit=cover, read more on https://developer.mozilla.org/en-US/docs/Web/CSS/env

@ccorcos did you find a workaround for this webkit bug? I'm having the same problem.

Same issue here with<EMAIL_ADDRESS>