implement regions

Some data formats have the concept of regions/submeshes/domains, e.g., gmsh and Exodus. Think about how to best integrate this into meshio.

Reading about Exodus boundary conditions, I see that besides what it calls 'element blocks', corresponding to the above, it also has 'nodesets' and 'sidesets', the last two being useful for boundary and initial conditions, and 'sides' being sides of elements.
I can immediately envisage 'nodesets' being useful for Dirichlet conditions.

Exodus Element Blocks are stricter than Gmsh Physical Regions; whereas the latter encode only the continuous concept of subdomain, the former mixes in the discrete notion of type of element.

Element Blocks (also referred to as simply, Blocks) are a logical grouping of elements all having the same basic geometry and number of nodes. All elements within an Element Block are required to have the same element type. (ibid)

In a 'quad-dominant' mesh of a surface, this would necessitate two blocks, for the triangles and quadrilaterals.  I can see computational advantages to this: the connectivity would be described by a rectangular matrix rather than a list. But it also seems like an admixture of concerns if one just wants to specify that a subdomain is of one material.

What would the computational advantage be of having the elemental group
data as matrix instead of a list? For one, a list (or list of lists) would
be much sparser, plus this information is already provided by meshio in the
form of dictionaries with list/array values, which I think is now provided
by the 'cells' and 'cell_data' objects.
On Fri, Dec 22, 2017, 21:17 Geordie McBain<EMAIL_ADDRESS>wrote:

Exodus Element Blocks are stricter than Gmsh Physical Regions; whereas the
latter encode only the continuous concept of subdomain, the former mixes in
the discrete notion of type of element.
Element Blocks (also referred to as simply, Blocks) are a logical grouping
of elements all having the same basic geometry and number of nodes. All
elements within an Element Block are required to have the same element
type. (ibid)
In a 'quad-dominant' mesh of a surface, this would necessitate two blocks,
for the triangles and quadrilaterals. I can see computational advantages to
this: the connectivity would be described by a rectangular matrix rather
than a list. But it also seems like an admixture of concerns if one just
wants to specify that a subdomain is of one material.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nschloe/meshio/issues/175#issuecomment-353668313, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AMTd7KePPmdbBvud0QNXM3SQ00aY8aZ8ks5tDA5wgaJpZM4RJrl-
.

Hmm. I was trying to second-guess why Exodus insisted on one type of element per block.
In which case each element has the same number of nodes and the array with entry [e, n] the global index of the n-th node in the e-th element would be 100% dense and perfectly rectangular, which I thought (at the risk of prematurely optimizing) might be more efficient to allocate and look up.
I didn't find an explicit statement of the motivation for the Exodus restriction yet, but thought it might be something like that.

As to the relation between this and what's currently in the meshio cell_data and field_data, I think they're like inverses, as discussed in the final comments yesterday on #169.

I'm not so keen on packing metadata into strings. dalcinl proposed more structured tags, which generally seems more Pythonic.

Well, Gmsh want's to store a string and an integer with each region. I guess that's what you get when you settle for a format like that, but it isn't pretty. I'm not a fan of making a tuple a key in dictionary, but, as suggested above, what we could do is simply store two separate things:

The regions as int-valued cell data arrays.
The string data as a dictionary (as part of field data)

I think that's more or less what we had done earlier anyways. Advantages of this:

The data structure maps 1:1 what gmsh does in physical and geometrical data.
It seamlessly integrates in our cell data array; no need to change the API.
Cell data can be written to almost all formats, so information isn't lost.

Disadvantages:

Each cells needs to have and only one value for each region array. This is fine for materials (after all, each cell is made of one), but you cannot simply mark a particular boundary set or so.
The Gmsh standard actually allow for marking more than physical and geometrical, but that's not covered here.

@gdmcbain By metadata I mean a special dict of something that is very specific to the format that you are reading from or writing to. For example, if you read gmsh and next write vtk, the vtk writer can just ignore this metadata, but if you write back gmsh, then you honor it. The use case is doing some pre-processing on the input mesh data, and writing it back in the same format. Of course, it is up to the user to doing the read-transform-write to update the metadata if needed.

@gdmcbain @nschloe Can you define what field_data means for you? Maybe yes, field_data is what I called metadata, but I'm not sure whether that's the actual meaning.

@dalcinl Remember we're discussing regions here. If it's about the a container class, please move you're contributions to the appropriate issue.

Yes, I know. Should be regions (or part of the info about them) be considered metadata that is too much format-specific?

First we have to decide how to do regions. If we decide to just wrap them as part of cell data (see suggestion above), we hardly need any meta data.

Perhaps cell_data is too much generic for enconding regions? For me, point_data and cell_data means scalar or vector fields on either points or cells, in the VTK sense. The gmsh format also support point and cell data (real values, not integers!), but confusing/mixing such data with regions was the root cause of my initial complaints.
If you still want to encode regions with cell data, that's fine, but we need to devise a mechanism to distinguish integral values (for gmsh regions, aka physical/elementary tags) from scalar/vector data (for gmsh NodeData or ElementData).

Perhaps cell_data is too much generic for enconding regions?

Generally you're right here. The thing is that Gmsh doesn't make use of the freedom: Both physical and geometrical data are simply integer arrays over cells, just like cell_data. The gmsh standard does actually allow for more flexibility by tagging, but I've never seen this used anywhere.

nut we need to devise a mechanism to distinguish integral values (for gmsh regions, aka physical/elementary tags)

That should be easy: The two region values of gmsh are called physical and geometrical.

What's in a name? :-) What would happen if you read from a VTK file with a cell data entry named physical with let say some scalar and vector field, and then you want to write out a gmsh file?
Anyway, you seem to suggest going back to previous approach where physical and geometrical were dumped in gmsh files as integer tags, and not as now in the $ElementData section. I'm certainly not opposed to that, I already said that IMHO the current behavior is a regression. However, maybe I would suggest to somehow namespace these special cell data names, let say something like gmsh:physical and gmsh:geometrical (or maybe region:physical to make it more format-independent), so now the gmsh writer can have some confidence that the data is actually meant to be dumped as region tags. With a bit of namespacing on the keys for cell data, I think you can go back to the original approach of using cell_data, and forget about a special  treatment for regions.

Thanks for clarifications.  This is all sounding O. K. too me as far as it goes, but…
I've just realized why I hadn't been bitten by the change as @dalcinl  was this time, whereas I had been back in #169.  I don't ask meshio to write .msh files, only read them, and that implicitly by using pygmsh.generate_mesh; the hidden temporary .msh files being written by Gmsh in a subprocess.  Thus far, I'm working directly with the five objects returned by generate_mesh (i.e. by meshio.read) and haven't needed to serialize the mesh; if I did, and chose meshio.write and Gmsh .msh for the purpose, I would have hit this problem, yes.  I would certainly have expected the physical tagging written by pygmsh and Gmsh into the $Element block to have persisted there.
So this isn't really about what I thought it was when this issue was launched in December; i.e. whether the data structure for the regions should be inverted.  This sounds more like #197, but I see that the discussion from there was moved back here.
To return it for the moment to the original question of which way the looking-up of regions should go, I see that Gmsh in the MSH format in the $Element block stores it as element -> region.  And if it were in $ElementData it would still be nearly the same: elm-number -> region, 'elm-number' being the index into the list or array of elements.  This means that if I only want to integrate over a region, I need to filter either of those look-ups to get the elements or elm-numbers that lie in the region of interest.  The intention of the inverse was to have dicts going the other way: region -> elm-number, so that such a traversal would be more direct.  I believe, as mentioned above, that this is what Exodus's 'element blocks' do, but studying the spec for Gmsh MSH again, I can't see any way to encode a mapping in that direction without inverting it.  It also sounds like VTK has no support for region -> elm-number either.  Is Exodus on its own?  Anyway, without support in Gmsh or VTK, it's maybe not worth having inverting the look-up read from the $Element block on the way in as one is just going to have to undo that on the way out in most cases.

@gdmcbain Thanks for your comment! If I would sign all of this I could.
For my own applications, I would rather need region -> elm-index, but as you point out correctly, this is unfortunately not what mesh formats implement. Granted, Exodus node sets and side sets is approximately that, but only for, well nodes and "sides". I don't know why they make this restriction. I'm almost inclined to create a new format to fix this once and for all. :wink:
Okay, I think this is how it's gonna go:

Implement regions as integer cell data. As for gmsh's groups, I like @dalcinl's suggestion to prefix the name; 'gmsh:physical' and 'gmsh:geometrical' are probably good enough.

If there ever comes a file format that does region -> element-index (or the need arises for Exodus node, side sets), we can always implement that as proper regions.

Alright, thanks everyone for hanging in there. I've just published 1.11.7 with the proposed fix.

@nschloe , I haven't used Exodus II too much myself (my current practice is to write pygmsh which writes .geo and calls Gmsh to convert that to .msh and calls meshio to read that and return the five objects points, cells, point_data, cell_data, field_data, then I bundle them up in a container object and do finite-element analysis from there) but my reading of the CUBIT documentation on Exodus II leads me to a more optimistic conclusion.

For my own applications, I would rather need region -> elm-index, but as you point out correctly, this is unfortunately not what mesh formats implement. Granted, Exodus node sets and side sets is approximately that, but only for, well nodes and "sides". I don't know why they make this restriction.

My reading of ‘Exodus boundary conditions/Element blocks’

Element Blocks (also referred to as simply, Blocks) are a logical grouping of elements all having the same basic geometry and number of nodes. All elements within an Element Block are required to have the same element type. Access to an Element Block is accomplished through a user-specified integer Block ID. Typically, Element Blocks can also be assigned material properties to associate material properties with a group of elements.

is that Element Blocks are indeed a mapping from region to element-index.  Doesn't it mean that Element Block is a region and it enumerates the elements belonging to it?
I'll try to experiment with Exodus II to see whether its Element Blocks indeed work as region -> element-index regions.  I notice that meshio.exodus_io.write ignores cell_data, so I'll use something else like libMesh or SEACAS.

What I'm thinking more generally, trying to not to be Gmsh-centric, is that some input or output formats will store regions as element -> region and some as region -> element.  (I'm not imagining any other possibilities than these two, though I did try to.)
It's true that we don't know of any mesh formats that support region -> element-index with elements being allowed to belong to more than one region, Exodus II with its Element Blocks does more work in the direction of region -> element than element -> region.
Another reference for the format (especially  ‘Anatomy of an Exodus II file’ in §3):

Kostka, T. D. (2013, January). Exomerge user's manual: A lightweight Python interface for manipulating Exodus files. Technical Report SAND2013-0725, Sandia National Laboratories, Livermore, California.

But anyway, not tying meshio too closely to any existing format, I wondered about whether the format-neutral data-structure that meshio builds and populates when called to read and uses when called to write, what if it had both possibilities?

element -> region, say implemented as at present in cell_data[type]['gmsh:physical']
region -> element, not yet implemented but maybe with a new dict cell_data['regions'].

Then in meshio.*_io.read, if reading:

a type 1 format such as Gmsh MSH, populate cell_data[type]['gmsh:physical']
a type 2 format, populate cell_data['regions']

Then in meshio.*_io.write, if we have

