Add xedocs version to context config, only if xedocs is called

Part of this PR, following this old conversation.
What does the code in this PR do / what does it improve?
Very minor addition: It adds the global version used in the context to the straxen context_configs. This is just to help to know what global version they are on, because some analysis have frozen global versions (Warnings when a frozen global version is not the same as the specified version is given by the cutax PR 429 as well)
Note: Doing st.set_context_config() after the initialization still does not change the global version (and it is not encouraged to change it mid-analysis). This addition does nothing to the actual processing other than make this information available :)
Can you briefly describe how it works?
Only adds a new key 'xedocs_version' to the context_configs, and only if the analysis actually uses xedocs during initialization.
Can you give a minimal working example (or illustrate with a figure)?
On this branch of straxen,
st=cutax.xenonnt_offline()  #or any other context
st.context_config
Please include the following if applicable:

[ ] Update the docstring(s)
[ ] Update the documentation
[ ] Tests to check the (new) code is working as desired.
[ ] Does it solve one of the open issues on github?

Notes on testing

Until the automated tests pass, please mark the PR as a draft.
On the XENONnT fork we test with database access, on private forks there is no database access for security considerations.

All italic comments can be removed from this template.

I think the tests are failing because of the issue with requirements' versions?

coverage: 91.067% (-0.07%) from 91.133%
when pulling 6941a1d203ba00240f8e889d5903363acd89b418 on xedocs_version_in_config
into 0286b80b3d1aa36984725bab98d589c6fb2b10ff on master.

coverage: 91.134% (+0.001%) from 91.133%
when pulling 6941a1d203ba00240f8e889d5903363acd89b418 on xedocs_version_in_config
into 0286b80b3d1aa36984725bab98d589c6fb2b10ff on master.

coverage: 91.093% (-0.04%) from 91.133%
when pulling 6941a1d203ba00240f8e889d5903363acd89b418 on xedocs_version_in_config
into 0286b80b3d1aa36984725bab98d589c6fb2b10ff on master.

coverage: 91.134% (+0.001%) from 91.133%
when pulling 6941a1d203ba00240f8e889d5903363acd89b418 on xedocs_version_in_config
into 0286b80b3d1aa36984725bab98d589c6fb2b10ff on master.

Just to document before we merge this, because xedocs version is added to the context config and it basically does nothing other than just make that information available, this warning will appear everytime a context with xedocs version is initialized:
Unknown config option xedocs_version; will do nothing. Invalid context option xedocs_version; will do nothing.
This doesn't affect anything else in any way :)


Possibility to use java.nio.charset.Charset instance.

Currently every escape functions using only charset names. If we use predefined Charset instance. it will run more faster.
For example:
Currently we have this method:
UriEscape.escapeUriPathSegment(String text, String encoding)
This overloaded method needed:
UriEscape.escapeUriPathSegment(String text, Charset encoding)
ps: also DEFAULT_ENCODING constant must be Charset instance not String. Can I send pull request for this changes?

Oh, I see minimum java requirement is version 1.5. But String.getBytes(Charset) method introduced in 1.6. Can we increase minimum requirement?


Introduce the opposite of the non-null assertion

Search Terms
non-null assertion opposite
Suggestion
The opposite of the "non-null assertion", used to force the compiler to believe that something may be undefined.
The most obvious syntax would be a "?" postfix operator, similar to how the non-null assertion is a "!" postfix operator. This would be consistent with the use of "?" for optional function params and object properties (which adds "undefined" to the type).
Use Cases
Indexing into arrays and "dictionary" objects with indexes/keys that are expected to potentially not exist.
Arrays and dictionary objects (an object type with the string index defined) are typically defined as having items whose type does NOT include undefined, even though it is technically possible (and valid) to use a non-existent index/key and get an undefined value as a result. In most situations, this avoids unnecessary/tedious non-null assertions, because arrays are often iterated (indexes guaranteed to exist), and dictionary objects are often used only to lookup keys that are guaranteed to exist.
However, in situations where an "untrusted" index/key is used on an array/dictionary, there is no convenient way to alter the type of the expression to indicate that the programmer is aware that the result may be undefined:
Examples
declare const array: Date[];
declare const untrustedIndex: number;

// Type is Date, but it may actually be undefined at runtime.
const item = array[untrustedIndex];

// To get useful "correct" typing, I must explicitly cast, duplicating the type
// of the item and adding "| undefined"
const item2 = array[untrustedIndex] as Date | undefined;

// Using the new proposed "possibly undefined assertion"
// Type is Date | undefined
const item3 = array[untrustedIndex]?;

Checklist
My suggestion meets these guidelines:

[?] This wouldn't be a breaking change in existing TypeScript / JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. new expression-level syntax)

Useful for RegExp.match().
const r = /^(.+)?\~(.+)$/;
const match = r.exec("~dude");
if (match != undefined) {
    match[1]; //Should be undefined; actually shows up as string
    match[2]; //Should be string
}

For now, in my code, I always make sure I assume the indices of match are string|undefined

I like the idea, however, to me it is a workaround of the larger issue presented here.

This could easily conflict with (or make very difficult) implementing the Optional Chaining proposal if it ever reaches Stage 3.


Removing hidden clap commands

Fixing the clap config in #342

Testing
Before
git-xet --help
git-xet 0.13.3
git-xet command line

USAGE:
    git-xet [OPTIONS] <SUBCOMMAND>

OPTIONS:
    -c, --cas <CAS>
            Optionally override cas endpoint

    -h, --help
            Print help information

    -l, --log <LOG>
            Sets the output log file. Writes to stderr if not provided

    -v, --verbose
            Increases verbosity of output. Multiple -v's can be added to increase verbosity

    -V, --version
            Print version information

SUBCOMMANDS:
    cas
            Plumbing commands for cas
    clone
            Clones an existing git xet repo, making sure the local configuration
    config
            Manage the xet config
    dematerialize
            Dematerialize files and drop the list of file paths from the lazy config
    diff
            Computes a summary-diff for a provided file between two commits
    dir-summary
            Computes and returns a directory-level summary for all directories in the repo
    filter
            Run the filter process
    help
            Print this message or the help of the given subcommand(s)
    hooks
            Plumbing commands for the git integration hooks
    install
            Installs the git filter config
    lazy

    login
            Stores authentication information for Xethub
    materialize
            Materialize files and add the list of file paths to the lazy config
    merkledb
            Plumbing commands for merkledb integration
    mount
            Mounts a repository on a local path
    pointer
            Generates a pointer file to stdout given a filename as an input If a filename is not
            provided, the file is read from stdin
    push
            Manually push all staged cas information to a remote CAS
    repo-size
            Computes and returns the total repo size (for the current commit), cached in git notes
    s3config
            Configure access to the XetHub S3 service
    smudge
            Outputs a file to stdout given a pointer file or with passthrough option -p set a
            non-pointer file as input. If a filename is not provided, the pointer file is read from
            stdin
    summary
            Computes and returns a file-level summary for a given file in the repo. Stores the
            result in git notes
    uninstall
            Uninstall git config information
    visualization-dependencies
            Computes and returns the data dependencies of custom visualizations, cached in git notes

After
git-xet --help
git-xet 0.13.4
git-xet command line

USAGE:
    git-xet [OPTIONS] <SUBCOMMAND>

OPTIONS:
    -c, --cas <CAS>
            Optionally override cas endpoint

    -h, --help
            Print help information

    -l, --log <LOG>
            Sets the output log file. Writes to stderr if not provided

    -v, --verbose
            Increases verbosity of output. Multiple -v's can be added to increase verbosity

    -V, --version
            Print version information

SUBCOMMANDS:
    cas
            Plumbing commands for cas
    clone
            Clones an existing git xet repo into a new directory
    config
            Manage the xet config
    dematerialize
            Dematerialize files and drop the list of file paths from the lazy config
    help
            Print this message or the help of the given subcommand(s)
    install
            Installs the git filter config
    lazy
            Auxiliary commands to manage the lazy config
    login
            Stores authentication information for Xethub
    materialize
            Materialize files and add the list of file paths to the lazy config
    merkledb
            Plumbing commands for merkledb integration
    mount
            Mounts a repository on a local path
    repo
            Repo level actions such as migrating repos
    repo-size
            Computes and returns the total repo size (for the current commit), cached in git notes
    s3config
            Configure access to the XetHub S3 service
    uninstall
            Uninstall git config information


Performance Improvements

Issue for multiple small or big performance improvements

using TryGetValue in AppSettings so you look for the value once instead 3 times

https://github.com/Flamifly/EasePass/tree/performance

Oh I see what you mean, totally forgot about such functions, long time not visited those files 😂. Glad we have you ❤

Tomorrow i will implement the next performance improvement for GetAllDatabasePaths on the Database class

a little performance improvement

reduced allocation of ToLower and increased performance with that small change

I noticed that I used contains and not equals so I changed it and it was even faster

next Improvement
Linq is mostly easy to use but way slower than the stuff you can implement

accesing Properties take longer than accesing a local variable

so i added a local variable length for the for loop

StringBuilder could be initialize once and not twice

Need to check if it would be faster if there would just a Clear instead of a new instalization

accesing Properties take longer than accesing a local variable
so i added a local variable length for the for loop

Do you have some benchmark values for those, as I mentioned in #148, I am curious if it makes that much of a difference when using array.Lenght or list.Count over using a local variable?

I got some but the result is not aspected in my opinion

it's almost pretty similar performance in this one the List.Count is faster but I did 4 Benchmarks and the local was usually faster at them but not much. Overall it was max 1-2 ms faster in 1 000 000 000 Iterations
In .Net it seems that it's just a little bit faster but not pretty much.
In other languages it is possible to be 25% faster with locals because of that I am used to do it always this way

Well for me this would not be a reason to rewrite everything, but now since I already merged we have it like you did now.
It's not a big deal, but I was really curious about it, thanks for measuring ✌

Iterating over string is slightly slower than iterating over span

Btw I will change the logic for is Secure alot to improve the overall performance for generating:
Tested with:

Before:

After:

Still some room for improvemence here

Yeah the allocated is pretty high in comparison, good thing to change that

It wasn't the allocation at all. I had 1.89kb allocation with 6.8us less than the original implementation
The most Gain of Performance belongs to a change I would do on ContainsSequence

In the original Implementation the string was converted to lower case and even if you do that on a span it is slow.
Instead we can use StringComparison.OrdinalIgnoreCase which does a way faster job with probably the same result (Did not test the result yet)

Oh true, I also think converting to lower case is the worst way for comparison. Since there are way faster ways. Finn is no one who thinks about speed 😂

😂
Is there something else that I should focus on optimising?

Hmm, I can not think about something rn

Next Performance Improvements:
PasswordHelper:

Change the Evaluate Method (Use one For loop instead of 4 Anys)
Change the Split in ReadIsPwnedData to Slices (Treat string as Span)

Performance Improvement Generating Password:
(Length: 12)

(length: 20)

Found a better way to generate a Password

So now the Diffirences
Old Implementation:
GeneratePassword:

IsSecure:

GetMaxPoints:

New Implementation:
Generate:

GetAllowedIncludes:

IsSecure (similar to GetAllowedIncludes)

Performance:

I am not sure what exactly I changed at the old Logic that it performs that bad thought I did not touch it.
But that does not matter now
Differences:
What did I change and why?

I implemented a Method that gets all includes of the allowed Chars. In my case an Include is if the Category of a Password is available or not (old logic maxpoints). I did this change because the Characters should not change while generating a new Password so it would perform much worse (need to change the IsSecure Method because we know which steps can be skipped)

Tomorrow I will end this
(wanted to add some Benchmarks for each Step and the result was better than my current implementation😂)
I will check if I can optimize them before I end this
Last Benchmark after first step:

Just by changing the way the Password will be checked results is about 90% faster is very interesting in my opinion

Pretty good job. I would've never figured this out 😂. You got som very good looking differences in performance waiting to get this merged and tested👍.

Ok now:
(length: 20)

I changed alot now.
First change is that I added a For Loop instead of checking always if I have reached the Length. (Was slightly faster)
Because of the For Loop the IsSecure Method will not be called every time a change on the  StringBuilder has been made (reduced allocation (we do not call ToString always for the IsSecure Method) and reduced the amount of checks inside the Secure Method, if the char is a number etc.) (was about 1us faster)

I will add this later to my Performance Branch and will create a Merge Request

Should we really check if the Password contains Punctuation or should we check if the Password contains Special characters?
because if the Password contains "<>%$§" without ".:;," it will be seen as insecure should we change that?

Performance Improvement for the RequestHelper:
Changing the Regex to a Generated Regex

By using a Generated Regex the Compiler will optimise it because of that it is in the most cases faster

Performance Improvement for the DatabaseItem:
Change GetFileNameWithoutExtension to own implemented one -> is not worth to do that if you need to work with a String

If you do not need to work with a String and can work with a Span it would be worth it

Since that is not the case for the DatabaseItem I wont do that

Performance Improvement for the Database:
chang the comparison from ToLower to Equals in RemoveDatavase:

It's way way way faster to use Equals instead of ToLower == ToLower
It's also faster to perform it on the string instead on a Span (probably the cast from a string to a span took that much time)
58ns to 0.03ns is a good improve to me

RemoveDatabasePath can be twice as fast:

We do not use a List for iterating (to iterate over a List is slower than an Array because the List can have it's Pointers everywhere and an Array have it's fixed block)
We removed the List completly and just use a StringBuilder to build our Paths (The List needs to be allocated and the Items need to be copied from the Array to the List)


Use serde for all demos

A lot of tests will need to be fixed. I started doing that but realized it would take a bit of work, so I just commented them out and we'll fix them later. Sorry for the mess!
I also improved some of the prompts to make them clearer.
In the participant demo, I also changed the first part to be able to read either a SecretShare or a KeyPackage (rather than just SecretShare). The reason is that DKG produces KeyPackages directly.

Ah ok, good catch on the KeyPackage.


Doesn't work with virtual directories

Simply create a virtual directory for the WCF service and things would break.

Swagger UI is still on localhost/api-docs even though I set virt dir as localhost/virt-dir (hence I expect something like localhost/virt-dir/api-docs/swagger.json)
API routes in Swagger UI don't have the virt dir address included

This was more about how the route binding works :smiley:


Draft: hot-rebuilding of npm workspaces

Overview
Jest, Stencil, Jest projects, Typescript project references, & npm workspaces don't play well together to facilitate hot reloading across a monorepo.
However, we CAN implement our own "hot rebuilder" for npm workspaces. The rebuilder:

watches relevant files using nodemon to trigger updates on changes
determines exactly what needs to be build by traversing a dependency graph (e.g. if you are testing in components and you make a change to source-iotsitewise, you can just rebuild source-iotsitewise and exclude core).
rebuilds relevant dependencies using npm workspace commands and re-runs the specified test command (for a package, or for a particular file - args are passed through to whatever test runner the target package is using)

Legal
This project is available under the Apache 2.0 License.

Please recreate this pull request off the new head, a history rewrite was pushed. Closing.


fixing cifar data