`cell_data[type]['gmsh:physical'] and we have to write

a type 1 format, that's easy, already implemented
a type 2 format, do the inversion.  Go through the `cell_data[type]['gmsh:physical'] and construct the maps region -> element

cell_data['regions'] and we have to write

a type 1 format, invert
a type 2 format, it should be straightforward.

I imagine not usually having both cell_data[type]['gmsh:physical'] and cell_data['regions'] in the same cell_data dict.

I was disappointed to learn by way of the above that

Even gmsh demands one and only one tag to be present for each cell in both physical and geometrical groups.

but indeed, from Gmsh's MSH ASCII file format:

By default, the first tag is the number of the physical entity to which the element belongs; the second is the number of the elementary geometrical entity to which the element belongs; the third is the number of mesh partitions to which the element belongs, followed by the partition ids (negative partition ids indicate ghost cells). A zero tag is equivalent to no tag. Gmsh and most codes using the MSH 2 format require at least the first two tags (physical and elementary tags).

That's quite a shortcoming.  I wondered what happens if two physical entities are defined that overlap.  I tried this with:
Point (1) = {0, 0, 0, 1};
Point (2) = {1, 0, 0, 1};
Point (3) = {2, 0, 0, 1};

Line (1) = {1, 2};
Line (2) = {2, 3};

Physical Line("left", 1) = {1};
Physical Line("all", 2) = {1, 2};

and found that Gmsh makes two lots of elements over 0 < x < 1.
$MeshFormat
2.2 0 8
$EndMeshFormat
$PhysicalNames
2
1 1 "left"
1 2 "all"
$EndPhysicalNames
$Nodes
3
1 0 0 0
2 1 0 0
3 2 0 0
$EndNodes
$Elements
3
1 1 2 1 1 1 2
2 1 2 2 1 1 2
3 1 2 2 2 2 3
$EndElements

The first two elements here have the same endpoints.
I suppose in practice (and I'm very surprised that I haven't hit this yet in my work) that what one would have to do is define three separate physical entities for the intersection and two relative complements and then use the union of the intersection and one of the two relative complements.  Not nice.

Thanks Geordie for the concise write-up!

what if it had both possibilities?

Yeah that'd be nice to have. I believe it'd make sense to wait for an actual use case of this and then design meshio around that. Having cell_data['regions'] will certainly a possibility, another is regions[name], but really we don't have to decide that before a user comes along with a mesh format that supports that.

That's quite a shortcoming. I wondered what happens if two physical entities are defined that overlap. I tried this with: [...]

Very interesting discovery! I'm surprised that not even Gmsh itself makes proper use of its tags. That makes me wonder why they didn't use $ElementData, or why that mesh format was created in the first place when VTK & friends were already around. Well, well...

I wondered what happens if two physical entities are defined that overlap.

This was touched on by C. Geuzaine (2018-09-06) as one of the motivations for the introduction of MSH4 #280.