current code produces a vector of X.min(), X.max() == (-1.989213, 1045.3115)  (below)
X[0]
array([[[637.6034  , 641.6514  , 665.93976 , ..., 552.59424 ,
         508.06564 , 467.58508 ],
        [613.31506 , 609.267   , 641.6514  , ..., 548.5462  ,
         504.01758 , 479.72925 ],
        [609.267   , 609.267   , 637.6034  , ..., 560.69037 ,
         524.2579  , 483.7773  ],
        ...,

should produce a vector of X.min(), X.max() == (-1.9892129679394217, 2.126788393620005)
X[0]
array([[[ 0.51899327,  0.53486799,  0.63011633, ...,  0.18562409,
          0.01100213, -0.1477451 ],
        [ 0.42374493,  0.40787021,  0.53486799, ...,  0.16974936,
         -0.00487259, -0.10012093],
        [ 0.40787021,  0.40787021,  0.51899327, ...,  0.21737353,
          0.07450103, -0.0842462 ],
        ...

All the CIFAR code works. I really doubt this is the right change.

The current code is using the zero-based mean/std in the normalization step. The fact that it works is actually kind of cool, but every other data loader produces 0(ish)-centered outputs - I came across this artifact while trying to reproduce something from another library and wondered why the output was so different.
Here's an example using this official pytorch tutorial with the values fetch_cifar provides
https://pytorch.org/tutorials/beginner/blitz/cifar10_tutorial.html
import torch
import torchvision
import torchvision.transforms as transforms

transform = transforms.Compose(
    [transforms.ToTensor(),
     # using the mean/std from fetch_cifar()
     transforms.Normalize((0.4913997551666284, 0.48215855929893703, 0.4465309133731618), (0.24703225141799082, 0.24348516474564, 0.26158783926049628))])

batch_size = 4

testset = torchvision.datasets.CIFAR10(root='./data', train=False,
                                       download=True, transform=transform)
testloader = torch.utils.data.DataLoader(testset, batch_size=batch_size,
                                         shuffle=False, num_workers=2)

dataiter = iter(testloader)
images, labels = next(dataiter)
print(images.min(), images.max())

images.min(), images.max() == (tensor(-1.9892), tensor(2.0946))

@geohot this looks like a bug that went un-noticed, I tested this on master and acc. goes from 90.20 to 90.32 with same hparams. looks like it slows down learning by a small amount

for 94% bounty this might be an important change


Fix attribution of date.rs

In commit f7270411efdd0011359deac82a2e224629e7f671, we copied our date
implementation from the httpdate project [1] (#6, #19).  However,
this was done without proper attribution and preservation of copyright
notices.  Let's fix this.
[1] https://github.com/pyfisch/httpdate

@traviscross Hi, thanks for opening this! Attribution in our projects occur in the LICENSE files; would you mind updating LICENSE-APACHE and LICENSE-MIT with the copyright notices? The comment at the top of the date.rs file would then not be needed. Thanks heaps!

Sure; updated.


Optional header XML

I needed the XML without header, I hope it helps someone.
👍

Thanks. Please provide comment for the new buildXML method argument for future reference.

Great! :)
Thanks for this Class


Integrate IntentAnalyzer

Pull Request Summary
Integrate intent analyzer into the transcript interactor. Also, split the current interactor into two interactors for CA. And fixed some typos regarding total_children attribute and arrow functions in the intent model.
Change types

[x] Non-breaking change
[x] Adding tests
[x] Adding to API

Testing
yes
How to manually test this PR (QA instructions)
I am using Postman to send get and post requests and don't know if there's another way to send a get request from our FE rn. Anyway, if you have Postman, upload a transcript to the DB and send a GET request. Notice that the intents are returned in a list exactly as according to intent analyzer, and it is different from how it appears in the database prior to analysis. If there is nothing in the db, an empty list is returned.
Questions

In reference to Sam's comment above:

On Postman, we can specify the query for the transcripts using the body of the GET request. You can see in the screenshot we are specifically seeking those with project_id of 1, which correctly returns all 5 corresponding items in the DB. This actually isn't the greatest example because all 5 items in the DB matched, but I also tested it with a different attribute that could distinguish between transcripts, and it works!


qhull input error: input is less than 3-dimensional since it has the same x coordinate

Hello i've created an issue last summer Using LiDAR Classification of Vegetation instead of NDVI and "Gridded building roof heights" ?.
I managed to run your process with my data and i wanted to implement it on a large area.
The LiDAR i'm using have already a great classification of Vegetation so there is no need to use the gridded points of the CityGML building.
You told me that the workflow is sequential, so i did the following:

filter my point cloud with vegetation and ground
Create a canopy height model(CHM)
Start at the part of the individual tree segmentation

On some area, the process with my data filtered on vegetation works perfectly.

I even manage to create CityGML with your FME script, and display them on a web page

But in another area, i have an error about Convex Hull
This is the line where i get the error
# calculate 3D convex hulls around segmented tree points
# retrieve volume and surface area of the hulls
crown_volumes_df <- compute_crown_volumes(lidar_surface_points, "treeID_temp")

Received error code 1 from qhull. Qhull error:
QH6013 qhull input error: input is less than 3-dimensional since it has the same x coordinate

While executing:  | qhull FA  Qt
Options selected for Qhull 2015.2.r 2016/01/18:
  run-id<PHONE_NUMBER>  FArea-total  Qtriangulate  _pre-merge  _zero-centrum
  _max-width 0.25  Error-roundoff 3.1e-09  _one-merge 2.2e-08
  _near-inside 1.1e-07  Visible-distance 6.2e-09  U-coplanar-distance 6.2e-09
  Width-outside 1.2e-08  _wide-facet 3.7e-08

When i have this error, the whole process stops.
I have tried different things without success:

Use raster crowns_mcws_grid to find area on my point cloud where there are not enough points
Use  vector mcws_segments_poly to get the number of points of my point cloud that are inside each MultiPolygon

At some point, i can see when display the LiDAR and the vector layer mcws_segments_poly that there are only one or a few point inside crowns.

Even after deleting this crowns and points, there is still the same issue
I wanted to know, if you had already met this error and where the problem is coming from.
If needed, i can share with you the code and the data i used
Thanks in advance

Hi Klatbahll,
Thanks for bringing this to my attention. Indeed, I was able to replicate similar errors. This can occur due to either a due to insufficient points within a tree crown (minimum 4) or, sometimes, even with a sufficient number of points, duplicate points may exist with identical XYZ coordinates.
I've made adjustments to the code and incorporated filters to remove duplicates and consider crown dimensions. Could you please check if your processing works with the updated code?
Besides, your customization of the workflow is reasonable, and the web-based visualization of the 3D tree models looks impressive. It's great to see that.

Thank you very much, i will try the new code this week and i'll let you know what happens.

Hello again,
I managed to test the new code that fix the issues i had.
Like i told you before we are running your code without the parts that uses the building gridded heights.
It's because our LiDAR has a good Vegetation Classification.
We have two differents datasets of LiDAR, created by two different companies.
One is working perfectly, and the second one we got some issues.
The issues happend at the same line than before with compute_crown_volumes and it's always related to convexHull.
# calculate 3D convex hulls around segmented tree points
# retrieve volume and surface area of the hulls
crown_volumes_df <- compute_crown_volumes(lidar_surface_points, "treeID_temp")

First issue we encountered is this one :
Error in convhulln(p, "FA") :
Received error code 2 from qhull. Qhull error:
QH6114 qhull precision error: initial simplex is not convex. Distance=0

While executing: | qhull FA Qt
Options selected for Qhull 2015.2.r 2016/01/18:
run-id<PHONE_NUMBER> FArea-total Qtriangulate _pre-merge _zero-centrum
_max-width 0.32 Error-roundoff 3.1e-09 _one-merge 2.2e-08
_near-inside 1.1e-07 Visible-distance 6.2e-09 U-coplanar-distance 6.2e-09
Width-outside 1.2e-08 _wide-facet 3.7e-08

precision problems (corrected unless 'Q0' or an error)
1 flipped facets

The input to qhull appears to be less than 3 dimensional, or a
computation has overflowed.

Qhull could not construct a clearly convex simplex from points:
- p3(v3): 1.6e+06 2.3e+06 1.6
- p2(v2): 1.6e+06 2.3e+06 1.5
- p0(v1): 1.6e+06 2.3e+06 1.8
- p1(v0): 1.6e+06 2.3e+06 1.6

The center point is coplanar with a facet, or a vertex is coplanar
with a neighboring facet. The maximum round off error for
computing distances is 3.1e-09. The cen

What we tried :
Export the layer crowns_mcws_poly and use it to remove crowns that we think are the reasons of the convex hull issues.
Here is the actions we did:

Remove crowns from the layer crowns_mcws_poly when it contains 4 points or less
Remove crowns from the layer crowns_mcws_poly when the area is < 0.5m²
Remove "duplicates" points in lidar_surface_points of 1 centimeter distance

After this, we still got this issue:
Error in convhulln(p, "FA") :
Received error code 2 from qhull. Qhull error:
qhull precision warning:
The initial hull is narrow (cosine of min. angle is 0.9999999999999999).
Is the input lower dimensional (e.g., on a plane in 3-d)? Qhull may
produce a wide facet. Options 'QbB' (scale to unit box) or 'Qbb' (scale
last coordinate) may remove this warning. Use 'Pp' to skip this warning.
See 'Limitations' in qh-impre.htm.
QH6114 qhull precision error: initial simplex is not convex. Distance=-1.2e-10

While executing: | qhull FA Qt
Options selected for Qhull 2015.2.r 2016/01/18:
run-id 443649979 FArea-total Qtriangulate _pre-merge _zero-centrum
_max-width 1.6 Error-roundoff 3.1e-09 _one-merge 2.2e-08
_near-inside 1.1e-07 Visible-distance 6.2e-09 U-coplanar-distance 6.2e-09
Width-outside 1.2e-08 _wide-facet 3.7e-08 _narrow-hull 1.1e-16

precision problems (corrected unless 'Q0' or an error)
1 flipped facets

The input to qhull appears to be less than 3 dimensional, or a
computation

We are not used with the convex hull functions.
Do you have any idea about process or treatment on the lidar to avoid this issues ?
If you need it, i can send you the code and the data i used.
Thanks in advance

Hey, thanks for your answer,
https://we.tl/t-F64HCAEtXS
here is the code and the data.
there is a README.md that explain the things we tried
Thanks a lot

I could reproduce the error and found points causing the problem.
It is a "crown" with 5 points, that looks like beeing part of a hedge in front of a building.
Problem is that the points are coplanar. That's why no convex hull can be calculated.
I attached the mcws segment and the points. You can download them and remove the points in your workflow like this:
# remove coplanar points - identified "crown"segment
# Import GeoJSON data as an sf object
coplanar_mcws_path  <- here::here("results/parameterized_tree_crowns/coplanar_mcws.geojson")
coplanar_mcws_sf_poly <- sf::st_read(coplanar_mcws_path)
# merge polygon to pointcloud
lidar_surface_points <- lidR::merge_spatial(lidar_surface_points, coplanar_mcws_sf_poly, attribute = "delete")
# filter from point cloud
lidar_surface_points <- lidR::filter_poi(lidar_surface_points, delete==FALSE)

Like you already mentioned, the crowns segmented are slightly variable.
So it could be, that a similiar error occurs in another area when segmentation is leading to that specific circumstance.
Therefore I recommend testing the lidR::segment_shapes() function to detect coplanar points.
It is already implemented in the part of the workflow filtering for roofs as planar shapes. The same logic could apply for hedges.
{r coplanar points classification}
# classify coplanar points as potential roof points
# lidar_surface_points <- lidR::segment_shapes(lidar_surface_points, lidR::shp_plane(th1 = th1_cop, th2 = th2_cop,k = k_cop), "Coplanar")


Optionally, slow down the opening of PuTTY sessions due to PuTTY file Logging

Is your feature request related to a problem? Please describe.
I turned on PuTTY logging. I am using their special characters &Y &M &D and &T  to create the log file name.  My SuperPutty session opens several windows on the same Linux box.  Oftentimes, I get the PuTTY warning box about the use of the same log file i.e. file name collision.
Describe the solution you'd like
Two solutions come to mind:

Detect opening of multiple PuTTY sessions on the same host. Have option to slow down openings of multiple sessions on same host.
Don't allow multiple sessions to be saved to re-open later. I don't like this idea at all. Option 1 is much better.

Describe alternatives you've considered

Only have a single PuTTY session per host machine saved for later restart.
Turn off PuTTY logging
Open and close PuTTY sessions inside SuperPutty so that multiple sessions are not re-opened on startup.
Open regular PuTTY sessions in the normal way outside of SuperPutty

Additional context
Have submitted a request to the PuTTY team to add a &R  special character to the file name feature. The &R would add a random number to the file name to prevent file name collisons.

A configurable delay seems like a reasonable approach.


update numpy package to 1.21.6

We are closing this branch and creating a new branch that will include both 913 and 920 (Package update).


[Docs] Clarifies ObjectIdentifier guarantees

SR-13564
rdar://69169351

Thanks for identifying this issue and getting the docs updated, @sunbohong!

@swift-ci Please smoke test


fix(deps): update dependency @apollo/utils.logger to v3

This PR contains the following updates:

Package
Type
Update
Change

@apollo/utils.logger
dependencies
major
^2.0.0 -> ^3.0.0

⚠ Dependency Lookup Warnings ⚠
Warnings were logged while processing this repo. Please check the Dependency Dashboard for more information.

Release Notes

apollographql/apollo-utils
v3.0.0
Compare Source
Major Changes

#271 4e85af0 Thanks @trevor-scheer! - Drop support for Node.js v14

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

Renovate Ignore Notification
As this PR has been closed unmerged, Renovate will ignore this upgrade and you will not receive PRs for any future 3.x releases. However, if you upgrade to 3.x manually then Renovate will reenable minor and patch updates automatically.
If this PR was closed by mistake or you changed your mind, you can simply rename this PR and you will soon get a fresh replacement PR opened.


High poly situations

What's the best path for baking high poly assets which have already been processed by mesh optimizer?  Also, is there a way to compress vertex colors?

What do you mean by "baking"? Vertex colors are compressed by default (using quantization + -cc option applies further compression as with other attributes).

To lossy compress things further, this is the sort of thing I'm talking about.  I'm thinking if we could have an auto uv unwrap into quads which then ray cast the texture tiles against the mesh to get normals, color, etc.  Would be a nice feature.
https://marmoset.co/posts/toolbag-baking-tutorial/

@unicomp21 It seems like you're looking for attribute aware simplification, like https://github.com/zeux/meshoptimizer/issues/158 ? (Not in yet, but planned...)

@AndrewJDR looks to be related, but would be nice if the cages and uv unwrap (or meshlet generation) could be automated?  After that stage, if we could have something for baking textures that would be cool too.  Perhaps it would be a different project, once the cages and uv unwrap are automated.  Or, maybe I'm in left field, lol.

Yeah I think this is talking about a remeshing approach where also instead of using the original texture, a new texture should be synthesized to closely mirror the original appearance. I had remeshing on my todo list, but I don't have immediate plans to implement it - need to finish other projects first. I'm going to convert this to a discussion thread so that the conversation can continue.


Pod initialization error with NGINX service mesh sidecar proxy

I'm having an issue with doing a rolling redeploy of my deployments and I'm reaching a couple of issues regarding the nginx-mesh-init container.
This is the particular error:
$kubectl logs os-env-deployment-84bbcbdf45-dd98v nginx-mesh-init
2022/05/20 15:47:17 could not create new iptables object, reason: running [/sbin/iptables -t nat -S --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
iptables v1.8.7 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

could not create new iptables object
gitlab.com/f5/nginx/service-mesh/product/sidecar/proxy-agent/pkg/iptables.NewIptables
        /builds/f5/nginx/service-mesh/product/sidecar/proxy-agent/pkg/iptables/iptables.go:41
main.main
        /builds/f5/nginx/service-mesh/product/sidecar/proxy-init/cmd/proxy-init/main.go:22
runtime.main
        /usr/local/go/src/runtime/proc.go:255
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:15811

Environment:
1Master 2 Workers: CentOS stream 8
CRI: cri-o
K8 version: 1.23.6
CNI: Calico 3.22.2
Ingress: NGINX ingress nginx/nginx-ingress:2.2.0 daemonset
NGINX service mesh installed through helm: 1.4
Is there some additional permissions I need to allow for the NGINX proxy that the Helm chart doesn't provide?
Troubleshooting checks:
Tested that command on host device (iptables -t nat -S --wait) and worked.
Deployed previous version of NGINX service mesh
Tested command on my container running Fedora 35: worked
Other pertinent information:
$kubectl describe deployment os-env-deployment
Name:                   os-env-deployment
Namespace:              default
CreationTimestamp:      Wed, 27 Apr 2022 15:56:16 -0500
Labels:                 app=os-env
Annotations:            deployment.kubernetes.io/revision: 7
Selector:               app=os-env
Replicas:               3 desired | 1 updated | 4 total | 3 available | 1 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:       app=os-env
  Annotations:  kubectl.kubernetes.io/restartedAt: 2022-05-19T18:09:08-05:00
  Containers:
   private-reg-container:
    Image:      <privatereg>/tbredow/os-environment-tset
    Port:       8000/TCP
    Host Port:  0/TCP
    Environment:
      testvalue:  fooey
    Mounts:
      /nfs from kubenfs01 (rw)
  Volumes:
   kubenfs01:
    Type:      NFS (an NFS mount that lasts the lifetime of a pod)
    Server:    <IP_ADDRESS>
    Path:      /Kube_NFS01
    ReadOnly:  false
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    False   ProgressDeadlineExceeded
OldReplicaSets:  os-env-deployment-6c479975ff (3/3 replicas created)
NewReplicaSet:   os-env-deployment-84bbcbdf45 (1/1 replicas created)
Events:          <none>

$ kubectl describe pod os-env-deployment-84bbcbdf45-dd98v
Name:         os-env-deployment-84bbcbdf45-dd98v
Namespace:    default
Priority:     0
Node:         <hostname2>/<IP_ADDRESS>
Start Time:   Thu, 19 May 2022 18:09:08 -0500
Labels:       app=os-env
              nsm.nginx.com/deployment=os-env-deployment
              pod-template-hash=84bbcbdf45
              spiffe.io/spiffeid=true
Annotations:  cni.projectcalico.org/containerID: aaf1cbd6632d289549c504c801b1c228654dfe01c403047523006e6051d44716
              cni.projectcalico.org/podIP: <IP_ADDRESS>/32
              cni.projectcalico.org/podIPs: <IP_ADDRESS>/32
              injector.nsm.nginx.com/status: injected
              kubectl.kubernetes.io/restartedAt: 2022-05-19T18:09:08-05:00
Status:       Pending
IP:           <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/os-env-deployment-84bbcbdf45
Init Containers:
  nginx-mesh-init:
    Container ID:  cri-o://c8c8a9c5226306efade80f1939f81e5f7d25de374fa13460680a084d3e5609a7
    Image:         docker-registry.nginx.com/nsm/nginx-mesh-init:1.3.0
    Image ID:      docker-registry.nginx.com/nsm/nginx-mesh-init@sha256:f56eb2ee03e1930b5a745e689e9a608f3e90e041745216763e8ea45724ad2c80
    Port:          <none>
    Host Port:     <none>
    Args:
      --ignore-incoming-ports
      8887
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Fri, 20 May 2022 10:52:21 -0500
      Finished:     Fri, 20 May 2022 10:52:21 -0500
    Ready:          False
    Restart Count:  201
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sl9zd (ro)
Containers:
  private-reg-container:
    Container ID:
    Image:         <privatereg>/tbredow/os-environment-tset
    Image ID:
    Port:           8000/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Environment:
      testvalue:  fooey
    Mounts:
      /nfs from kubenfs01 (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sl9zd (ro)
  nginx-mesh-sidecar:
    Container ID:
    Image:         docker-registry.nginx.com/nsm/nginx-mesh-sidecar:1.3.0
    Image ID:
    Port:          8887/TCP
    Host Port:     0/TCP
    Args:
      -s
      8000
      -n
      os-env-deployment
      --namespace
      nginx-mesh
      -d
      example.org
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Environment:
      MY_DEPLOY_NAME:      os-env-deployment
      MY_NAMESPACE:        default (v1:metadata.namespace)
      MY_POD_NAME:         os-env-deployment-84bbcbdf45-dd98v (v1:metadata.name)
      MY_POD_IP:            (v1:status.podIP)
      MY_SERVICE_ACCOUNT:   (v1:spec.serviceAccountName)
    Mounts:
      /run/spire/sockets from spire-agent-socket (ro)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sl9zd (ro)
Conditions:
  Type              Status
  Initialized       False
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  kubenfs01:
    Type:      NFS (an NFS mount that lasts the lifetime of a pod)
    Server:    <IP_ADDRESS>
    Path:      /Kube_NFS01
    ReadOnly:  false
  kube-api-access-sl9zd:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
  spire-agent-socket:
    Type:          HostPath (bare host directory volume)
    Path:          /run/spire/sockets
    HostPathType:  DirectoryOrCreate
QoS Class:         BestEffort
Node-Selectors:    <none>
Tolerations:       node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                   node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason   Age                     From     Message
  ----     ------   ----                    ----     -------
  Warning  BackOff  4m16s (x4604 over 16h)  kubelet  Back-off restarting failed container

$ kubectl get nodes -o wide
<hostname1>   Ready    control-plane,master   28d   v1.23.6   <IP_ADDRESS>   <none>        CentOS Stream 8   4.18.0-348.2.1.el8_5.x86_64   cri-o://1.23.2
<hostname2>   Ready    <none>                 28d   v1.23.6   <IP_ADDRESS>   <none>        CentOS Stream 8   4.18.0-348.2.1.el8_5.x86_64   cri-o://1.23.2
<hostname3>  Ready    <none>                 28d   v1.23.6   <IP_ADDRESS>   <none>        CentOS Stream 8   4.18.0-348.2.1.el8_5.x86_64   cri-o://1.23.2

I'm seeing that CentOS users that have seen similar error messages ran commands like the following on their host with success:
sudo modprobe iptable_filter
sudo modprobe iptable_nat

That worked! I checked the IP tables and nothing seemed out of sort, but that did the trick. Thank you for your help.
kubectl get pods
NAME                                 READY   STATUS    RESTARTS   AGE
os-env-deployment-8645495848-8r26n   2/2     Running   0          33s
os-env-deployment-8645495848-kxr62   2/2     Running   0          16s
os-env-deployment-8645495848-r2fdv   2/2     Running   0          24s


Use PROSE to predict column type

https://app.zenhub.com/files/186917455/c3748d27-2c7a-4b4f-bdb4-409238e61671/download

https://github.com/dotnet/machinelearning-tools/pull/745

This will be validated with multiple bug bashes. Closing


Added XDG Base Directory support

There is a recent go package that adds XDG Base Directory support to golang programs,
https://github.com/zchee/go-xdgbasedir
More about this at https://wiki.archlinux.org/index.php/XDG_Base_Directory_support
This pull request uses go-xgdbasedir in order to store the configuration file to the designated config dir of the system.
The filename for the configuration is httplab.
Tested on Ubuntu.

thanks for doing this, I'd like to create some specs to properly define/understand the behavior first before it gets too complicated


buildRustCrate: set CARGO_FEATURE_* when running the build script

Motivation for this change
Cargo sets CARGO_FEATURE_* for all features when running a build
script:
https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts
Some crates have build scripts (e.g. openblas-src) that rely on the
feature variables being properly set.
Since we now need several representations of features, this change
also updates createFeatures to be a list of features, rather than
rustc feature arguments. configureCrate and buildCrate then
build the required representations as-needed.
Fixes #68978
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@ofBorg build buildRustCrateTests


Concurrency parameter works incorrectly

I've noticed that when I set concurrency parameter to a value of

$(nproc --all

Is 12 for my pc and amount of tests I have is 6, launching them by mask, so I've expected testcafe would launch only 6 browsers, but was 12.
Launch command was

npx testcafe "firefox" tests/e2e/ --test-grep "^[^w]" --ts-config-path testcafe.tsconfig.json --speed 1.0 --concurrency 12 -r teamcity --video /tmp/ --video-options 'singleFile=false,failedOnly=true,pathPattern=${TEST}_${USERAGENT}.mp4'

node v14.2.0
npm v6.14.4
npx v6.14.4
testcafe v1.8.4
macOs v10.15.4

Hi @orihomie
This's expected. If you specify --concurrency 12, TestCafe will opens 12 browser instances ignoring the number of tests. If there are fewer tests than browser instances, extra browser instances will not execute tests.


Live Share

Issue Type: Bug
You are running VS Code outside the Applications folder, so we cannot install support for joining sessions using a browser link. You can still join sessions manually.
Extension version: 1.0.1891
VS Code version: Code 1.33.0 (0dd516dd412d42323fc3464531b1c715d51c4c1a, 2019-04-04T15:11:32.076Z)
OS version: Darwin x64 19.4.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz (4 x 2600)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: enabledrasterization: enabledsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
2, 3, 3

Memory (System)
8.00GB (0.02GB free)

Process Argv

Screen Reader
no

VM
0%

@cherisek Thanks for reaching out. Usually, this error shows up because the launcher cannot be set-up, so vsls:// URIs will not be picked up by the operating system. Can you give us a bit more details on your setup? What folder are you running VSCode from? Do you have any  non-default permissions on that folder or on the Users folder?

Hey @dlebu ,  I am running my VSCode from my applications folder. I have read and write permissions for system and admin. everyone is set to read only. I also see this error after click on live share and then trying to sign in through github.

It feels like there is something wrong with your setup. We use the launcher in 2 scenarios: sign in and joining through the browser. You can workaround both:

For sign in, run the command in your palette Live Share: Disable VSCode account authentication. This will revert to legacy sign in, which is supported but not using the launcher.
For joining, run the command: Live Share: Join collaboration session, instead of joining a session through the browser.

Once you did #1, you should be able to share, let me know how it goes. I can take another look on my mac permissions and compare with yours if this does not work.

When I do the step 1. I see command not found.

We've changed our authentication service. See #4128 and if the new authentication is giving you an issue, please create a new issue. Thank you for your patience.


Fix small typo on port number

Changed a typo in the port number on the FlightSQL docs. Port 433 should be 443.

[x] Signed the InfluxData CLA
(if necessary)
[x] Rebased/mergeable

Thanks @gunnaraasen


Bump deps in docs Gemfile

Summary
To make dependabot happy.

This branch does not need a CHANGELOG entry 🙄


fix(migrate): properly migrate btcpayserver configs

Description:
Fix issue with wallet config format conversion when upgrading from 3.x to 4.x.
Motivation and Context:
fix #1901
How Has This Been Tested?
1. Create a btcpayserver config in 0.3.4.
rm -rf /Users/tom/Library/Application\ Support/Electron
git checkout v0.3.4-beta
yarn clean && yarn && yarn dev
NODE_TLS_REJECT_UNAUTHORIZED=0 yarn dev

Create a new wallet, select btcpayserver option, and craft a connection config that looks like btcpay server (you c an use your own node details)
{
  "configurations": [
    {
      "type": "grpc",
      "cryptoCode": "BTC",
      "host": "YOUR_LND_HOST",
      "port": "YOUR_LND_PORT",
      "macaroon": "YOUR_MACAROON_IN_HEX_FORMAT"
    }
  ]
}

2. Switch to this branch, and rebuild/restart the app - verify that wallet config is correctly converted and that the app properly connects to the wallet:
git checkout fix/delete-invalid-btcpayserver-configs
yarn clean && yarn && yarn dev

Types of changes:
Bug fix
Checklist:

[x] My code follows the code style of this project.
[x] I have reviewed and updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes where needed.
[ ] All new and existing tests passed.
[x] My commits have been squashed into a concise set of changes.

Coverage increased (+0.04%) to 19.494% when pulling 804b3e97782c8693432d562e3d50a23cee7c9043 on mrfelton:fix/invalid-btcpayserver-configs into 76558b2a1c9ea5c646ad49ee64a5321c9b15de6b on LN-Zap:master.


BetterEnd & BetterNether incompatibilities

I was making a modpack when i encountered this.
So if i have BetterX installed and use BetterX world gen
A. If tried to goto the nether, i just get stuck on the portal waiting for it to find a location to teleport me
B. If i then disable FastRandom and use the portal again, everything works and chunks generate
C. Then if i Re-enable FastRandom, I can go into the nether, but the chunks that werent generated before wont load, and if i goto an ungenerated chunk, it thread locks
Same-ish effect when going to the end but in A. it just thread locks. Heres the thread dump courtesy of ModernFix https://pastebin.com/6nVs0cri
Snip
"Worker-Main-21" daemon prio=4 Id=198 RUNNABLE
	at org.betterx.bclib.api.v2.generator.map.hex.HexBiomeChunk.<init>(HexBiomeChunk.java:49)
	at org.betterx.bclib.api.v2.generator.map.hex.HexBiomeMap.getChunk(HexBiomeMap.java:85)
	at org.betterx.bclib.api.v2.generator.map.hex.HexBiomeMap.getChunkBiome(HexBiomeMap.java:150)
	at org.betterx.bclib.api.v2.generator.map.hex.HexBiomeMap.getRawBiome(HexBiomeMap.java:125)
	at org.betterx.bclib.api.v2.generator.map.hex.HexBiomeMap.getBiome(HexBiomeMap.java:57)
	at org.betterx.bclib.api.v2.generator.BCLibEndBiomeSource.method_38109(BCLibEndBiomeSource.java:291)
	at net.minecraft.class_3195.method_41613(class_3195.java:147)
	at net.minecraft.class_3195.method_47931(class_3195.java:199)
	at net.minecraft.class_3195$$Lambda$39594/0x0000000804cd3d78.test(Unknown Source)
	at java.base@17.0.1/java.util.Optional.filter(Optional.java:218)
	at net.minecraft.class_3195.method_47932(class_3195.java:199)
	at net.minecraft.class_3195.method_41614(class_3195.java:125)
	at net.minecraft.class_2794.method_41044(class_2794.java:513)
	at net.minecraft.class_2794.method_41041(class_2794.java:466)
	at net.minecraft.class_2794$$Lambda$39580/0x0000000804cc9af0.accept(Unknown Source)
	at java.base@17.0.1/java.lang.Iterable.forEach(Iterable.java:75)
	at net.minecraft.class_2794.method_16129(class_2794.java:448)
	at net.minecraft.class_2806.method_39464(class_2806.java:54)
	at net.minecraft.class_2806$$Lambda$1770/0x000000080151b530.doWork(Unknown Source)
	at net.minecraft.class_2806.method_12154(class_2806.java:252)
	at net.minecraft.class_3898.method_17225(class_3898.java:684)
	at net.minecraft.class_3898$$Lambda$35748/0x0000000804785a90.apply(Unknown Source)
	at com.mojang.datafixers.util.Either$Left.map(Either.java:38)
	at net.minecraft.class_3898.method_17224(class_3898.java:673)
	at net.minecraft.class_3898$$Lambda$35601/0x0000000804756220.apply(Unknown Source)
	at java.base@17.0.1/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150)
	at java.base@17.0.1/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:482)
	at net.minecraft.class_3900.method_17634(class_3900.java:62)
	at net.minecraft.class_3900$$Lambda$35747/0x0000000804785870.run(Unknown Source)
	at net.minecraft.class_3846.method_16907(class_3846.java:91)
	at net.minecraft.class_3846.method_16900(class_3846.java:146)
	at net.minecraft.class_3846.run(class_3846.java:102)
	at java.base@17.0.1/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1395)
	at java.base@17.0.1/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
	at java.base@17.0.1/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
	at java.base@17.0.1/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
	at java.base@17.0.1/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
	at java.base@17.0.1/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)

When something like this happens, please manually trigger a crash-report by holding F3 + C for 10 seconds.
here's what i got:
java.lang.ExceptionInInitializerError
	at net.minecraft.world.biome.source.FixedBiomeSource.<clinit>(FixedBiomeSource.java:17)
	at net.minecraft.world.biome.source.BiomeSources.registerAndGetDefault(BiomeSources.java:8)
	at net.minecraft.registry.Registries.method_47485(Registries.java:232)
	at net.minecraft.registry.Registries.method_47482(Registries.java:247)
	at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:721)
	at net.minecraft.registry.Registries.init(Registries.java:245)
	at net.minecraft.registry.Registries.bootstrap(Registries.java:239)
	at net.minecraft.Bootstrap.initialize(Bootstrap.java:69)
	at net.minecraft.client.main.Main.main(Main.java:170)
	at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:470)
	at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74)
	at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23)
	at net.fabricmc.devlaunchinjector.Main.main(Main.java:86)
Caused by: java.lang.ClassCastException: class jdk.random.L64X128MixRandom cannot be cast to class net.minecraft.util.math.random.Random (jdk.random.L64X128MixRandom is in module jdk.random of loader 'app'; net.minecraft.util.math.random.Random is in unnamed module of loader net.fabricmc.loader.impl.launch.knot.KnotClassLoader @d2cc05a)
	at net.minecraft.util.math.random.ChunkRandom.handler$zza000$faster-random$test(ChunkRandom.java:525)
	at net.minecraft.util.math.random.ChunkRandom.<init>(ChunkRandom.java:19)
	at net.minecraft.world.biome.Biome.<clinit>(Biome.java:56)
	... 13 more

Their random generator gets created here:
https://github.com/quiqueck/BCLib/blob/3b23118a28bbea0363e25378aab38cbff45f9683/src/main/java/org/betterx/bclib/api/v2/generator/map/hex/HexBiomeMap.java#L85

I did find a fix after messing around with ChunkRandom, although I really don't like it.
One fix is to assign a vanilla CheckedRandom in ChunkRandom, but this will hurt worldgen performance.
package com.github.anopensaucedev.fasterrandom.mixin;

import net.minecraft.util.math.random.CheckedRandom;
import net.minecraft.util.math.random.ChunkRandom;
import net.minecraft.util.math.random.Random;
import org.spongepowered.asm.mixin.Final;
import org.spongepowered.asm.mixin.Mixin;
import org.spongepowered.asm.mixin.Mutable;
import org.spongepowered.asm.mixin.Shadow;
import org.spongepowered.asm.mixin.injection.At;
import org.spongepowered.asm.mixin.injection.Inject;
import org.spongepowered.asm.mixin.injection.callback.CallbackInfo;

@Mixin(ChunkRandom.class)
public class ChunkRandomMixin {

	@Mutable
	@Shadow
	@Final
	private Random baseRandom;

	@Inject(method = "<init>(Lnet/minecraft/util/math/random/Random;)V",at = @At("RETURN"))
	private void fasterrandom$fixBetterX(Random baseRandom, CallbackInfo ci){
		this.baseRandom = new CheckedRandom(0);
	}

}

I have absolutely no idea what fasterrandom$test is, as no method is ever named that in the source code, refmap or decompiled source. There is also nothing in these fields that would even have test as a member.

I might push this fix as-is to resolve it for now, but ideally this should be looked into further.

Could add a compat mixin that changes their random number generator back to a normal one.
Maybe a feature to disable the random generator replacement if it's instantiated from certain classes would be handy in the future for this.

Just a shout, maybe the split() method doesn't work as intended

Actually, i think that might be it.
variants of split like split(int x, int y, int z) aren't implemented, but i think pasting them in won't work.
Also, the only test that makes sense (as in, calls split()) is all the ones in MaterialRules, which never manages to get called when entering the nether.

Fixed with #41/#42 (merged)


include basic badges

add new Badge behaviour

-> slightly changes formatting due to my VS Code

Hi @KurtLa, thanks a lot for your PR, but it has too many merge conflicts resulting from using older version of Flutter and its packages.
Please upgrade your packages and then do a PR.

Hey @DrunkOnBytes
I'm very sorry, but I just saw your comment. My small case study project is up and running, but if you want me to fix the merge issues, I can do so.

No need now @KurtLa.
Another person from the community also sent a PR to add the badge features.
One suggestion for any future PRs you send. Try to minimize merge conflicts and avoid inclusion of 3rd party packages.
Thank you for the PR though. I hope you'll continue supporting this project in the future as well.


More selective process annotation

Right now it's possible to add a field to all messages, typically used to indicate per-process information:
eliot.add_global_fields(pid=os.getpid())

This is far too verbose in many cases, since redundant information is added to all messages.
A better alternative would be to add these fields only to start messages of actions and to cross-process tasks when they are first started, i.e. eliot:remote_task. That way the information is added in a context that indicates that it applies to all child messages, removing the need for redundancy.
Proposed new API:
eliot.add_global_fields(pid=os.getpid()) # backwards compat
eliot.add_global_fields(eliot.GLOBAL_ALL, pid=os.getpid()) # new way to specify current policy
eliot.add_global_fields(eliot.GLOBAL_START, pid=os.getpid()) # only task start and `eliot:remote_task` messages

It isn't entirely clear to me that this is too verbose, at least absent tool support for re-interpolating the fields from those messages that don't have them.

My thought is it doesn't need to be on all messages. If you're not sure which machine a specific message is from, either look at the full tree or query for more metadata from e.g. journald.


[DOCS] Update the Building a Server documentation page

As was mentioned in the #44 , RR doesn't support custom plugins by copying the main.go file anymore. We need to update the related documentation page https://roadrunner.dev/docs/beep-beep-build with updated information on how to build a custom server.

Done by https://github.com/spiral/roadrunner-docs/pull/60


build, backend: add backend commit failpoints

those commit failpoints we were talking about the other day /cc @gyuho

lgtm. thanks.

lgtm


github_packages: Add glibc to os.version on Linux

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

Add glibc_version to os.version so that brew install can verify that the host has sufficiently recent version of glibc, and install the brewed glibc if not.

Review period will end on 2021-04-05 at 19:33:42 UTC.

Add glibc_version to os.version so that brew install can verify that the host has sufficiently recent version of glibc, and install the brewed glibc if not.

brew install won't query os.version here. If it's specific to GitHub Packages I'd suggest it be part of https://github.com/Homebrew/brew/pull/10983 and it'll be significantly easier to parse if it's a separate annotation rather than something that needs extracted from the os.version.

Add glibc_version to os.version so that brew install can verify that the host has sufficiently recent version of glibc, and install the brewed glibc if not.

brew install won't query os.version here. If it's specific to GitHub Packages I'd suggest it be part of https://github.com/Homebrew/brew/pull/10983 and it'll be significantly easier to parse if it's a separate annotation rather than something that needs extracted from the os.version.

https://github.com/Homebrew/brew/pull/10983/files#diff-4890b590cb90a2c9ef5af6c48b020b952b712a1b080fa39be1c377de8e8a7c62R75
My PR to install bottles from GitHub Packages already supports querying and selecting the correct bottle based on os.version for macOS. I'd like to add support for that feature to Linux as well, where the version of glibc is what matters. Parsing is straight forward with os_version[/glibc ([0-9.]+)/, 1]

If it's specific to GitHub Packages I'd suggest it be part of #10983

My reason to include it in this PR rather than #10983, is that I want the metadata in before bulk uploading Brewsci/bio bottles to GHCR. My PR #10983 to install from GHCR and consume this metadata is not yet ready to be merged, but this PR is to create the metadata, so that it can be consumed.

This year we're planning on migrating building bottles for Linux from Ubuntu 16.04 to Ubuntu 18.04. We need this metadata to ensure that only compatible bottles are installed by the client and ensure that this migration goes smoothly.

I'd like to add support for that feature to Linux as well, where the version of glibc is what matters. Parsing is straight forward with os_version[/glibc ([0-9.]+)/, 1]

It would be more straightforward still when you don't need to filter based on a subset of the OS version. It also isn't an OS version which is a metadata cleanliness argument for me.

This year we're planning on migrating building bottles for Linux from Ubuntu 16.04 to Ubuntu 18.04. We need this metadata to ensure that only compatible bottles are installed by the client and ensure that this migration goes smoothly.

Cool. Fine to add it in some form but let's not put it in the OS version when it's not the OS version.

Review period skipped due to critical label.


Fix SDP mangling, fix reportFatal in call.js, use latest webrtc-adapter from NPM rather than bower

Description

SDP has changed in Chrome M50 hence there are more video error correction params we need to remove for the bandwidth tests.
Update and use latest webrtc-adapter from NPM rather than bower.
Fix reportFatal (dead code) in call.js

Fixes #178
Purpose
Fix errors seen in Chrome M50

Hold a sec realized the vulcanize was still pulling in the old adapter

This pull request does so much stuff at same time...
did we stop updating bower webrtc-adapter? why move to npm module?

Sorry for doing so much in one PR, at least it's in separate commits.

lgtm


[Box] Update BoxProps to temporarily allow any props

BoxProps are currently too limiting and will throw errors when using any styled props, such as ml or fontWeight
This change temporarily allows any props to be used with Box while more comprehensive types are being developed

@oliviertassinari Would be 💯 if we could get this merged in and released as soon as possible. This is the last change that's holding us back from using Box.

I see, so you're suggesting I do something like the following in my tsconfig.json:
"paths": {
  "@material-ui/core/Box": ["MyApp/types/box.d.ts"]
}

This should work, although worth noting that the Box component is effectively unusable from TypeScript without this.

I see, so you're suggesting I do something like the following in my tsconfig.json:

Exactly.

This should work, although worth noting that the Box component is effectively unusable from TypeScript without this.

We're not happy with the current state but it would help us a lot if users of Box contribute those declarations.

We're not happy with the current state but it would help us a lot if users of Box contribute those declarations.

I'd love to help out if I can get the time to dedicate to it.

@pheuter Do you think that we should close the pull request?

Yeah, makes sense to close until proper typings are introduced.
Sent from mobile

From: Olivier Tassinari<EMAIL_ADDRESS>Sent: Tuesday, March 26, 2019 6:35 PM
To: mui-org/material-ui
Cc: Mark Fayngersh; Mention
Subject: Re: [mui-org/material-ui] [Box] Update BoxProps to temporarily allow any props (#15048)
@pheuterhttps://github.com/pheuter Do you think that we should close the pull request?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mui-org/material-ui/pull/15048#issuecomment-476879117, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAFqGiCkTb32GyTzNlYc58L64a_BllSoks5vaqCXgaJpZM4cHFC8.

@pheuter Alright, I'm adding a reference to the original issue: #14944. This way, somebody else can discover it, it provides more context.


selfie: Add write_synced

Currently, selfie directly uses the host's write function when implementing SYS_WRITE for higher bootlevels. This however causes issues with glibc buffering when these instances attempt to write to FD 1, causing output to appear out of order to the grader. As such, a new function write_synced is added which properly handles the case of writing to console for the highest bootlevel, by using printf (which is properly synced) to do so.
This fixes the issue addressed in both #337 and #338.

Quick question, is it safe to submit the assignment with the current state of the repository? Or should I wait until this gets merged before doing so?

NOTE: one bug is remaining in this PR, line 3055 still checks output_fd instead of fd. This should be addressed before merging (I will do so myself once the time is more reasonable .-.).

NOTE: one bug is remaining in this PR, line 3055 still checks output_fd instead of fd. This should be addressed before merging (I will do so myself once the time is more reasonable .-.).

Fix pushed for this, the PR should be fully mergeable now

@Popax21 @CAS-ual-TY thanks a lot. Will polish this now a bit and then push.

@Popax21 @CAS-ual-TY Please check out https://github.com/cksystemsteaching/selfie/commit/bdba082e31b4c76c999eb03c71aee1b79c913345
Any further comments? @CAS-ual-TY what happens when you roll back your PR, use -m 1 again?

@Popax21 @CAS-ual-TY Please check out bdba082
Any further comments? @CAS-ual-TY what happens when you roll back your PR, use -m 1 again?

Looks good to me, thanks for handling the issue this quickly!

Any further comments? @CAS-ual-TY what happens when you roll back your PR, use -m 1 again?

@ckirsch Tested it. You now have to print your name at the "correct" place in code, printing it right before printing the synopsis does not work anymore.
This is the case for runs both with and without -m 1. I personally would call this behavior of the grader correct now and the code looks good.


OWL Ontology for QDCAT

Copied issue from previous repository - summary of issue commentary is as below.
Define the Ecosciences Queensland profile of DCAT as an OWL ontology.
Starting here: https://github.com/EcosciencesQLD/metadata-schema/blob/master/rdf/qdcat.ttl
The 'ontology' is rather simple - just a few extra properties that we have found that needed to be added to DCAT.
The SHACL file is much more comprehensive -

Transferred issue to https://github.com/qg-qesd/metadata-schema/issues/13


Add info for lock cards

closes #90

Submission checklist:
Layout

[x] Change inspected in the mobile web ui
[x] Change inspected in dark mode

I'll go for popover instead https://github.com/shadcn-ui/ui/issues/86

ok that's much better

I tested on Nova and it works well


High School of Computer Science "Grigore Moisil"

http://liis.ro

@alexevladgabriel lib/domains/file.zip: this request has an incorrect file path format, please ensure that you are familiar with     this repository rules located at the bottom of this page and change     your request accordingly. If you don't know how to change request, close it and open a new one.     If you are not able to make the pull request according the instructions, please send us an email to<EMAIL_ADDRESS>Please mention this request URL in the message.

@philipto Right now, it's need to be correct.

@alexevladgabriel Pull request merged. Thank you!


chore: redis addon supports multiVersion defined with chartVersion

For each released Chart Version of the Redis addon, a new version of the cmpd and its associated resources (cmpd, configuration, scripts configmap template) is created. This version is reflected in the naming of the corresponding resources. The purpose of this approach is to ensure that existing clusters remain unaffected during upgrades. Existing clusters need to explicitly specify a particular version of the cmpd before performing an upgrade.
It's worth noting that some resources are considered to be less impacted by version changes, so they are not automatically versioned based on the Chart Version. These resources include ClusterDefinition, ComponentVersion, BackupPolicyTemplate, ActionSet, and others.
It's important to mention that currently, the Chart Version follows the KubeBlocks version, such as 0.9.0, 0.9.1, 1.0.0. In future releases, only the Chart Version needs to be maintained.

/approve


Task/delete old import jobs 5872

Linked Issue
Closes #5872
Merge only after https://github.com/treeverse/lakeFS/pull/5840
Context: https://github.com/treeverse/lakeFS/issues/5748

Approving as this is very clearly a major improvement. THANKS!
However I am concerned with in-process scheduling using gocron:

It is hard to observe the results of cleanup: sure there are logs, but I have no way of knowing when to look.
It is very bursty for large clusters, unless lakeFS restarts often and at random.
It is hard to debug in production: if I change some configuration and want to see it try to run again, I can either wait 24h or restart lakeFS.

So I would much prefer to wrap a single command lakefs cleanup (name TBD). It will clean things up now. And users will be able to run it using their favourite production scheduler. For instance in Cloud this could just be a CronJob.

Thanks @arielshaqed,
I agree with your concerns, we've discussed this issue in depth in the past and we realize that at some point we will need to tackle this issue - though this is out of the scope of this PR.
Regarding the solution though - not sure this is the best approach, some of the background tasks might be lengthy and we don't want the user to invoke a synchronous API for that


Add ReceiptMetadata with verifier_info field for checking for verifier parameter mismatch

This PR adds a ReceiptMetadata struct and attaches it to the Receipt type.
The first field added to the ReceiptMetadata is a verifier_info: Digest value, which is constructed from a hash of the parameters for a given a given verifier.
This value can be used to tell when a Receipt and a verifier have different parameters (e.g. the control root may have changed).
It is intented additionally to serve as a routing key for the Ethereum on-chain verifier contracts, ensuring we send a given receipt to the right place.
Additionally, this PR:

Adds an Input type to the ReceiptClaim to serve as a placeholder for a future value type.
It is implemented as an uninhabited type, which means it cannot be constructed.
This ensures that adding fields to this type is not a breaking change to our APIs, and all code paths will deal with the digest only.
Refactors the risc0_groth16 public API to introduce a new VerifyingKey type.
This type implements the Digestible trait and is serializable with serde, which eases implementation of ReceiptMetadata.
Additionally, it works to hide the arkworks types such that we have the option to swap arkworks (which is primarly a library for R&D of proof systems) out for a different Groth16 verifier implementation.

This PR is in draft state while I am still working on:

[x] Adding tests for receipt metadata, including that it remains stable between releases.
[x] Refacoring to remove the metadata.rs file and simply move the types along side the receipt implementation.
[x] Rebase onto a non-functional change PR that just splits apart receipt.rs

I wonder if we can first make a NFC that splits out the receipt types so that it's a lot easier to review.

I wonder if we can first make a NFC PR that splits out the receipt types so that it's a lot easier to review.

I'll go ahead and do that.

I wonder if we can first make a NFC PR that splits out the receipt types so that it's a lot easier to review.

This is done now

I wonder if we can first make a NFC PR that splits out the receipt types so that it's a lot easier to review.

I'll go ahead and do that.

This is done now

Ok, all tests are passing now expect the Ethereum tests (https://github.com/risc0/risc0-ethereum/pull/93 should help keep this test green) and semver checks (this PR contains breaking changes)

In 0a37650, I fixed support for no-std in risc0-groth16. It appears is was half-implemented and the cfg to actually enable no-std in lib.rs was never added. I added that and fixed a handful of errors that popped up as a result. No risc0-groth16 can be used in no-std and there is no need for the cfg statements that were added in https://github.com/risc0/risc0/pull/1776 to conditionally compile CompactReceipt. This avoids the need for any hackyness in getting CompositeReceiptVerifierInfo to be available and consistent between zkVM and host.

@flaub, when you get a chance, this is ready for review

It would be helpful to get your review here @capossele, in particular on the changes to the interface of risc0_groth16. I did some work to:

Remove arkworks from the public interface, as it feels quite likely we will want to use a different basis for verification in the future and it would be good to have forwards compatibility there. One reason in particular for this is that we want to have acceleration for Groth16 verification in the near-ish future.
Change from have the prepared verifier key be what people pass around to just being the verifier key. It's not clear to me what the security implications are of receiving a prepared verifying key and using it. It also was odd to have the "prepared" version be the only public option, and we could reintroduce precomputed preparation of the key under the surface.

Looks like this is failing now due to the checked-in receipt for cargo risczero verify.

I ran into a similar problem so my PR drops the risczero verify test until we can generate a receipt automatically at build time: https://github.com/risc0/risc0/pull/1807


[optix] New port

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

Some notes for the reviewer:

OptiX is published under a proprietary license by NVIDIA, hence cannot be installed by vcpkg, but its existence on the system can be checked for.
This is similar to the behavior of the cuda port, and more specifically of cudnn and nccl. The code is not an identical copy, but is written with careful consideration of the practices in these ports.
The FindOptiX.cmake is written in line with FindOptiX.cmakes released by NVIDIA in their various repositories. It works independent of vcpkg, and is probably the most comprehensive one to date.

Note : I will be converting your PR to draft status. If your PR is ready for review, please click on 'ready for review' to reactivate it.

I think it is good to go.

No feature needs to test.
Usage tested pass on x64-windows.

Does it make sense to add a non-trivial port with zero vcpkg CI coverage?
This will also block CI for proposed reversed dependencies such as https://github.com/microsoft/vcpkg/pull/33448.

Does it make sense to add a non-trivial port with zero vcpkg CI coverage? This will also block CI for proposed reversed dependencies such as #33448.

Historically we have required at least one platform to pass before we are willing to index something in the curated registry.

Does it make sense to add a non-trivial port with zero vcpkg CI coverage? This will also block CI for proposed reversed dependencies such as #33448.

Historically we have required at least one platform to pass before we are willing to index something in the curated registry.

The word "historically" gives me hope.
This is a pragmatically useful port, it not only opens the way for #33448 and other upcoming libraries that depend on OptiX, but also enables ports that are already within the main branch such as ParaView and VTK to use their ray tracing backends.

The word "historically" gives me hope.

I don't think there's a good reason to change this policy. We are 'selling' a group of things that we have tested to work together; as written we can't sell that because we can't test it.

This is a pragmatically useful port, it not only opens the way for #33448 and other upcoming libraries that depend on OptiX, but also enables ports that are already within the main branch such as ParaView and VTK to use their ray tracing backends.

We couldn't add such a dependency to those ports because they would then become untestable which is a regression.
You could resolve this problem by providing edits to e.g. https://github.com/microsoft/vcpkg/blob/master/scripts/azure-pipelines/windows/deploy-cuda.ps1 which would allow our lab to test the port.

The word "historically" gives me hope.

I don't think there's a good reason to change this policy. We are 'selling' a group of things that we have tested to work together; as written we can't sell that because we can't test it.

This is a pragmatically useful port, it not only opens the way for #33448 and other upcoming libraries that depend on OptiX, but also enables ports that are already within the main branch such as ParaView and VTK to use their ray tracing backends.

We couldn't add such a dependency to those ports because they would then become untestable which is a regression.
You could resolve this problem by providing edits to e.g. https://github.com/microsoft/vcpkg/blob/master/scripts/azure-pipelines/windows/deploy-cuda.ps1 which would allow our lab to test the port.

I recently attempted this, modifying deploy-cuda.ps1 to download and run the installer. However unlike CUDA, OptiX requires authentication to Nvidia Designworks, see https://developer.nvidia.com/downloads/designworks/optix/secure/8.0.0/nvidia-optix-sdk-8.0.0-win64.exe . At this point I do not think there is a way or reason to push this port further with the current limitations.
My solution is to close this + VisRTX port MRs and using them as overlay ports myself.

I recently attempted this, modifying deploy-cuda.ps1 to download and run the installer. However unlike CUDA, OptiX requires authentication to Nvidia Designworks, see https://developer.nvidia.com/downloads/designworks/optix/secure/8.0.0/nvidia-optix-sdk-8.0.0-win64.exe . At this point I do not think there is a way or reason to push this port further with the current limitations.

This is not necessarily fatal; we did something similar to get the cudnn parts. (I myself filled out all the sign your life away bits and put them in a storage account)
We would need such authentication ourselves though.
That all said I'm not sure how I feel about including things in the curated registry that aren't publicly available; I think we should be encouraging Nvidia to host their own registry with this stuff and then they could set whatever policy they wish?

@ras0219-msft @dan-shaw @JavierMatosD and I affirmed that we want at least one platform in the test matrix today but we're still interested in adding stuff to our labs on your behalf if you wish to try.


Fix a sentence in core-testing-guide.adoc

While you're at it, could you add a comma before the "and Geb for..."?

Sure, I'll do it with pleasure. Do you think it would be convenient to drop this pull request and submit a new one with this changes plus the comma?

You can if you want, but it's not like PRs make a snapshot of the content when they're opened, so what I usually do in these cases is

Commit the change
Squash it with your previous commit locally
Force push with git push origin +master

Overwriting the history like that is evil to do on a repo someone might fork.  But for cases like this, nobody's gonna fork a fork, so it's fine.

It's done. Cheers.

Thanks!

My pleasure.


Freeze Pouchfile specification

Should all vault configuration be read from environment after #10 is done? We could then remove address and token from Pouchfile.


Support squashfs files that start at an offset

Is your feature request related to a problem? Please describe.
The AppImage file format conists of an ELF to the end of which a squashfs file is appended.
Describe the solution you'd like
I would like to use libsqsh on such squashfs files that don't start at offset 0 but at another offset.
Hence, I am looking for

An example to extract from such files (like sqsh_file_content(archive, path))
An example how to list directories from such files (like https://github.com/Gottox/libsqsh/tree/main/examples)

Additional context
This library could become really, really useful in the context of the AppImage ecosystem (e.g., file managers that want to show the proper icons for AppImages, etc.); for this the offset functionality is essential. Thanks for making this library, for licensing it under a permissive license, and for your support! :+1:
Here is an example file: appimagetool-x86_64.AppImage - the squashfs starts at offset 631200.
References

https://github.com/plougher/squashfs-tools/blob/e43ebfc3a6fa6bde5a176d077486b3419fec5b36/squashfs-tools/unsquashfs.c#L4143-L4151
https://github.com/plougher/squashfs-tools/blob/e43ebfc3a6fa6bde5a176d077486b3419fec5b36/squashfs-tools/unsquashfs.c#L53
https://github.com/vasi/squashfuse/pull/7

I introduced offset handling. Just set archive_offset to the desired offset.
Source based on on examples/list_files_ll.c:
#include <sqsh.h>
#include <stdio.h>
#include <stdlib.h>

int
main(int argc, char *argv[]) {
	int error_code = 0;
	if (argc != 2) {
		printf("Usage: %s <sqsh-file>\n", argv[0]);
		return 1;
	}
	struct SqshConfig config = {
		// Read the header file to find documentation on these fields.
		// It's safe to set them all to 0.
		.source_mapper = sqsh_mapper_impl_mmap,
		.source_size = 0,
		.mapper_block_size = 0,
		.mapper_lru_size = 0,
		.compression_lru_size = 0,
		.archive_offset = 631200, // <=======================================
	};
	struct SqshArchive *archive =
			sqsh_archive_new(argv[1], &config, &error_code);
	if (error_code != 0) {
		sqsh_perror(error_code, "sqsh_archive_new");
		return 1;
	}
	const struct SqshSuperblock *superblock = sqsh_archive_superblock(archive);
	uint64_t inode_root_ref = sqsh_superblock_inode_root_ref(superblock);
	struct SqshInode *inode =
			sqsh_inode_new(archive, inode_root_ref, &error_code);
	if (error_code != 0) {
		sqsh_perror(error_code, "sqsh_inode_new");
		return 1;
	}

	struct SqshDirectoryIterator *iterator =
			sqsh_directory_iterator_new(inode, &error_code);
	if (error_code != 0) {
		sqsh_perror(error_code, "sqsh_directory_iterator_new");
		return 1;
	}

	while (sqsh_directory_iterator_next(iterator) > 0) {
		const char *name = sqsh_directory_iterator_name(iterator);
		size_t size = sqsh_directory_iterator_name_size(iterator);
		fwrite(name, size, 1, stdout);
		fputc('\n', stdout);
	}

	sqsh_directory_iterator_free(iterator);
	sqsh_inode_free(inode);
	sqsh_archive_close(archive);
}

Output:
# build/examples/list_files_ll appimagetool-x86_64.AppImage
.DirIcon
AppRun
appimagetool.desktop
appimagetool.png
usr

Thank you very much. This works for me :+1:


iPad: Editing existing objects doesn't work

When I try to modify the attributes of an existing node or way by touching the corresponding text field in the left sidebar the keyboard opens and the node gets unselected. This leads to closing of the sidebar which then only displays the search box.
When I try to use the same form fields during creating a new node everything works, so it's only the edit mode which causes problems.

I'm not seeing this particular issue in mobile Safari on iPhone (not that mobile editing is all roses now). I'm closing this, but let us know if you're still this problem!


Update component DateTime

Warning is set in chrome logs asking to update DateTime component:
Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles for details. * Move data fetching code or side effects to componentDidUpdate. * If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state * Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run npx react-codemod rename-unsafe-lifecycles in your project source folder. Please update the following components: %s DateTime

Log fron chrome's inspector:
app.bundle.js:477076 Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles for details.

Move data fetching code or side effects to componentDidUpdate.
If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state
Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run npx react-codemod rename-unsafe-lifecycles in your project source folder.

Please update the following components: DateTime
printWarning @ app.bundle.js:477076

Reproduce on TW. Search


[release] 0.0.1-beta

TODO
bug fix

[x] #41
[x] #40
[x] #38
[x] #33
[x] #31
[x] #29
[ ] #51
[x] #57
[ ] #49

enhancement

[x] #21
[x] #50
[x] #61

refactor

[x] #53
[x] #54
[x] #58
[ ] #68

Add more buch:


fix: fix exception when editing custom blocks

This PR fixes a variety of exceptions that were thrown when adding fields to custom blocks.

This also fixed #113.

This also also fixed #110.

...aaaand #111.


deps: bump artifact options

Supersedes #114 which only updated download-artifact (which is stated as not being backwards compatible with artifacts uploaded with v3 here).

Note that I tested this PR by temporarily updating the release workflow to run through the steps that use the upload- and download-artifact actions and verified that it worked as expected.


Add aRGENTeaM provider

aRGENTeaM is a great spanish subtitle provider, especially for the latin community. Only episodes subtitles are supported in this first release of the provider.

Anybody knows why my repo pass the Travis-CI tests (https://travis-ci.org/mmiraglia/subliminal), but this PR does not? :(


chore: updated utils with pylint rules

SUMMARY
Several disabled pylint rules utils files can be removed:

bad-whitespace - autoformatting,
unused-import and import-error not prompting error,
E0202
no-member in some cases are resolved.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TEST PLAN

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

Thank you @mistercrunch for review.
cc: @willbarrett


DynamoDBEmbedded is not resolving

https://github.com/awslabs/aws-dynamodb-examples/blob/c68fafca35fb4d46fe39364d66593f5ac0b67fdc/src/test/java/com/amazonaws/services/dynamodbv2/local/embedded/DynamoDBEmbeddedTest.java#L44

its probably an issue with your maven imports. restart your ide/reimport maven

A quick fix would be: import com.amazonaws.services.dynamodbv2.local.embedded.DynamoDBEmbedded;


Consider accepting a Cow instead of Into<&'b str> in App::about

 Issue by d-e-s-o
Sunday Oct 04, 2020 at 18:26 GMT
Originally opened as https://github.com/clap-rs/clap/issues/2150

I find the signature of methods like App::about not super useful. It's probably fine when doing everything statically, because you could easily make sure that the string provided outlives the App object (because most of the time you have a 'static string anyway as everything is defined statically in the code). But consider the case where you'd want to add subcommands dynamically at runtime. It gets unnecessarily unwieldy now, in my opinion, because of the lifetime requirement.
 This way, users that do something more dynamic would at least have the possibility to fudge that with a dynamic memory allocation at the call site, instead of doing some dance to make the generated string outlive the App object or even boxing the string up just to leak it.

 Comment by ldm0
Tuesday Oct 06, 2020 at 01:00 GMT

Related: https://github.com/clap-rs/clap/pull/1728

 Comment by pksunkara
Wednesday May 26, 2021 at 14:40 GMT

@d-e-s-o Do you think you can take a small attempt at this by only changing the about? Would like to see how it improves the API.

 Comment by d-e-s-o
Thursday May 27, 2021 at 16:08 GMT

@d-e-s-o Do you think you can take a small attempt at this by only changing the about? Would like to see how it improves the API.

Sure, see https://github.com/clap-rs/clap/pull/2504.

 Comment by epage
Monday Oct 04, 2021 at 17:53 GMT

This is related to my proposed fix for #1041


[css] [v4] .text-xs-center no longer available

I'm only able to extend @extend .text-center;, not @extend .text-xs-center;. According to the "Migrating" guide, it should be possible

Added responsive variations to our text alignment classes .text-{sm,md,lg,xl}-{left,center,right}.

It was removed in alpha 6 - https://github.com/twbs/bootstrap/pull/21217

@sqal Thanks for this information. What were the reasons?

From the Alpha 6 announcement:

First, we’ve dropped the -xs infix from our lowest (extra small) breakpoint. xs isn’t a responsive breakpoint quite like sm, md, lg, and xl because it doesn’t start applying styles at a min-width and up. It simply applies to everything as there’s no bounding @media query.


Crashes not flushing log to disk properly

I started noticing crashes where in the crash log there's no stack trace, making it near impossible to find the cause.
Confirmed happening in Frontier War and Attrition.
No way to reproduce consistently yet.
Interestingly when observed the stack trace does seem to get printed properly to the console window.

my northstar launcher is crash ever time

Potential way of reproduce
sv_cheats 1; script thread function(){throw ""}()

Should be fixed with #413