The handling of physical groups in version 2 had numerous issues (see https://gitlab.onelab.info/gmsh/gmsh/issues/94). Two of the most serious were that

if you defined more than 1 group for a given geometrical entity, the elements would be duplicated
storing the physical group for each element was wasteful (as many integers as elements, instead of a single one)

These points might guide #289.


[Feature] Sync with repo

Hey, it would be really cool to allow for improved syncronization with a repository.
I imagine a way to login to a github repo from the plugin and link to a specific .json file with the structure in it. Whenever the file changes, the plugin could show an update button or something to pull in the latest changes.
Why?
A common issue is that docs, code playgrounds and figma get out of sync. Automating the update process and putting the source of truth onto github could help a lot.

I agree on this being a great addition. This would also unblock desires for additional "global" node-type based templates. eg #21. Currently thinking over a few different approaches here. One being OAuth'd as you describe, also considering a lighter lift public JSON endpoint sync as a good first step in that direction.
Additionally, our team is thinking about something like this at a feature level, so the request itself is great feedback I'm sending that way.


Mobile: Account/Search/Chromecast button group needs a little bit more spacing on the right side

Describe the bug
The account+chromecast+search button group(top right corner) needs a little bit more spacing on the right side. Also, the scroll bar overlaps it.
To Reproduce

Open Jellfin in Safari browser
Add Jellfin to home
Open Jellyfin Safari app
Login to Jellyfin

On a Smartphone or Tablet?

iPhone 15 Pro

Are you using any extra code in your "Custom CSS" field?

No

Screenshots

I just pushed a change to fix this. Lmk if the issue persists.


Northstar <IP_ADDRESS> Access Violation

Bug
Played Titan Brawl when game suddenly crashed. Not sure if there are any viable repro steps I could provide.
Log:
[11:45:17] [NORTHSTAR] [errr] Northstar version: <IP_ADDRESS>
[11:45:17] [NORTHSTAR] [errr] Northstar has crashed! a minidump has been written and exception info is available below:
[11:45:17] [NORTHSTAR] [errr] Loaded mods:
[11:45:17] [NORTHSTAR] [errr] Northstar.Client 1.11.1
[11:45:17] [NORTHSTAR] [errr] Northstar.CustomServers 1.11.1
[11:45:17] [NORTHSTAR] [errr] Northstar.Custom 1.11.1
[11:45:17] [NORTHSTAR] [errr] Access Violation: Attempted to read from: 0xFFFFFFFFFFFFFFFF
[11:45:17] [NORTHSTAR] [errr] At: client.dll + 0x48ed73
[11:45:17] [NORTHSTAR] [errr]
[11:45:17] [NORTHSTAR] [errr] Stack trace:
[11:45:17] [NORTHSTAR] [errr]     Module Name             Offset   Full Address
[11:45:17] [NORTHSTAR] [errr] ---------------------------------------------------
[11:45:17] [NORTHSTAR] [errr]     client.dll              0x48ed73 0x7ffa3a0fed73
[11:45:17] [NORTHSTAR] [errr]     client.dll              0x48ed05 0x7ffa3a0fed05
[11:45:17] [NORTHSTAR] [errr]     client.dll              0x46320a 0x7ffa3a0d320a
[11:45:17] [NORTHSTAR] [errr]     client.dll              0x463022 0x7ffa3a0d3022
[11:45:17] [NORTHSTAR] [errr]     client.dll              0x1957eb 0x7ffa39e057eb
[11:45:17] [NORTHSTAR] [errr]     engine.dll              0xb95da  0x7ffa05b595da
[11:45:17] [NORTHSTAR] [errr]     engine.dll              0x15a054 0x7ffa05bfa054
[11:45:17] [NORTHSTAR] [errr]     engine.dll              0x159bf8 0x7ffa05bf9bf8
[11:45:17] [NORTHSTAR] [errr]     engine.dll              0x157970 0x7ffa05bf7970
[11:45:17] [NORTHSTAR] [errr]     engine.dll              0x16e9f6 0x7ffa05c0e9f6
[11:45:17] [NORTHSTAR] [errr]     engine.dll              0x16dbcb 0x7ffa05c0dbcb
[11:45:17] [NORTHSTAR] [errr]     Northstar.dll           0xcab66  0x7ffaa1a7ab66
[11:45:17] [NORTHSTAR] [errr]     engine.dll              0x1c88c0 0x7ffa05c688c0
[11:45:17] [NORTHSTAR] [errr]     Northstar.dll           0x12344e 0x7ffaa1ad344e
[11:45:17] [NORTHSTAR] [errr]     engine.dll              0x1c65ae 0x7ffa05c665ae
[11:45:17] [NORTHSTAR] [errr]     engine.dll              0x390e2d 0x7ffa05e30e2d
[11:45:17] [NORTHSTAR] [errr]     engine.dll              0x1c79d9 0x7ffa05c679d9
[11:45:17] [NORTHSTAR] [errr]     engine.dll              0x1c793c 0x7ffa05c6793c
[11:45:17] [NORTHSTAR] [errr]     launcher.dll            0x15afd  0x7ffad8345afd
[11:45:17] [NORTHSTAR] [errr]     launcher.dll            0x15afd  0x7ffad8345afd
[11:45:17] [NORTHSTAR] [errr]     launcher.dll            0xd386   0x7ffad833d386
[11:45:17] [NORTHSTAR] [errr]     NorthstarLauncher.exe   0x491d   0x7ff61c4c491d
[11:45:17] [NORTHSTAR] [errr]     NorthstarLauncher.exe   0x80a8   0x7ff61c4c80a8
[11:45:17] [NORTHSTAR] [errr]     KERNEL32.DLL            0x126bd  0x7ffb158126bd
[11:45:17] [NORTHSTAR] [errr]     ntdll.dll               0x5dfb8  0x7ffb1718dfb8
[11:45:17] [NORTHSTAR] [errr]
[11:45:17] [NORTHSTAR] [errr] Flags: 0b100000000000001011111
[11:45:17] [NORTHSTAR] [errr] RIP: 0x7ffa3a0fed73
[11:45:17] [NORTHSTAR] [errr] CS : 0x33
[11:45:17] [NORTHSTAR] [errr] DS : 0x2b
[11:45:17] [NORTHSTAR] [errr] ES : 0x2b
[11:45:17] [NORTHSTAR] [errr] SS : 0x2b
[11:45:17] [NORTHSTAR] [errr] FS : 0x53
[11:45:17] [NORTHSTAR] [errr] GS : 0x2b
[11:45:17] [NORTHSTAR] [errr] RAX: 0x409a507c409a507c
[11:45:17] [NORTHSTAR] [errr] RBX: 0x28e07b5f100
[11:45:17] [NORTHSTAR] [errr] RCX: 0x28e09fc1880
[11:45:17] [NORTHSTAR] [errr] RDX: 0x7ffa3c46af10
[11:45:17] [NORTHSTAR] [errr] RSI: 0x0
[11:45:17] [NORTHSTAR] [errr] RDI: 0x28e07b5f100
[11:45:17] [NORTHSTAR] [errr] RBP: 0x28e07b5f100
[11:45:17] [NORTHSTAR] [errr] RSP: 0xf9f57aefc0
[11:45:17] [NORTHSTAR] [errr] R8 : 0x28e0888b2a0
[11:45:17] [NORTHSTAR] [errr] R9 : 0x69
[11:45:17] [NORTHSTAR] [errr] R10: 0x28ea19deeac
[11:45:17] [NORTHSTAR] [errr] R11: 0xf9f57af070
[11:45:17] [NORTHSTAR] [errr] R12: 0x7ffad8395701
[11:45:17] [NORTHSTAR] [errr] R13: 0x0
[11:45:17] [NORTHSTAR] [errr] R14: 0x1
[11:45:17] [NORTHSTAR] [errr] R15: 0x1
[11:45:17] [NORTHSTAR] [errr] Xmm0 : [ 532.947, 0, 0, 0], [ 0x44053ca1, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm1 : [ 532.94, 0, 0, 0], [ 0x44053c2c, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm2 : [ 0.12816, 0, 0, 0], [ 0x3e033c60, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm3 : [ 536.847, 0, 0, 0], [ 0x4406362e, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm4 : [ 131289, 0, 0, 0], [ 0x48003644, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm5 : [ 2.46628E+06, 0, 0, 0], [ 0x4a1687ad, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm6 : [ 0.0166667, 0, 0, 0], [ 0x3c888889, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm7 : [ 8.36738E+27, 4.5906, 0, 0], [ 0x6dd84aaf, 0x4092e62e, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm8 : [ 0.0145263, 0, 0, 0], [ 0x3c6dff90, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm9 : [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm10: [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm11: [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm12: [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm13: [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm14: [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[11:45:17] [NORTHSTAR] [errr] Xmm15: [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]

[process exited with code 100 (0x00000064)]

Specifications

Northstar version: <IP_ADDRESS>
Platform: Origin, Win11

Dump and log file
nsdump2023-01-02 11-45-17.zip
nslog2023-01-02 11-25-06.txt

i'm seeing on 1.12 as well
[23:28:38] [NORTHSTAR] [info] To spectate, type in console: SPEC NAMEOFPLAYER  (Press A or D to change players)
[23:28:46] [SCRIPT CL] [info] titan
[23:28:49] [SCRIPT CL] [info] entity (11: player [11])
[23:28:54] [SCRIPT CL] [info] entity (5: player [5])
[23:28:59] [SCRIPT CL] [info] entity (5: player [5])
[23:29:01] [SCRIPT CL] [info] entity (5: player [5])
[23:29:04] [SCRIPT CL] [info] entity (5: player [5])
[23:29:06] [SCRIPT CL] [info] entity (5: player [5])
[23:29:11] [SCRIPT CL] [info] entity (5: player [5])
[23:29:16] [SCRIPT CL] [info] 0.48 1
[23:29:22] [SCRIPT CL] [info] titan
[23:29:33] [SCRIPT CL] [info] entity (9: player [9])
[23:29:33] [SCRIPT CL] [info] Core Earned
[23:29:40] [SCRIPT CL] [info] entity (11: player [11])
[23:29:44] [SCRIPT CL] [info] entity (11: player [11])
[23:30:01] [SCRIPT UI] [info] UICodeCallback_LevelLoadingFinished:  (true)
[23:30:01] [SCRIPT UI] [info] UICodeCallback_CloseAllMenus
[23:30:01] [SCRIPT UI] [info] UICodeCallback_ErrorDialog: Connection to server timed out.
[23:30:01] [NORTHSTAR] [info] Set playlist to tdm
[23:30:01] [SCRIPT UI] [info] UICodeCallback_LevelShutdown: mp_angel_city
[23:30:01] [NORTHSTAR] [error] Northstar version: <IP_ADDRESS>
[23:30:01] [NORTHSTAR] [error] Northstar has crashed! a minidump has been written and exception info is available below:
[23:30:01] [NORTHSTAR] [error] Loaded mods:
[23:30:01] [NORTHSTAR] [error] Northstar.Client 1.12.0
[23:30:01] [NORTHSTAR] [error] Northstar.CustomServers 1.12.0
[23:30:01] [NORTHSTAR] [error] Northstar.Custom 1.12.0
[23:30:01] [NORTHSTAR] [error] Access Violation: Attempted to read from: 0x0000023300000000
[23:30:01] [NORTHSTAR] [error] At: client.dll + 0x3cba7
[23:30:01] [NORTHSTAR] [error]
[23:30:01] [NORTHSTAR] [error] Stack trace:
[23:30:01] [NORTHSTAR] [error]     Module Name             Offset   Full Address
[23:30:01] [NORTHSTAR] [error] ---------------------------------------------------
[23:30:01] [NORTHSTAR] [error]     client.dll              0x3cba7  0x233c3dbcba7
[23:30:01] [NORTHSTAR] [error]     client.dll              0x358c   0x233c3d8358c
[23:30:01] [NORTHSTAR] [error]     client.dll              0x391ef1 0x233c4111ef1
[23:30:01] [NORTHSTAR] [error]     client.dll              0x3411e  0x233c3db411e
[23:30:01] [NORTHSTAR] [error]     client.dll              0x2ffec  0x233c3daffec
[23:30:01] [NORTHSTAR] [error]     client.dll              0x350a3  0x233c3db50a3
[23:30:01] [NORTHSTAR] [error]     client.dll              0x86c5   0x233c3d886c5
[23:30:01] [NORTHSTAR] [error]     client.dll              0x108a8  0x233c3d908a8
[23:30:01] [NORTHSTAR] [error]     client.dll              0x319e81 0x233c4099e81
[23:30:01] [NORTHSTAR] [error]     client.dll              0x31bf8c 0x233c409bf8c
[23:30:01] [NORTHSTAR] [error]     client.dll              0x3f2a58 0x233c4172a58
[23:30:01] [NORTHSTAR] [error]     client.dll              0x3ee9cb 0x233c416e9cb
[23:30:01] [NORTHSTAR] [error]     client.dll              0xfd788  0x233c3e7d788
[23:30:01] [NORTHSTAR] [error]     client.dll              0x1a6dd8 0x233c3f26dd8
[23:30:01] [NORTHSTAR] [error]     client.dll              0x1942a4 0x233c3f142a4
[23:30:01] [NORTHSTAR] [error]     engine.dll              0x72b19  0x7ff92c532b19
[23:30:01] [NORTHSTAR] [error]     engine.dll              0x8dde3  0x7ff92c54dde3
[23:30:01] [NORTHSTAR] [error]     engine.dll              0x15ac4d 0x7ff92c61ac4d
[23:30:01] [NORTHSTAR] [error]     engine.dll              0x15973b 0x7ff92c61973b
[23:30:01] [NORTHSTAR] [error]     engine.dll              0x157970 0x7ff92c617970
[23:30:01] [NORTHSTAR] [error]     engine.dll              0x16e9f6 0x7ff92c62e9f6
[23:30:01] [NORTHSTAR] [error]     engine.dll              0x16dbcb 0x7ff92c62dbcb
[23:30:01] [NORTHSTAR] [error]     Northstar.dll           0xa79a6  0x7ff985a279a6
[23:30:01] [NORTHSTAR] [error]     engine.dll              0x1c88c0 0x7ff92c6888c0
[23:30:01] [NORTHSTAR] [error]     Northstar.dll           0xa864e  0x7ff985a2864e
[23:30:01] [NORTHSTAR] [error]     engine.dll              0x1c65ae 0x7ff92c6865ae
[23:30:01] [NORTHSTAR] [error]     engine.dll              0x390e2d 0x7ff92c850e2d
[23:30:01] [NORTHSTAR] [error]     engine.dll              0x1c79d9 0x7ff92c6879d9
[23:30:01] [NORTHSTAR] [error]     engine.dll              0x1c793c 0x7ff92c68793c
[23:30:01] [NORTHSTAR] [error]     launcher.dll            0x15afd  0x7ffa47425afd
[23:30:01] [NORTHSTAR] [error]     launcher.dll            0x15afd  0x7ffa47425afd
[23:30:01] [NORTHSTAR] [error]     launcher.dll            0xd386   0x7ffa4741d386
[23:30:01] [NORTHSTAR] [error]     NorthstarLauncher.exe   0x491d   0x7ff6ba4b491d
[23:30:01] [NORTHSTAR] [error]     NorthstarLauncher.exe   0x80a8   0x7ff6ba4b80a8
[23:30:01] [NORTHSTAR] [error]     KERNEL32.DLL            0x126bd  0x7ffa8deb26bd
[23:30:01] [NORTHSTAR] [error]     ntdll.dll               0x5dfb8  0x7ffa8e6edfb8
[23:30:01] [NORTHSTAR] [error]
[23:30:01] [NORTHSTAR] [error] Flags: 0b100000000000001011111
[23:30:01] [NORTHSTAR] [error] RIP: 0x233c3dbcba7
[23:30:01] [NORTHSTAR] [error] CS : 0x33
[23:30:01] [NORTHSTAR] [error] DS : 0x2b
[23:30:01] [NORTHSTAR] [error] ES : 0x2b
[23:30:01] [NORTHSTAR] [error] SS : 0x2b
[23:30:01] [NORTHSTAR] [error] FS : 0x53
[23:30:01] [NORTHSTAR] [error] GS : 0x2b
[23:30:01] [NORTHSTAR] [error] RAX: 0x23300000000
[23:30:01] [NORTHSTAR] [error] RBX: 0x0
[23:30:01] [NORTHSTAR] [error] RCX: 0x233ec2f1080
[23:30:01] [NORTHSTAR] [error] RDX: 0x23300000000
[23:30:01] [NORTHSTAR] [error] RSI: 0x233eaca8140
[23:30:01] [NORTHSTAR] [error] RDI: 0xffffffff
[23:30:01] [NORTHSTAR] [error] RBP: 0x23300000000
[23:30:01] [NORTHSTAR] [error] RSP: 0x56be5ae400
[23:30:01] [NORTHSTAR] [error] R8 : 0xffffffff
[23:30:01] [NORTHSTAR] [error] R9 : 0xb6b
[23:30:01] [NORTHSTAR] [error] R10: 0x1000
[23:30:01] [NORTHSTAR] [error] R11: 0x56be5ae480
[23:30:01] [NORTHSTAR] [error] R12: 0xd9e
[23:30:01] [NORTHSTAR] [error] R13: 0xdad
[23:30:01] [NORTHSTAR] [error] R14: 0x233e9801500
[23:30:01] [NORTHSTAR] [error] R15: 0x233ec2f1080
[23:30:01] [NORTHSTAR] [error] Xmm0 : [ 2.94782E+20, 7.88931E-43, 3.38545E+20, 7.88931E-43], [ 0x617faec0, 0x233, 0x6192d200, 0x233 ]
[23:30:01] [NORTHSTAR] [error] Xmm1 : [ 3590.46, 0, 0, 0], [ 0x4560675c, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm2 : [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm3 : [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm4 : [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm5 : [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm6 : [ 0.0153198, 0, 0, 0], [ 0x3c7b0000, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm7 : [ 31.4126, 5.37658, 0, 0], [ 0x41fb4d13, 0x40ac0ce8, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm8 : [ 0.0144374, 0, 0, 0], [ 0x3c6c8ac6, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm9 : [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm10: [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm11: [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm12: [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm13: [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm14: [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]
[23:30:01] [NORTHSTAR] [error] Xmm15: [ 0, 0, 0, 0], [ 0x0, 0x0, 0x0, 0x0 ]

These are two different crashes btw


Dockerized application for local development, testing and deployment

Relates to:
Distribution.
Risks
Low. Could potentially cause confusion to those unfamiliar with Docker.
Background
What does this PR do?
This PR aims to improve Eliza ergonomics by providing a one liner for getting up and running via Docker.
What kind of change is this?
Development or infrastructure support.
Why are we doing this? Any context or related work?
Improve Eliza accessibility.
Documentation changes needed?
Updated README.
Testing
Where should a reviewer start?
Detailed testing steps
docker:build
docker:run
docker:bash

Deploy Notes
We could potentially add CI/CD. Or an official Docker image. Thoughts?
Database changes
N/A

Dockerfile Audit and Suggested Improvements
The current Dockerfile implementation has several areas that could be improved to enhance performance, security, and maintainability. Here’s a detailed list of suggested changes:

No .dockerignore File

Without a .dockerignore, unnecessary files and folders (e.g., .git, node_modules, logs) are included in the Docker build context. This increases image size and build time.
Suggested Fix: Add a .dockerignore file to exclude files not needed in the container.

Inefficient Layer Caching

Dependencies are installed multiple times, which prevents effective caching. Additionally, using separate ADD commands for configuration files results in multiple layers.
Suggested Fix: Consolidate the ADD commands for configuration files and install dependencies in a single step. Run pnpm i only once after adding all configuration files.

Redundant RUN pnpm i Commands

Dependencies are installed three times throughout the Dockerfile, increasing build time.
Suggested Fix: Install dependencies once, after copying all necessary configuration files, to streamline the build process.

Lack of Multi-Stage Build for Production

A single-stage build may result in unnecessary development dependencies being included in the final image, which increases image size and introduces security risks.
Suggested Fix: Use a multi-stage build to separate build dependencies from the final production image, ensuring only essential files are included.

Unoptimized CMD Command

The CMD ["tail", "-f", "/dev/null"] keeps the container idle and suggests the container isn’t configured to run the application.
Suggested Fix: Replace CMD with the actual command to start the application, such as CMD ["pnpm", "start"].

Direct Inclusion of Environment Variables (.env File)

Adding the .env file with ADD exposes sensitive information in the Docker image. This can pose security risks if the image is pushed to a registry.
Suggested Fix: Use Docker secrets or pass environment variables at runtime to secure sensitive data.

Lack of Non-Root User

The container runs as the root user by default, which can lead to security vulnerabilities if exploited.
Suggested Fix: Create a non-root user and run the application under this user. Example:RUN adduser -D appuser
USER appuser

Missing Port Exposure

If the application is meant to run a service (e.g., a web server), the container should expose the relevant port.
Suggested Fix: Add an EXPOSE <port> statement for documentation and networking purposes.

Lack of .npmrc Caching

If .npmrc contains specific registry or authentication settings, it should be added before dependency installation for caching purposes and authentication consistency.
Suggested Fix: Add .npmrc before running pnpm i to leverage caching and reduce unnecessary network requests.

Unused docs Directory

Adding docs to the image increases its size without being used by the application.
Suggested Fix: Remove the docs directory from the Dockerfile unless it’s necessary for runtime.

Inconsistent Dependency Installation

Multiple installations of dependencies without clearing caches or pinning versions may lead to conflicts or unexpected updates.
Suggested Fix: Ensure dependencies are installed consistently in one step, and pin specific versions where possible.

Missing Health Checks

Without a health check, monitoring systems like Kubernetes cannot accurately assess the container’s health.
Suggested Fix: Add a health check for better monitoring, e.g.:HEALTHCHECK CMD curl -f http://localhost:<port> || exit 1

Suggested Refactored Dockerfile
Here’s a refactored Dockerfile with the suggested improvements:
# Stage 1: Build dependencies in a temporary stage
FROM node:23.1.0 AS builder

# Set working directory
WORKDIR /app

# Copy config files and install dependencies
ADD pnpm-workspace.yaml package.json .npmrc pnpm-lock.yaml /app/
RUN npm install -g<EMAIL_ADDRESS>&& pnpm i

# Copy application files
ADD tsconfig.json /app/tsconfig.json
ADD packages /app/packages
ADD scripts /app/scripts
ADD characters /app/characters

# Optional: build step if using TypeScript or other build process
# RUN pnpm build

# Stage 2: Create final image for production
FROM node:23.1.0-alpine

# Create a non-root user and switch to it
RUN adduser -D appuser
USER appuser

# Set working directory and copy only necessary files from the builder stage
WORKDIR /app
COPY --from=builder /app .

# Expose application port
EXPOSE 3000  # Change to the actual app port

# Set the default command to run the application
CMD ["pnpm", "start"]

Merging this in would help to reduce exposure of the developers machine to the community developed code. A huge plus for me as a developer.


feat: Add WindowCornerHintsProperty

What does the pull request do?
This PR adds a new StyledProperty to the Window class: WindowCornerHintsProperty, which provides hints for window corner appearance. The hint is only used on Windows, as only this platform supports controlling corner appearance.
This is required for Classic.Avalonia theme to look good.
What is the current behavior?
Currently, there is no way to control window corners; it is up to Avalonia to decide which corner style to use.
What is the updated/expected behavior with this PR?
When WindowCornerHintsProperty is set to default platform, round, or do not round, the appropriate corner preference is used. However, by default, WindowCornerHintsProperty has the value NoHint, which indicates that it is up to Avalonia to decide which corner style should be used. This way, the default behavior is the same as it is now.
How was the solution implemented (if it's not obvious)?
This PR follows the implementation of ExtendClientAreaChromeHintsProperty.
Checklist

[ ] Added unit tests (if possible)?
[ ] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation.

Breaking changes
Obsoletions / Deprecations
Fixed issues
Fixes #17294

This API makes sense to me as part of Win32Properties class: https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Controls/Platform/Win32Properties.cs#L17. Not xplat.

This API makes sense to me as part of Win32Properties class: https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Controls/Platform/Win32Properties.cs#L17. Not xplat.

Oh, I didn't know about Win32/Mac/X11 Properties classes. I have updated the PR, now it adds a new attached property in Win32Properties, it makes much more sense


Update docs how to use OperatorHub.io on OpenShift

What type of PR is this?
/kind documentation
What this PR does / why we need it:
This adds an example CatalogSource to install the operator directly on OpenShift.
Which issue(s) this PR fixes:

None
Does this PR have test?
None

Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

Added documentation about how to install the operator on OpenShift via OperatorHub.

Codecov Report

Merging #1145 (5f3cc70) into main (5a2122a) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1145   +/-   ##
=======================================
  Coverage   50.70%   50.70%
=======================================
  Files          42       42
  Lines        4753     4753
=======================================
  Hits         2410     2410
  Misses       2266     2266
  Partials       77       77


Linux packages JSON format

We have a packages file in markdown format currently. The JSON file is intended to be the source of truth and to be used to generate the markdown file (proposal in place for both formats).
I made a few design choices:

Separate logical from physical packages.
Document all the interesting notes (including the scenarios) on the logical packages, keeping the physical package info as lean (and duplication-free) as possible.
Order the packages such that it is likely/possible to be able to foreach+install (like curl + jq + bash) required packages for both NAOT or CoreCLR w/o installing anything extra. This fits a bit into the "clever" category.

The intent is that any distro can be added here. NuGet packages are missing. We can add those, too.
I started with .NET 9 to prove out the idea. Adding the other .NET versions is trivial since the packages are all the same. The only difference is that the distro versions may fully, partially or not at all overlap. It's another example of a historical document.
I named this linux-packages.json to match linux-packages.md. It would be good to add platforms like FreeBSD here, too. I'm wondering if now is a good time to rename these files as required-packages.json or runtime-deps.json or similar.
Note: Here is a very similar past effort: https://github.com/dotnet/core/blob/main/release-notes/6.0/runtime-deps.json
@mthalman @ashnaga @Falco20019 @omajid @leecow

Here's a demo of one way the JSON format can be used.
$ docker run --rm -it ubuntu:24.04
root@243a281eaab7:/# curl -s https://raw.githubusercontent.com/dotnet/core/linux-packages/release-notes/9.0/linux-packages.json | jq -r .distributions[2].releases[1].packages[0:7][].name | xargs echo
libc6 libgcc-s1 ca-certificates libssl3t64 libstdc++6 libicu74 tzdata
root@243a281eaab7:/# apt install $(curl -s https://raw.githubusercontent.com/dotnet/core/linux-packages/release-notes/9.0/linux-packages.json | jq -r .distributions[2].releases[1].packages[0:7][].name | xargs echo)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libc6 is already the newest version (2.39-0ubuntu8.2).
libgcc-s1 is already the newest version (14-20240412-0ubuntu1).
ca-certificates is already the newest version (20240203).
ca-certificates set to manually installed.
libssl3t64 is already the newest version (3.0.13-0ubuntu3.1).
libstdc++6 is already the newest version (14-20240412-0ubuntu1).
The following NEW packages will be installed:
  libicu74 tzdata
0 upgraded, 2 newly installed, 0 to remove and 2 not upgraded.
Need to get 11.1 MB of archives.
After this operation, 38.5 MB of additional disk space will be used.

I really just meant that it would be good to have the option to include FreeBSD (and the like) in this list. I agree that including Windows is a step too far. Also, the product doesn't have dependencies on macOS or Windows.
Yes, there are other opportunities to use dependency lists. One of the things I learned from my other efforts is that generating markdown is sufficient for validating the schema and ensuring that the data is maintained.

Thanks: )
On Mon, Jul 15, 2024 at 4:27 PM Rich Lander @.***>
wrote:

We have a packages file in markdown format currently. The JSON file is
intended to be the source of truth and to be used to generate the markdown
file (coming shortly).
I made a few design choices:

Separate logical from physical packages.
Document all the interesting notes (including the scenarios) on the
logical packages, keeping the physical package info as lean (and
duplication-free) as possible.
Order the packages such that it is likely/possible to be able to
foreach+install (like curl + jq + bash) required packages for both NAOT or
CoreCLR w/o installing anything extra. This fits a bit into the "clever"
category.

NuGet packages are missing. We can add those, too.
You can view, comment on, or merge this pull request online at:
https://github.com/dotnet/core/pull/9412
Commit Summary

3f99a91
https://github.com/dotnet/core/pull/9412/commits/3f99a91ad805836d1be12e07d0462e414465c27a
Add packages JSON file
8b7ee12
https://github.com/dotnet/core/pull/9412/commits/8b7ee12ea7d483681cf8b7d3837c64adb5b6c895
Reformat document
893f323
https://github.com/dotnet/core/pull/9412/commits/893f323a7b9c41855ff5c4794d2de88fb2a510a3
Remove zlib

File Changes
(1 file https://github.com/dotnet/core/pull/9412/files)

A release-notes/9.0/linux-packages.json
https://github.com/dotnet/core/pull/9412/files#diff-3ed3a98fa356b79397c55d2e219d8be11183631e470481bd364e0cefd7f3f78c
(386)

Patch Links:

https://github.com/dotnet/core/pull/9412.patch
https://github.com/dotnet/core/pull/9412.diff

—
Reply to this email directly, view it on GitHub
https://github.com/dotnet/core/pull/9412, or unsubscribe
https://github.com/notifications/unsubscribe-auth/BA7FZAXNKSLV6HZTST4G6QTZMRLFHAVCNFSM6AAAAABK5OTPCWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQYDSOBQGY3DMMI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I added a formats description based on the request from @mthalman for more information on the new format. I'm sure that more can be added to the descriptions. I'll add more as I go. Feel free to do same.
https://github.com/dotnet/core/pull/9412/commits/489d5cdb1b58264e2900fc8e9a633a4e080ac9d2

Good question for @leecow.
https://github.com/dotnet/core/pull/9412#discussion_r1681212234

I don't feel strongly that they should match but it's worth looking at. I do agree that any schema we post should include description and example fields.

@eiriktsarpalis explained to me how to add descriptions with the generated schema. I'll give that a try. Might be a good customer sample!
@mthalman and I chatted about the name. We agreed that linux-packages.json isn't the best name because we want to file to be a natural home for BSD packages, too. How about package-deps.json? It's not a perfect name, but I also don't have another suggestion. I'd then go with a matching MD file for .NET 9+ and have mis-matched files for earlier versions (to avoid a needless breaking change).

I created an issue for the release-specific files.
https://github.com/dotnet/core/issues/9417

@mthalman -- How does this look?
https://github.com/dotnet/core/pull/9412/commits/03af9b669257a2bc4603bb95c5a7e8f0dee2f727
The schema is still generated. I used DescriptionAttribute on each type in the model (plus a little code) and this is the result. Quite an effective pattern.

Back to naming. I don't want to continue with linux-packages because "linux" is too narrow.
I propose "os-packages.json". It sort of fits with supported-os.json where the context is an OS. It also means that we can add any OS to this that we see fit, Linux, Unix, or something else.

I think we're getting close to a final review on this PR. I believe I've addressed the bulk of the feedback to date.

One step closer. I applied the patterns provided by @eiriktsarpalis, which helped a lot.
How is it looking @mthalman?

Hi: )
On Thu, Jul 18, 2024 at 10:03 PM Rich Lander @.***>
wrote:

@.**** commented on this pull request.
On release-notes/schema/dotnet-required-packages.json
https://github.com/dotnet/core/pull/9412#discussion_r1683791353:
Done.
—
Reply to this email directly, view it on GitHub
https://github.com/dotnet/core/pull/9412#discussion_r1683791353, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/BA7FZAX4GZVPYIENGVRWUVTZNCM35AVCNFSM6AAAAABK5OTPCWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCOBXGMYTCOJXGM
.
You are receiving this because you commented.Message ID:
@.***>

I added a new min-version concept for packages. @bartonjs and @vcsjones are considering increasing the min-version of OpenSSL to 1.1.1 (which is likely a good idea). I wanted to try that out. I updated the schema, included this particular example in the JSON, and included this data in the "Notes" section of the markdown table.
https://github.com/dotnet/core/blob/3a8b35f332e4185340b4a3eae54a1a5936c8b180/release-notes/9.0/os-packages.json#L40

Will you sponsor me. @.*** Thanks-peace out
On Sat, Jul 20, 2024 at 4:31 PM Rich Lander @.***>
wrote:

@.**** commented on this pull request.
In release-notes/schemas/dotnet-os-packages.json
https://github.com/dotnet/core/pull/9412#discussion_r1685551281:

         "array",

         "null"

       ],

       "items": {

         "type": [

           "string",

           "null"

         ]

       }

     }

   },

   "required": [

     "id",

     "name",

     "required-scenarios",

     "references"

Thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/dotnet/core/pull/9412#discussion_r1685551281, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/BA7FZAVJAXXK34VAKNGAPP3ZNLXNJAVCNFSM6AAAAABK5OTPCWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCOJQGA3TQNRZHE
.
You are receiving this because you commented.Message ID:
@.***>

I plan to merge this PR on Monday.

On FreeBSD we have libc as part of the base system, so we need a way to somehow hide dependencies based on OS. The same goes for libgcc as we have LLVMs libcompilerrt as a replacement.

@arrowd -- I don't think that will be a problem. The nominal packages list is intended to be a superset view of packages. Each distro then is able to subscribe to that list, with a partial or full set. When the markdown is generated, it uses the distro packages only. So, I think the scheme already works as you need. Feel free to contribute to FreeBSD packages and I think it will just work.

Sure, I'll try to find time for a follow-up after this PR lands.


Show deploystatus view immediately after deploys

Don't wait for deploy calls to finish before updating UI, improves responsiveness.
Signed-off-by: Michael McCracken<EMAIL_ADDRESS>

Fixes #170


About Page Layout & Styling

Work done by @asaki444 and @juanri0s
Describe your PR
Layout and styling work for the about page, includes Cloudinary images for the hero and cards. No interaction work.
Related to #72
Fixes #
Pages/Interfaces that will change
/about
Screenshots / video of changes
Drop some screenshots of the before and after of your work here. Better yet, take a screen recording using a tool like Loom
Mockups:
https://www.figma.com/file/Lo1ZcBOO9t4QRbX2I0PwBQ/RBB?node-id=0%3A1
Desktop View:

Mobile View (Chrome Dev Tools screenshot messes up the hero image for some reason)

Mobile View (Hero using snipping tool)

Steps to test

Click on About in navbar or footer.
OR Navigate to /about

Additional notes
PR does not implement content block component or hero component

still need to look into the layout issue with large screens for the WHO WE ARE text


chore: java options as multilines and jenkins-infra-team mail

Interesting bits from https://github.com/jenkins-infra/kubernetes-management/pull/2161 for infra.ci.jenkins.io

For later reader: the "inline -> multiline" is caused by updatecli (check https://github.com/jenkins-infra/kubernetes-management/pull/2167/files).


Metrics for subaccount-sync continued

Description
To visualize subaccount-sync activity and to create base for future alerting.
Changes proposed in this pull request:

Missing metric registered (time in the queue)

Related issue(s)

#691

/lgtm


Show duplicates IP in another colour for shared role

Issue type: feature request
With the new IP role added (thanks for that), would it be possible to change the duplication check when displaying an IP ? I would like to show the warning in another colour the duplicate addresses if the role is to be shared among several interface (VIP, anycast, VRRP...). I still think that it is usefull to show the other duplicate IP to see where it is allocated.
Here is an exemple of what I think. If you think this is OK, I will work on a pull request with cleaner code.
(code in ipadress.html)
        {% if duplicate_ips_table.rows %}
                        {% if ipaddress.get_role_display == 'VIP' %}
                                {% include 'panel_table.html' with table=duplicate_ips_table heading='Duplicate IP Addresses' panel_class='info' %}
                        {% else %}
                                {% include 'panel_table.html' with table=duplicate_ips_table heading='Duplicate IP Addresses' panel_class='danger' %}
                        {% endif %}
        {% endif %}

I think it makes sense to simply ignore duplicate IPs with the "anycast" role, but for the rest of these you still want to know when you have duplicate IPs. For instance, you should typically only have one VRRP IP in a prefix, which is shared by multiple devices. (Note that we cannot currently map a VIP explicitly to multiple interfaces, though we'll probably implement something in the future.)


Fix typos

Found via codespell -L ines

Codecov Report

Merging #66 (bf4b926) into master (4681846) will not change coverage.
Report is 1 commits behind head on master.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.
@@           Coverage Diff           @@
##           master      #66   +/-   ##
=======================================
  Coverage   92.89%   92.89%
=======================================
  Files           9        9
  Lines         704      704
=======================================
  Hits          654      654
  Misses         50       50

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Thanks!

:partying_face: :partying_face: :partying_face: :partying_face: :partying_face:


cmd/vet: detect Get/Post http.Response assignment to "_", which is a memory leak

I made a rookie mistake and introduced a memory leak into a codebase by failing to realize that you must close the http.Response body returned by http.Post() even if you don't need the response content.
I suspect I'm not only one who has made this mistake.
I have a diff, if the proposal is accepted.

While ignoring the response might be common for Post, it should be rare for Get. So if we want a general solution, simply detecting that response is ignored ("_" as your title suggest) is not enough.
(I am surprised that this hasn't been discussed before; certainly seems useful. I don't see it discussed in github - perhaps there's some discussion elsewhere. Tangentially related..)

There's also the more general problem of not using an io.Closer properly once it is constructed. That is, never calling Close() on it.
If we only check for the _, err := http.Post(...) pattern, it seems to me like the check wouldn't be very powerful. What if we first construct the http.Request and then call Do on it? What if we don't ignore the http.Response, but we don't close it in some cases? The Azure bug linked above has both of these properties.
On the other hand, if we implement the more generic check, I imagine it would be very tricky to avoid false positives. For example, some implementations of io.Closer may be no-ops, and fine to ignore.

@alandonovan

For example, some implementations of io.Closer may be no-ops, and fine to ignore.

There's even such a helper in the [https://golang.org/pkg/io/ioutil/#NopCloser](standard library), for converting from a simple io.Reader to a ReadCloser with a no-op Close() method.

We already have in vet a list of functions whose result is not to be ignored; it sounds like http.Post should be on that list.
The general analysis that would solve this class of problems is called type-state verification. It checks, for example, that on a file returned by Open, all calls to Read and Write occur before Close, and that a call to Close occurs on all control flow paths. (A looser version of the check would ensure that at least some path calls Close.)  The quality of such an analysis depends on how precisely it models data, control, and the call graph. Generally it takes a lot of analytical firepower (and CPU/RAM) to do a good job in the more sophisticated cases, but we can catch dumb errors with simpler heuristics. An example to follow might be the lostcancel check in vet, which ensures that a context's cancel function is "used" on all control flow paths after it is created. The check could perhaps be generalized to solve other problems of this form.

What if we add -closer as a vet flag which errors if a local io.Closer is ignored? We would whitelist ioutil.nopCloser from the stdlib. It's a start towards getting the check on by default.

We already have in vet a list of functions whose result is not to be ignored; it sounds like http.Post should be on that list.

Could you share where this is?


improve doc

This improves the full examples in the doc, by switching to a service-oriented design. This had bothered me because people will copy/paste example code and it needs to be architected in a reasonable way, even if the examples end up being a bit longer.
And other minor changes.

Codecov Report

Merging #224 into master will increase coverage by 0.24%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #224      +/-   ##
==========================================
+ Coverage   83.94%   84.19%   +0.24%
==========================================
  Files         106      106
  Lines        1221     1221
  Branches       24       24
==========================================
+ Hits         1025     1028       +3
+ Misses        196      193       -3

Impacted Files
Coverage Δ

...ore/src/main/scala/net/BufferedMessageSocket.scala
96.15% <0.00%> (+3.84%)
:arrow_up:

...ore/src/main/scala/net/AbstractMessageSocket.scala
83.33% <0.00%> (+33.33%)
:arrow_up:

Continue to review full report at Codecov.

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


Cryptographic signature invalid error

While testing, I keep getting cryptographic signature invalid error.
The test url is https://user-images.githubusercontent.com/76050122/119028040-4b5d1300-b9a7-11eb-8bf4-3d5b9c4272f5.png
I have tried updating the public keys but that did not change anything. Upon inspection I can see that the signer certificate update results in a 204 response.
204 No Content https://dgca-verifier-service.cfapps.eu10.hana.ondemand.com/signercertificateUpdate (126ms)
I have tested signer certificate url in POSTMAN and the response is 200.
ps. The ios version works normally
What am I missing?

Hello, it is seems to be a bug connected to the fact that the Test Result in the QR-Code has the value "DETECTED".  You should try with a QR Code with Test Result Value of "UNDECTED".

Thank you


[14.0] ISPN-14247 Drop snakeyaml dependency from everywhere

https://issues.redhat.com/browse/ISPN-14247

merged! thanks @tristantarrant !


Allow plugging in custom CA at the time of install via Add-on profile

Please describe the Improvement and/or Feature Request

Currently OSM creates a default secret via Tresor package initially if there is no secret with name osm-ca-bundle present in the cluster. The ask is to be able to allow plugging in custom CA at the time of install which will create the secret based on the given certificate. The reason for this is OSM currently does not auto-rotate the secret in a compliant manner. The use-case of our org is that we must auto-rotate the secret every 90 days and allowing plugging in custom CA allows us to maintain auto rotation of the secret.
Scope (please mark with X where applicable)

New Functionality          [x ]
Install                    [ x]
SMI Traffic Access Policy  [ ]
SMI Traffic Specs Policy   [ ]
SMI Traffic Split Policy   [ ]
Permissive Traffic Policy  [ ]
Ingress                    [ ]
Egress                     [ ]
Envoy Control Plane        [ ]
CLI Tool                   [ ]
Metrics                    [ ]
Certificate Management     [ x]
Sidecar Injection          [ ]
Logging                    [ ]
Debugging                  [ ]
Tests                      [ ]
CI System                  [ ]
Demo                       [ ]
Project Release            [ ]

Possible use cases

@shahriak The OSM AKS addon is not managed as a part of this open source project. Kindly follow up with the AKS team managing the OSM addon for enhancements required in the addon.


Mutually Exclusive Options: stack overflow

How to reproduce:
Minimal working example:
package test;

import picocli.CommandLine;
import picocli.CommandLine.ArgGroup;
import picocli.CommandLine.Command;
import picocli.CommandLine.Option;

public class ArgGroupsTest {

    public static void main(String[] args) {
        CommandLine cmd = new CommandLine(new TestCommand());
        cmd.parseArgs("-a=Foo");
        cmd.parseWithHandler(new CommandLine.RunAll(), args);
    }

    @Command(name = "ArgGroupsTest")
    static class TestCommand implements Runnable {

        @ArgGroup( exclusive = true)
        DataSource datasource;

        static class DataSource {
            @Option(names = "-a", required = true, defaultValue = "Strings.gxl")
            static String aString;
        }

        @Override
        public void run() {
            // nothing to do here
        }
    }
}

If I remove defaultValue = "Strings.gxl"from the annotation of option -a, the error goes away.
Stack trace:
Exception in thread "main" java.lang.StackOverflowError
	at picocli.CommandLine$Help$Ansi.apply(CommandLine.java:12026)
	at picocli.CommandLine$Help$ColorScheme.optionText(CommandLine.java:11737)
	at picocli.CommandLine$Model$ArgGroupSpec.concatOptionText(CommandLine.java:6630)
	at picocli.CommandLine$Model$ArgGroupSpec.synopsisText(CommandLine.java:6602)
	at picocli.CommandLine$Model$ArgGroupSpec.synopsis(CommandLine.java:6593)
	at picocli.CommandLine$ParseResult$MatchedGroup.addMultiple(CommandLine.java:8438)
	at picocli.CommandLine$ParseResult$MatchedGroup.<init>(CommandLine.java:8422)
        ...
       quite a few lines here

Thanks for raising this! This bug exposed a deeper bug that I'm still wresting with...

Fixed in master. Thanks again for raising this.
Hoping to release alpha-2 in a few days.

Was this released? I am still facing this bug

@mitamr Yes the fix for the above issue was included in picocli-4.0.0-alpha-2 and all following releases. I just tried the above example with picocli 4.0.4 and it works fine: no StackOverflowError.
If you are still seeing this with picocli 4.0.4 you found a new similar issue. Can you please raise a new ticket with an example of how to reproduce the issue?


Added support for complex types in [FromUri] in Swashbuckle version 4

I can't support Swagger 2.0 yet.  I needed this fix in Swashbuckle version 4, so backported the changes from #70.

Just released version 4.2.0 with these changes. Please try it out and provide feedback if you get a chance.
FYI, bar any serious bugs, this will be the last release of the 4.x line. All future development and features will be targeted to the next major version 5.x, which makes the transition from Swagger 1.2 to Swagger 2.0.


feat(dapp-console): app data model

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#195  👈
#194
#183
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tremarkley and the rest of your teammates on  Graphite


refactor: use slices.Contains instead of for loop to check if the provided db is in AllowedDBDrivers

By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.
Problem/Feature
Description of Changes:

use slices.Contains instead of for loop to check if the provided db is in AllowedDBDrivers

Checklist

[x] I have self-reviewed the changes being requested
[x] I have updated the documentation (check issue ticket #218)

I am not sure what the purpose of the PR is. You changed only one file in the flags dir, and the tests are failing.
I will close it as incomplete.


Add build job for devtools on quartz

In progress, testing against GitLab CI
Resolves #145

LGTM

LGTM

Devtools build successful: https://lc.llnl.gov/gitlab/smith/serac/pipelines/16740


Grafana Dashboard not available on public IP port 3000

Bug Report
What happened:
Following the instruction here on Ceph-Ansible Installation. I successfully deployed a three-node cluster of Ceph. The output of the ansible-playbook command was with failed=0. However the dashboard is not available externally; meaning that the incoming requests on port 3000 are not forwarded to the docker container. Although the service is fully functional internally. But for example Prometheus is available through port 9090 externally.
What you expected to happen:
To have the grafana dashboard available externally at port 3000.
How to reproduce it (minimal and precise):

Install nautilus from stable-4.0 with Dashboard enabled.
Share your group_vars files, inventory
group_vars:
ceph_origin: repository
ceph_repository: community
ceph_stable_release: nautilus
public_network: "<IP_ADDRESS>/24"
cluster_network: "<IP_ADDRESS>/24"
monitor_interface: ens224

inventory:
[mons]
cephansible1
cephansible2
cephansible3

[osds]
cephansible1
cephansible2
cephansible3

[grafana-server]
cephansible1

Environment:

OS (e.g. from /etc/os-release): CentOS 7 1810
Kernel (e.g. uname -a): 3.10.0-957.27.2.el7.x86_64
Docker version if applicable (e.g. docker version):  Docker version 1.13.1, build 7f2769b/1.13.1
Ansible version (e.g. ansible-playbook --version):  ansible-playbook 2.8.4
ceph-ansible version (e.g. git head or tag or stable branch): stable-4.0
Ceph version (e.g. ceph -v): ceph version 14.2.2 (4f8fa0a0024755aae7d95567c63f11d6862d55be) nautilus (stable)

Could you share your ansible logs ?

Sure!
Here you go:
ansible.log

However the dashboard is not available externally; meaning that the incoming requests on port 3000 are not forwarded to the docker container

What do you mean exactly by externally ? because we don't use NAT for the container so there's no forward, they're using the host network.
Do you have something listening on port 3000 on cephansible1 node ?
If not, could you check the grafana container logs ?
# docker logs grafana-server
and/or
# journalctl -u grafana-server

I mean there is no service listening on port 3000 on public_network IP range, though when I get the list of listening ports, there is one listening on 3000 but with a specific network to containers (the IP is <IP_ADDRESS>:3000). Here is the output of ss -lntu command(ListeningPorts.txt)
Here are the logs for grafana-server(grafana-server-logs.txt)
I could manually stop the container using docker cli and start it again with the port forwarding (like docker run -d -p 3000:3000 grafana/grafana) but this does not seem to be a descent solution!
Also, note that after a reboot of the cephansible1 machine, the grafana container didn't start automatically!

mean there is no service listening on port 3000 on public_network IP range, though when I get the list of listening ports, there is one listening on 3000 but with a specific network to containers (the IP is <IP_ADDRESS>:3000). Here is the output of ss -lntu command(ListeningPorts.txt)
Here are the logs for grafana-server(grafana-server-logs.txt)

Weird because we explicitly configure grafana on the public_network [1]. Could you run the playbook with more verbosity (-vv) because in the current logs I couldn't see the fact values.

I could manually stop the container using docker cli and start it again with the port forwarding (like docker run -d -p 3000:3000 grafana/grafana) but this does not seem to be a descent solution!

Again you don't need port forwarding because we're using the host network configuration [2]

Also, note that after a reboot of the cephansible1 machine, the grafana container didn't start automatically!

That's supposed to be done by [3]
[1] https://github.com/ceph/ceph-ansible/blob/stable-4.0/roles/ceph-facts/tasks/facts.yml#L316
[2] https://github.com/ceph/ceph-ansible/blob/stable-4.0/roles/ceph-grafana/templates/grafana-server.service.j2#L18
[3] https://github.com/ceph/ceph-ansible/blob/stable-4.0/roles/ceph-grafana/tasks/setup_container.yml#L25

Thank you for your quick reply!

Again you don't need port forwarding because we're using the host network configuration [2]

I got you the first time. I meant that as a workaround; certainly not a solution

That's supposed to be done by [3]

That's true, but it didn't work
Here is the verbose log(ansible.log)

2019-09-04 19:02:21,098 p=147571 u=root |  TASK [ceph-facts : set grafana_server_addr fact - ipv4] *********************************************************************************************************************************************************
2019-09-04 19:02:21,099 p=147571 u=root |  task path: /usr/share/ceph-ansible/roles/ceph-facts/tasks/facts.yml:314
2019-09-04 19:02:21,099 p=147571 u=root |  Wednesday 04 September 2019  19:02:21 +0430 (0:00:00.203)       0:02:58.674 ***
2019-09-04 19:02:21,242 p=147571 u=root |  ok: [cephansible1] => changed=false
  ansible_facts:
    grafana_server_addr: <IP_ADDRESS>
(...)
2019-09-04 19:03:42,851 p=147571 u=root |  TASK [ceph-facts : set grafana_server_addr fact - ipv4] *********************************************************************************************************************************************************
2019-09-04 19:03:42,851 p=147571 u=root |  task path: /usr/share/ceph-ansible/roles/ceph-facts/tasks/facts.yml:314
2019-09-04 19:03:42,852 p=147571 u=root |  Wednesday 04 September 2019  19:03:42 +0430 (0:00:00.344)       0:04:20.427 ***
2019-09-04 19:03:43,096 p=147571 u=root |  ok: [cephansible1] => changed=false
  ansible_facts:
    grafana_server_addr: <IP_ADDRESS>

That's very strange. The grafana ip address fact changed during the playbook execution.
<IP_ADDRESS> is part of the docker interal network ?
Do you have anything configured related to grafana ?

No, this has been executed on a clean install of CentOS.

Ok so according to the logs, grafana_server_addr: <IP_ADDRESS> seems to be set during the infrastructure-playbooks/dashboard.yml playbook execution.
My theory is that somehow (I'm not able to reproduce on my side for now) public_network  value is lost when this playbook is executed so it fallbacks to the default value <IP_ADDRESS>/0.
Because the docker network appears before the public_network in the ansible facts then the ipaddr filter get all ip addresses and returns the first one.
If you run :
$ ansible -i hosts all -b -m setup -a 'filter=ansible_all_ipv4_addresses'
xxxxx | SUCCESS => {
    "ansible_facts": {
        "ansible_all_ipv4_addresses": [
            "<IP_ADDRESS>",
            "<IP_ADDRESS>"
        ]
    },
    "changed": false
}

You should have this kind of output.
But even with this I don't have the same behavious.
Did you define public_network in group_vars/all.yml ?
If yes could you try to add this task to roles/ceph-facts/tasks/facts.yml just before the set grafana_server_addr fact - ipv4 task (~ L314) :
- debug:
    msg: '{{ public_network }}'

So after a lot of investigation, while reading the Ceph Cookbook 2nd edition - Packt Publication, I came across a section regarding grafana-server:

If you are running ansible-playbook on a host mentioned in the inventory file, you will need to append ansible_connection=local to each line in the inventory file that mentions that host.

I was actually installing Ceph from cephansible1 node!
So I started installing Ceph from the beginning (on a fresh install - rerunning on the previous installation wouldn't work) with a change to the inventory file:
[mons]
cephansible1 ansible_connection=local
cephansible2
cephansible3

[osds]
cephansible1 ansible_connection=local
cephansible2
cephansible3

[grafana-server]
cephansible1 ansible_connection=local

And fortunately that fixed it.
@dsavineau I'm not sure if this needs to be documented so I won't close it.

Ok so we can close it


TS-4925: Manager pollMgmtProcessServer stuck with EBADF.

If the select in pollMgmtProcessServer fails with an actual error
(EBADF, for example), it just returned back into the select loop
and was unable to recover. This might happen if the server file
descriptor is -1, or otherwise stale.
The fix is to not put -1 into the select set, and to break the loop
if select returns an error.

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/923/ for details.

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/817/ for details.

@gtenev  Can you review this please?

I'd imagine this is a backport candidate for at least 7.0.0, maybe 6.2.x ?

@zwoop It is a race that happens when traffic_server keeps failing to start. 7.0 would be good but not sure we need to bother with 6.2


(venv) (base) razafimandimby@razafimandimby-Lenovo-G50-30:~$ python3 -c 'import tensorflow as tf; print(tf.version)' Instruction non permise (core dumped)

Please make sure that this is a build/installation issue. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:build_template
System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary):
TensorFlow version:
Python version:
Installed using virtualenv? pip? conda?:
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:

Describe the problem
Provide the exact sequence of commands / steps that you executed before running into the problem
Any other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.

can you help me please ?

Are you on 64bit or 32bit machine? Please fill you template as it is empty.

I'm on 64bit machine. What kind of template should I fill in ?  I'am a beginner on this platform and on IT in general. Thanks for your understanding.

This one https://github.com/tensorflow/tensorflow/issues/43670#issue-711899548. You haven't filled any info.

System information
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Ubuntu 20.04.1 TLS
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: Laptop Lenovo G50-30
TensorFlow installed from (source or binary): TensorFlow installed from source
TensorFlow version: 2.3.1
Python version: 3.8.2
Installed using virtualenv? pip?9 conda?: virtualenv
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory: Graphic Pilote Nvidia for Windows 8.1 (64 bits) - Lenovo G50-30

I'm sorry, I don't know for the rest.

Can you run in python:
import sys
print(sys.maxsize > 2**32)

(venv) (base) razafimandimby@razafimandimby-Lenovo-G50-30:~$ import sys
La commande « import » n'a pas été trouvée, mais peut être installée avec :
sudo apt install graphicsmagick-imagemagick-compat  # version 1.4+really1.3.35-1, or
sudo apt install imagemagick-6.q16                  # version 8:<IP_ADDRESS>+dfsg-2.1ubuntu11.1
sudo apt install imagemagick-6.q16hdri              # version 8:<IP_ADDRESS>+dfsg-2.1ubuntu11.1

this is the error message that i have

It Is python code

(venv) (base) razafimandimby@razafimandimby-Lenovo-G50-30:~$ sudo apt install imagemagick-6.q16hdri
(venv) (base) razafimandimby@razafimandimby-Lenovo-G50-30:~$ import sys
import-im6.q16hdri: attempt to perform an operation not allowed by the security policy `PS' @ error/constitute.c/IsCoderAuthorized/408.
This is the last command that i do and the error message

can you take my laptop with TeamViewer please ?

It is not a bug it is just a support request.
I think that you can close this ticket and reformulate as a support question at https://stackoverflow.com/questions/tagged/tensorflow


Solver unit test

This PR has some solver unit tests.  Are they good form for the solver unit test?  If so I can add some more tests.
The unit tests are in : pkg/solver/solver_test.go
Closes #66

@perdasilva Thanks for review.  I updated the tests and rebased for the current main branch.

/approve


missing guidance on null guards

There has been some discussion and misunderstanding on whether or not application and/or library developers now can remove any null guards (e.g. if(input != null){...}, ArgumentNullException) because of this feature. See for example here and here. The documentation needs clear guidance if or if not (and if so, when) it is now safe to remove null guards.

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

ID: bea1e2ab-5517-b17c-4a65-7c7bae09261a
Version Independent ID: 2a326631-709b-4461-6c15-a75a5087ef1d
Content: Nullable reference types in C# - C# 8.0 language proposals
Content Source: proposals/csharp-8.0/nullable-reference-types.md
Product: dotnet-csharp
Technology: csharp-spec
GitHub Login: @dotnet-bot
Microsoft Alias: wiwagn

Thanks for writing this @bitbonk
The reference guidance for corefx is a good start. However, as we add more annotations to different APIs in corefx, we're continuing to learn the best way forward. We're not comfortable saying "we know the answers" yet.
I've not assigned this a milestone, because we're not confident enough of the current guidance to recommend it universally. However, I've adding a high priority label because we agree it's important.

@IEvangelist  Can you clarify why this was closed? Where can I see the updated docs for this?

@bitbonk The PR was merged today. It will be published overnight, on our regular publishing cycle.
If you can't wait, the source is here on GitHub.

Sorry, @bitbonk -- I should have commented with an explanation. I'll be sure to make that a part of my standard workflow from now on. Thanks for keeping me honest 👍


Create Sprite for Gasoline (Flamethrower Ammunition)

Please see CONTRIBUTING.md first.
Happy Hacking! :smiley:

Can I do this one? :)

Sure! :smiley:


Change the way to retrieve services during tests

Thanks to https://twitter.com/welcoMattic/status/1463810474726895617

Coverage remained the same at 96.383% when pulling bc9f50f46ef1d185f2cc663e955c125407bab798 on fix/test-container-services into 04330e2738737c55406547ea666b9cac4901ee5a on master.


Improve yeoman interactive UI to list sub-generators

Feature request
While yo --generators shows all available generators including sub-generators, yeoman interactive UI only work with main generators, completely ignoring sub-generators.
Interactive UI purpose is to simplify working with yeoman and installed generators. But many generators have sub-generators, which are not accessible from interactive UI.
I could think of two possible ways to include sub-generators:

Sub-generators could be listed together with main generators.
Alternatively, interactive UI could show a second prompt to let users chose a particular sub-generator to run in case there is more then one option available.

Similar proposal was made in #397, but the issue was closed by OP for no apparent reason,

I would go with 2. Showing them in the main list would make the list very long and noisy.


Check that sorts are used with the correct number of generics

Flux happily accepts the following
use flux_rs::*;

#[refined_by(n: int)]
struct S {
    #[field(i32[n])]
    f: i32,
}

defs! {
    fn foo(s: S<int>) -> int {
        s.n
    }
}

This is wrong because the sort S (that we automatically generate from the refined_by annotation) doesn't have any generics.
We should check sorts are used with the correct number of generics when converting from fhir to rty here

@nilehmann, Is this still an issue? I can give it a try.

@vrindisbacher yes, it still is


Add reusable GitHub Actions pipeline for lint/build/test

@alexweininger if you want to add some stuff for the test case reporting please do.
Related to #1457

@alexweininger if you want to add some stuff for the test case reporting please do.

It requires npm package updates and some other changes so I'll do that in a separate PR.

@alexweininger if you want to add some stuff for the test case reporting please do.

It requires npm package updates and some other changes so I'll do that in a separate PR.

Sounds good. Plus the NPM stuff would have to be in the respective package.json files.


fix fix catalog parameter when checking privilege of show_create_table stmt

the ctl parameter of show_create_table stmt is not set in checkTblPriv, this is not correct for multicatalog
Proposed changes
Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[x] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run clickbench

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 33.65 seconds
stream load tsv:          451 seconds loaded<PHONE_NUMBER>9 Bytes, about 158 MB/s
stream load json:         36 seconds loaded<PHONE_NUMBER> Bytes, about 62 MB/s
stream load orc:          73 seconds loaded<PHONE_NUMBER> Bytes, about 14 MB/s
stream load parquet:          31 seconds loaded 861443392 Bytes, about 26 MB/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230306080751_clickbench_pr_109133.html

run clickbench

run clickbench

run compile


Optimize Storage Logic

Is your feature request related to a problem? Please describe.
Currently, CareConnect saves the address book to storage after every command, even for commands that do not modify data, such as Find. These file writes are unnecessary and lead to performance overhead.
Describe the solution you'd like

Add a boolean attribute to command result stating whether the data was modified.
Modify LogicManager::execute to only saveAddressBook if data was modified

not important enough to be done in v1.6


evaluation wrapper - sort segments by time

It's not obvious to me whether this is a bug for JAMS or mir_eval, but when evaluating segment data, I got some nasty exceptions whenever the interval data was not ordered.
This is easily fixable by calling annotation.data.sort_values('time', inplace=True) before generating interval/values and calling mir_eval.
[tagging @craffel for insight]

What were the exceptions?

Migrating this to craffel/mir_eval#202 and closing out.  Pretty sure it's not a jams issue.


UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0: invalid start byte

python -m demo --img_path ./input_images/000013.jpg --out_folder ./RingNet_output --save_obj_file=True --save_flame_parameters=True --neutralize_expression=True
when I run this command its not giving the output of neutral_expression , I have copied the flame models to the flame_model folder. It has given at line 80 in serialization.py "dd = pickle.load(open(fname_or_dict))"
Pls help me in solving this issue and I am using pyton 3.6 as mesh libraries are working only in python 3.5+

Hi @bradison18! I am facing the same error. How did you manage to solve this?


Replace rinkeby at goerli

Rinkeby was not supported now... https://blog.ethereum.org/2022/06/21/testnet-deprecation

https://github.com/swaponline/MultiCurrencyWallet/issues/5102


Typo in def. of CHEBI:3405 - carboxin

"...A fungicide for control of bunts and smuts normally that is normally used as a seed treatment."
Please resolve duplication of "normally", thanks.

Now fixed. Thanks


Rustfmt

@sornas are we doing this or no?

Yeah I'm looking over it now.

Oh wow the merge conflicts suckk, I can do a new pass.

Merged (sort-of) in #256


iOS 11.3 - Changes

In iOS 11.3 they made some changes to HomeKit as stated in the update notes:

Adds support for software authentication as a new way for developers to create and enable HomeKit-compatible accessories

Does this affect our current projects?
I would say no because it’s “hardware-related”, but has anyone tried it out yet?
Thanks!

Hello I just wanted to know if this is my problem and FixMa or with iOS 11.3 everything does not work .

But FlixMa you have all ok ?

I just updated to iOS 11.3 on iPhone 7 and all accessories are still functioning correctly. ATV4 has also been updated to the latest tvOS. Remote access fully functional also. Must be something your end causing the problem.

Ok , thanks

I didn't update yet because of the fear, everything wouldn't anymore.
But if Bluntiless did update and everything seems to be fine. Why not upgrading ;-)


[backport/1.26] build: include validation listener manager in the envoy exe build (#26882)

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

cc @phlax

thanks for raising @soulxu - i already picked this commit to #26851 - and i think the branch needs other commits there to make CI work - so ill close this

thanks for raising @soulxu - i already picked this commit to #26851 - and i think the branch needs other commits there to make CI work - so ill close this

thanks! sorry I missed the existing commit


cmd/compile: add special binary export encoding for iotas?

Poking around the export data for the ssa package, I noticed a lot of runs of constants generated by iota--each with an int value + 1 and a line +1 from its predecessory. It is a somewhat common structure that admits of a compact encoding, something like this:
// export
func (p *exporter) iotas(e []*Node) {
    p.tag(iotaTag)
    p.int(len(e))
    n := e[0]
    p.pos(n)
    p.typ(unidealType(n.Type, n.Val()))
    p.value(n.Val())
    for _, n := range e {
        p.qualifiedName(n.Sym)
    }
}

// import
    // ...
    case iotaTag:
        niota := p.int()
        p.pos() // TODO: hook this up and increase by one line at each new node
        typ := p.typ()
        val := p.value(typ)
        for i := 0; i < niota; i++ {
            sym := p.qualifiedName()
            importconst(p.imp, sym, idealType(typ), nodintconst(val.Interface().(int64)+int64(i)))
        }
        return niota
    // ...

A possibly even more compact encoding is to detect common prefixes in names across the entire run, which is fairly common. Even without that, this has a pretty significant impact on the ssa package:
name        old export-bytes  new export-bytes  delta
Template          19.0k ± 0%        19.0k ± 0%     ~     (all equal)
Unicode           4.45k ± 0%        4.43k ± 0%   -0.31%  (p=0.002 n=6+6)
GoTypes           29.7k ± 0%        29.6k ± 0%   -0.53%  (p=0.002 n=6+6)
Compiler          75.6k ± 0%        74.3k ± 0%   -1.62%  (p=0.002 n=6+6)
SSA               76.2k ± 0%        65.7k ± 0%  -13.79%  (p=0.002 n=6+6)
Flate             4.98k ± 0%        4.98k ± 0%   +0.02%  (p=0.002 n=6+6)
GoParser          8.81k ± 0%        8.81k ± 0%   +0.01%  (p=0.002 n=6+6)
Reflect           6.25k ± 0%        6.10k ± 0%   -2.37%  (p=0.002 n=6+6)
Tar               9.49k ± 0%        9.46k ± 0%   -0.31%  (p=0.002 n=6+6)
XML               16.0k ± 0%        16.0k ± 0%     ~     (all equal)
[Geo mean]        15.1k             14.8k        -1.98%

It's not quite obvious that it's worth doing in general--SSA might be somewhat special.
For discussion, if we make another round of export format changes.

Oops, forgot to cc @griesemer @mdempsky

There's already a TODO in bexport.go to use a more condensed for for "long runs of constants". There are other packages that come to mind (Unicode, syscall) which perhaps don't use iota but still could benefit from more compact encoding. I think this is worthwhile doing, perhaps together with the string encoding change.

I also have a local type export change I'm playing with now that saves another percent and change. I'll see about pulling together a handful of CLs.
I don't really know all the things that need to change when the export format changes. Is it just the compiler and go/type's gcimporter?
Also, for some of these changes, it might be rather invasive to try to gracefully support reading all old versions, the way we do now. :(

Supporting old versions: Good point. If we do change the export format version, people will find out, but it's going to be a major nuisance for a lot of people (including us) working at tip if they all have to recompile existing libraries. We probably should try to be backward compatible to make this a transparent change.
When changing the export format, we need to change:

compiler: bexport.go, bimport.go
go/importer: go/internal/gcimporter/bimport.go
x/tools: go/gcimporter15/bimport.go

If we're backward-compatible, it's ok to generate the old format in tools we don't know about.

PS: being backward compatible for the position encoding change may negate the effect. hmm... (maybe that one needs to handles separately).

Basically none of the changes I've been considering are really backwards compatible. They'd all involve a version bump. But I thought you put in pretty good version skew detection and error messages.
Maybe I'll put together some compiler-only CLs for you to look at, and then we can decide together whether to proceed with them.

A compiler that can read the new format will be able to read the old format, and discern based on export format version. But yes, if the new format is present, one needs a compiler that understands the new format (but we don't need to upgrade all existing installed libraries).

Punting to 1.10 because of uncertainty about interaction with #20070.


Config: Don't clean hardware w/o config change

This is a proposal for solving issue #603.

Correct, in my case, files were updated (new creation date) but their content didn't change. That's fair.


Localization for .de

Placeholder for now -- need list of strings to translate
cc @zombie

I have put in a request for this.

@dmarti I responded to your request in the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1562714. I am not clear what needs to be localized and what this whole request is about. I assume the deadline no longer applies.

@zombie Will we need any other strings?

Also the extension name (if we want to localize that), description, and the ON/OFF switch state labels.  I extracted all of english UI strings for localization into a messages.json, which is what is actually used to localize extensions:
https://github.com/zombie/Global-Consent-Manager/blob/master/_locales/en/messages.json

Translation on Pontoon: https://pontoon.mozilla.org/de/global-consent-manager/


ruff server hangs when performing "code actions" in Helix

Might be related to Issue #416 in ruff-lsp, particularly @ssmsossah's comment here that the same thing is happening in NeoVim.
Running ruff server in Helix. Health checks with hx --health python all pass.
Helix 24.7
ruff 0.6.0
protocol error: InternalError: failed to deserialize diagnostic data: missing field 'range'
[[language]]
name = "python"
formatter = { command = "ruff", args = ["format", "-"]}
language-servers = ["ruff", "pyright", "pylsp"]

[language-server.pyright.config.python.analysis]
typeCheckingMode = "basic"

[language-server.ruff]
command = "ruff"
args = ["server"]

Welp, looks like I just rubber-ducked my way out of this one.  dunno how that misconfig slipped in but changing args = ["server"] to config = { settings = { args = ["server"] } } as suggested in the helix docs fixed the issue... closing.

I'm a bit confused here. What was the exact change? The args = ["server"] should be correct. Can you provide the docs reference for this?

@dhruvmanila  it's here

That's weird because their documentation mentions the use of args:

args | A list of arguments to pass to the language server binary

while, the config key is actually the initialization options which is different.
I'll need to try this out.

I'm getting code actions:

Using the following config:
[[language]]
name = "python"
language-servers = ["ruff", "pyright"]

[language-server.pyright]
command = "pyright-langserver"
args = ["--stdio"]

[language-server.ruff]
command = "ruff"
args = ["server"]

that is weird.  if you think it's worth further reproducing the issue on my end, just let me know @dhruvmanila.  Maybe there are logs I can pull? The related issues make me skeptical it's a Helix-specific problem

Is the config that you provided in the PR description complete? If not, could you provide the remaining parts? I'm curious whether you're using python-lsp-ruff (plugin to pylsp).
It might also be worth discussing this with the Helix team. Is it args or config? Because, we're using args in our setup guide :)

Yes, that was the complete config for the python language.  I tried it with various combinations of pylsp, pyright, and pylyzer.  definitely was not including python-lsp-ruff even though i have used it in the past, I was assuming hopefully correctly that ruff server was a full replacement.
I just confirmed the error is persisting when i revert the change, right now i'm just running ruff and pylyzer

we're using args in our setup guide

ah, so that's how i ended up there!


serde-sarif doesn't deserialize additional properties

Per section 3.8 of the SARIF spec, a properties field can contain arbitrary extra data, i.e. fields with any name.  This is highlighted in the JSON schema that the package is built from here. However, that fact seems to have not made it to the code and these extra properties are not currently deserialized by serde-sarif. It would be great if these could be deserialized, e.g. into a field like:
use serde_json::Value;
use std::collections::BTreeMap;
...
struct PropertyBag {
    ...
    #[serde(flatten)]
    additional_properties: BTreeMap<String, Value>,
}

@edoardopirovano thanks for reporting, this should be available in the latest published version of serde-sarif (0.3.5).
see example: https://github.com/psastras/sarif-rs/blob/main/serde-sarif/src/sarif.rs#L295
let me know if there is any issue, thanks!

Amazing, thanks for the quick turnaround on this!


net/http/cookiejar: New does not need an error as return argument

https://github.com/golang/go/blob/92ecd7893308ad222bfdd33b10be1cce769a3cdf/src/net/http/cookiejar/jar.go#L77
Should not return an error, since it will always yield nil it is useless.

Too late to fix now, it would break Go 1 compatibility to modify the return values of that function.
At some point, it probably did return an error, but since the signature can't be changed, the error return is always nil now.

I think the API was designed that way to allow for a future different/more complex implementation. Here a golang-dev discussion: https://groups.google.com/forum/#!topic/golang-dev/ygDB3nbir00/discussion
cc @nigeltao who designed the api

Ok makes sense, but from a design point, the new method is not part of the interface. More complex storage implementations could still have their own New func with custom signature.
But well too late is too late, did not think about that.


fix(pdf) Add missing formatted variables, add decorators

Signed-off-by: Jerome Simeon<EMAIL_ADDRESS>Changes

Fixes bug in template to pdf transform for formatted variables
Adds API call to get base64 encoded version of pdf document
Adds some internal support to pass Concerto decorators to the pdf generation
Upgrades to Concerto 1.0.2 -- includes fixes to security vulnerabilities
Switches off stdout in the CLI when using --output option

Coverage decreased (-0.2%) to 87.6% when pulling f5bf63cac5df0b5b47a592e63fb02f370268b061 on jeromesimeon:js-fix-pdf-template into 3bfa14d90eb822950c28643eea407cab560c71ee on accordproject:master.


Consider humanizing resource state on dashboard

As mentioned in https://github.com/dotnet/aspire/pull/1517#pullrequestreview-1801412256, we may want to consider humanizing resource states in the resource grid.

@davidfowl @kvenkatrajan do you think this is a worthwhile change?

Yes I think we should do this.


Account for character tokens in replaces

Do not case the u or x in the tokens \u00c7 and \x57 etc. Also don't case standard references like \n.  Regex format replace is actually normal replace that mimics format behavior, so it must respect char tokens like normal replace.

Probably need to also handle narrow split notation of wide characters...

Surrogates are not matched as a single regex in either engine.  On a narrow Python 2 system with the Regex engine they are matched only because Python 2 converts them over to full width notation, but on a wide system, they are not matched. So we don't need to explicitly check for those.
Need to make sure inserted groups strings are already converted over to Unicode on backrefs replace, or if we need to look for Unicode notation.  I suspect they would already be converted valid strings meaning we can upper case or lower case directly, but a test will clarify this.

Also a even though they pass through Regex and get coverted as wide on narrow Python2, Python2 itself can't lower and upper case those characters, so they can be ignored.

Duh, groups come from the literal string we are replacing in, there is nothing that needs to be done.  We should get the actual characters not patterns.  For the next release, we are going to keep replace pattern Unicode and bytes resolution to regex as only Regex natively does resolution for these in a replace pattern anyways.  So will do this just to keep parity with Regex for now.  Maybe in the future this will get folded into Re.


spark executor head dump not completed when jvm oom

I specified executor jvm options
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp
when executor java.lang.OutOfMemoryError happened, a java_pid22.hprof file generate.
i got "Dumping heap to /tmp/java_pid22.hprof ..." message in executor console before container exit.
but the hprof file size only 200M, this is much more smaller than my heap memory.
the hprof file is not completed and MAT gui tool cannot read it.
why?

@erictanghu Did you ever resolve this? Is yes then can you please provide some pointers.