Add support for decoding StringArray in LargeUtf8 schema

Vec::<_>::from_type::<Record>(TracingOptions::default())? is very
convenient, but it always returns a LargeUtf8 type for String fields
in Record, which prevents using it before decoding from a
RecordBatch which may contain a StringArray (instead of the expected
LargeStringArray).
This change adds a fallback on error when decoding what we expect to be
a LargeUtf8, to try decoding it as a Utf8 as a last resort.
(this PR contains the commit from #142 to avoid a merge conflict)

Thanks, I'll give it a try

You should be able include the changes as serde_arrow = { version = "0.10.1-rc.1", ... }. See also here.

I'm a little confused by this. Your example here and the documentation show Vec::<Field>::from_value(&batch.schema())?; but from the code and the executable examples, it looks like from_value expects a value rather than a schema. And that value needs to implement Serialize, which means it isn't suitable for types that implement only Deserialize

Def. to include more docs :). The short version:

arrow::datatypes::Schema supports  Serialize, when you include arrow with the serde flag.

E.g., the schema of a batch with fields first: Int32, second: Struct { a: Int32 } will serialize to the equivalent of [{"name": "first", "data_type": {Int32: null}}, {"name": "second", "data_type": { "Struct": [ { "name": "a":, "data_type": {"Int32": null}}]}]
To see this, you could include a println!("{}", serde_json::to_string(&batch.schema())?);

from_value interprets the corresponding serialization events to built the fields for this schema, e.g., [Field::new("first", DataType::Int32, false), Field::new("second", DataType::Struct(vec![Fiedl::new("a", DataType::Int32, false)]), false)].

from_value and its requirement of Serialize are only related to how to obtain the field information. I.e., it replaces the from_type call in your code. That the resulting fields are used in deserialization is unrelated to how the fields are built initially. In my personal usage, I use from_type to reconstruct the schema from a serde-arrow specific JSON format (the arrow serde representation of a schema is a bit more verbose). For the example:
let fields = Vec::<Field>:.from_type(&json!([
  {"name": "first", "data_type": "I32"},
  {"name": "second", "data_type": "Struct", "children": [ {"name": "a", "data_type": "I32} ]},
]);

Oh. And regarding the name: from_value is probably misnamed. I chose the name, as I am typically using it with serde_json::Value(s) and it is conceptually similar to serde_json::from_value. Except, SchemaLike::from_value accepts any Rust type that can be interpreted by serde, not only values. You could think of it implicitly passing the argument throught serde_json::to_value first, then interpreting the resulting JSON object.

Got it, thanks.
For what it's worth, I see a small (5 to 10%) slowdown of the deserialization code of my application when using this vs my PR. It is probably because I use a rather small batch size (256 or 512 records).

* `arrow::datatypes::Schema` supports  `Serialize`, when you include `arrow` with the `serde` flag.

It's arrow_schema, not arrow btw.

Re. Slowdown. Yes, this way of getting the schema is totally, not optimized. If speed is imporant, you can have a look at the second code example in this issue. This way of getting the fields should be much faster.
The arrow crate exports various types, for example arrow:datatypes::Schema. I am only using the indvidiual crates to keep the dependency tree small.


Waypoint: Concatenating Strings with Plus Operator [Beta] grammar

In JavaScript, the + operator when used with a String value, it is called concatenation operator.

Grammatically speaking this should probably read something more like

In JavaScript, the + operator when used with a String value is called the concatenation operator.

Adding another one to this:
The first test says
myStr should have a value of This is the start. This is the end
but it only accepts a value of This is the start. This is the end.
so I think it's missing a period in the test directions
Also it shows undefined in the viewer

@HermanFassett I think the earlier statement

"In JavaScript, the + operator when used with a String value, it is called concatenation operator."

is better to understand.

@abhisekp but it is incorrect English.

Updated:


Changes some code if it has some error please clarify.

Please mention your changes. What did you develop in the existing code? Explain how your code will optimize the existing code?
(It's difficult to me to go through every changed code. It'll be helpful to me to easily get your updated or modified code)
Thank You!

The code in this language is updated already by another contributor. Please feel free to find them and make your changes to the code according to that.


Conform PitchSet to IntegeralLiteralConvertible / FloatLiteralConvertible

Create a PitchSet with a single Pitch as such:
let pitchSet: PitchSet = 60

And therefore an array of PitchSet (soon to be PitchSetSequence ...):
let pitchSets: [PitchSet] = [60,64,67]

In the future:
let polyphony: PitchSetSequence = [60,[64,67],70,[71,73,75]]

Actually, don't. Then it's ambiguous.


Added docs team to CODEOWNERS

Change-type: patch
Signed-off-by: Miguel Casqueira<EMAIL_ADDRESS>

Please make sure to read the CONTRIBUTING document before opening the PR for relevant information on contributing to the documentation. Thanks!

I will a PR to test this.


Redirect instead of login.

Register the first user, it appears in the DB correctly, with the role user and admin, I do not see another error, only that it redirects me to the login.

Hi, "session-cookie-secure" is set to true in release config. It means that user session cookie will be send from browser to server only when website is using https. Run it in debug mode, or set to false if you are running it on localhost. If you are running in production, we strongly recommend using valid ssl certificates.

Thank you very much.
As matusszabo said in "session-cookie-secure" you have to put false if working on localhost
Muchas gracias.
Como matusszabo dijo en "session-cookie-secure" tienes que poner false si se trabaja en localhost


Widget not showing properly

I am django beginner and I have the following Problem. I want to define a model and us this model to generate a form with the markdown-widget.
Model
class ThesisAnmeldung(models.Model):
    forschungsfrage = models.CharField(max_length=500)
    def __str__(self):
        return self.forschungsfrage

Form
class Thesis(ModelForm):
    name = forms.CharField(widget= MarkdownEditor(attrs={'id': 'content','height': 150, } ))
    name2 = forms.CharField(widget= MarkdownEditor(attrs={'id': 'content2','height': 150, } ))#
    class Meta:
        model = ThesisAnmeldung
        fields = ('forschungsfrage',)
        widgets = {'name': MarkdownEditor(attrs={'id': 'content3','height': 150, } ) , }

Problem
name   and name2 are displayed correctly with the markdown-editor.
Only the third field forschungsfrage shows the problem. i can only see a small standard textbox. It seems like the markdown-widget is not used. Is there any solution for this problem?

Was my bad. Some css conflict


When pushing a newly pulled environment with function secrets the push fails with "Parameters: [secretsPathAmplifyAppId] must have values"

Before opening, please confirm:

[X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

How did you install the Amplify CLI?
nem
If applicable, what version of Node.js are you using?
15.5.1
Amplify CLI Version
7.6.3
What operating system are you using?
macOS
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No
Amplify Categories
function
Amplify Commands
pull, push
Describe the bug
I recently added secrets to a function, then asked my colleague to pull the environment, make some changes, then push it back again. Unfortunately this resulted in updates failing (see the screenshot)
I inspected the team-provider-info.json file and realized that secretsPathAmplifyAppId is missing in the function. The secrets are already in the SSM and fully populated.

Expected behavior
Expecting the push to function as the SSM parameters are already populated and there.
Reproduction steps
User 1:

Adds a secret to a function
Push

User 2:

Pulls an entirely new environment
Makes some changes to the function
Push
Awaits UPDATE_FAILED error from cloud formation

GraphQL schema(s)

# Put schemas below this line

Log output

⠦ Updating resources in the cloud. This may take a few minutes...
Following resources failed
✖ An error occurred when pushing the resources to the cloud
🛑 An error occurred during the push operation: Resource is not in the state stackUpdateComplete

Additional information
No response

I fixed this by adding the secretsPathAmplifyAppId:"my-app-id" to the team-provider-info.json, in the function->function-name section ... it was missing from there after I pulled my environment.
Looking at the file history, the line went missing after commit where I migrated to the v2 transformer... (i.e. after running amplify migrate api)

Hey @maziarzamani and @jkervine :wave: since this data is captured in the team-provider-info.json and that file is tracked by git it can be carried from one machine/directory to another via a git pull, although our doc for sharing a single environment are misleading where we suggest an amplify pull to "sync" the environment.
On the other hand I was able to successfully reproduce this issue by using the following steps:

in one directory myapp, create a new amplify project with amplify init -y
add a function with a single secret with amplify add function, add mysecret with some value
push the new resource with amplify push -y
in a separate sibling directory myapp2 pull the existing application with the pull command described in the console amplify pull --appId <amplify-app-id> --envName <existing-env-name>
try adding a small change to the function and push
observe error, missing secretsPathAmplifyAppId
as a workaround, we can:

leverage git to pull latest changes, which will update the team-provider-info.json
or run amplify update function > update secrets > "I'm done" to update the team-provider-info.json without git

Marking as a bug 🙂

I'm having exactly the same problem:

This is my json

This should be fixed in v7.6.23. Let us know if you're still running into issues using the latest version of the CLI.


Don't set uncoerced value to coerced default value.

What does the pull request do?
If a default value is coerced then we were assigning it to the uncoerced value, meaning that next time CoerceValue was called, it would be called with the coerced value instead of the actual value.
Fixed issues
Fixes #11484

You can test this PR using the following package version. 11.0.999-cibuild0036827-beta. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]


Microphone Input

Can scream be made to take in microphone input from the "receiver"?

I know this feature isn't in scream yet, but are there any plans to support this in the future?
I'm using the dual sound card setup for audio input in my VM currently, but I have only one microphone so I have to use an audio splitter. However it proves to be extremely painful to deal with the noises and electrical interference around trying to split an analog signal. It would really be nice if we could do this at software level which would have much less noise issues since it's digital.
I could help with implementing this, but I am not sure where to look at first, if we could have some simple plans/roadmaps on how to implement this feature I might be able to start on it, thanks!

Me too on this suggestion, making a raspberry pi based gaming headset
Windows PC out to RPi should work but I need mic input from RPi to show up in windows !

Me too. Want to build a receiver with Raspberry Pi since Windows doesn't really support LDAC or apt-X, but also need microphone input for communicating.
Is there any workaround could make microphone input to Windows from the receiver?

Scream might be replacing VBAN as my solution to sending audio from my Windows machine to a Raspberry Pi. I haven’t used it in the other direction, but I think it can work bidirectionally when setup that way. Voicemeeter Banana is Windows donationware with VBAN built in and there is an open source Linux implementation of VBAN on GitHub.  Might work for some of these use cases.  Voicemeeter in particular offers some very powerful Windows audio routing.


💡 Features from Redux that I would like to see in react-easy-state

Here are a few things that I like from Redux that I think could enhance this great lib:

Single global store: it is very useful to have access to the whole store from any part of the application. Perhaps some documentation on how to do this properly would be useful.
Action log: in Redux I am able to console.log any action type in any reducer. This is very useful for debugging.

I made a simple counter app with this library and I really like it. I am considering rebuilding a work project to react using this state management library. Great work!

A quick update about the debugger. Currently it's a drill down style logger, which can be enabled separately for each component with view(Comp, { debug: true }).

It logs each render of the component.
If you click on the log, you can see why Easy State scheduled a render for that component. The reason is always a property set/add/delete operation on a store.
If you click on the reasoning it lists a few of formatted stack traces, which show you where exactly the store property was used and mutated in your code. You can click on the links the see the place in the source code.

Is there anything else you would like to see? Is this the 'right direction' to start a debugger? What exactly do you use debuggers - like this - for?

This is nice. I guess I can setup actions 'a la flux' just to label what triggered the update. Very thoughtful. This should cover my needs for now.
Is this feature available on the latest release?

It is not yet released. I have to tweak/test/document it, February 8 still seems like a doable release date. I just wanted to see if it is useful beforehand 🙂

@solkimicreb - Would like to try out this logger / provide feedback. If you've got it in a branch / next

@ro-savage I think you forgot to add the link 🙂

I will put it on a branch tomorrow and write a short doc about what and how I want to do. I spent most of my time with preparing the underlying Observer Utililty library for the changes so far.

You can find it on the next branch. There won't be much debugger related changes in this lib.
Basically I spent my last week to prepare the underlying Observer Utility lib. It now pushes out a lot of data about state access/mutations to a passed debugger function. Easy State will proxy this to it's own devtool option and it will also add a few more events (like render, mount, unmount).
It is designed in a way to eventually make the following possible:

Redux style time travel and session saving / loading / replay (this already had a working prototype).
Hot reloading with keeping the state (hopefully).
A drilldown timeline.
Tracking the property mutations and accesses (in renders) to show the exact reasoning why a render was triggered.

The debugger is a very dirty React App on my Mac currently, I will try to push to a WIP repo ASAP (hopefully today).

v5 has an experimental interface for connecting debuggers. You can test it out with view(Comp, { devtool: console.log }). It just pushes out a huge amout of raw data - related to the view. A more sophisticated devtool is in the making and I will put a prototype in a separate repo soon.
All the needed is data is available now, but the devtool will require a lot of development effort to make it as useful as the Redux one. I will let you know how can you contribute, if any of you are interested 🙂

Devtool would be great, yes. I see devtool and debug options are still undocumented. Will it be possible to log not only views but store instance directly?

just another way to debug:
window.myStore = store({})
you can then access it in the chrome console or even better, you can simply attach it to be watched in chrome -> sources tab.

Do exist a new way to debug? I notice that devtool and debug options are gone

Is there any way to use the old debug feature? That worked for me earlier, but now has been removed

Following up on the debug feature. This would be something super useful I to many I think.

Hi @solkimicreb and Team, would there happen to be any update for this? To bring back the debug feature 😆


Can't properly customize control because of many private variables

Wanted to customize hitTest - 'focus' is inaccessible due to 'private' protection level
Tried to fix focus modifier to public - Property must be declared private because its type uses a private type
and etc.
This project contains errors (I can't describe now it but it linked with constraints + mask area) but I can't even try to fix them by subclassing because all the necessary variables are declared as private.
So if you don't provide proper delegate methods - could you at least remove all the private marks? It is enough fast solution

What are you trying to achieve? And please provide some context that could help reproduce the error.

thanks, I've already fixed the error but the problem remains - I can't customize hitTest because it refers to private variables. In my particular case I want to call "next action" in all the view except of some area which is different from the "TutorialItem" area but can include it.

additionally - inheritable singleton:
https://medium.com/@derrickho_28266/swift-singleton-inheritance-ba64d517ebd5

@gerchicov-bp Thanks for posting the issues. This library and other libraries with the KR prefix are actually proprietary and are made public just in case other people need them. Since I am busy with other updates, please note that it will take some time before I find the time to look into these issues.


Pnpm Install: Spawn Error

Hi Mr. Indaco.
I was really looking forward to using it in my new project but couldn't install it.
internal/child_process.js:408
throw errnoException(err, 'spawn');
^
Error: spawn E2BIG
at ChildProcess.spawn (internal/child_process.js:408:11)
at spawn (child_process.js:677:9)
at Object.spawnWithSignal (child_process.js:911:17)
at spawn (pkg/prelude/bootstrap.js:2014:27)
at spawn (/snapshot/dist/pnpm.cjs)
at runCmd_ (/snapshot/dist/pnpm.cjs)
at runCmd (/snapshot/dist/pnpm.cjs)
at runPackageLifecycle (/snapshot/dist/pnpm.cjs)
at Array. (/snapshot/dist/pnpm.cjs)
at LOOP (/snapshot/dist/pnpm.cjs) {
errno: -7,
code: 'E2BIG',
syscall: 'spawn'
}

Hi @milimyname,
please, provide your system info by running
npx envinfo --system --binaries
Thanks

System:
OS: macOS 13.1
CPU: (8) arm64 Apple M1
Memory: 1.86 GB / 16.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 18.13.0 - /usr/local/bin/node
Yarn: 1.22.19 - /opt/homebrew/bin/yarn
npm: 9.2.0 - /opt/homebrew/bin/npm

pnpm --version ?

7.27.1

Did you try  with newer pnpm versions like v7.30.3 or the latest v8.1.0?

I did. The same error. I wonder if u can install it to ur project.
Packages: +54 -36
++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------
Progress: resolved 417, reused 373, downloaded 2, added 33, done
node_modules/.pnpm/@indaco+svelte-iconoir@4.1.0/node_modules/@indaco/svelte-iconoir: Running postinstall script...
node:internal/child_process:413
throw errnoException(err, 'spawn');
^
Error: spawn E2BIG
at ChildProcess.spawn (node:internal/child_process:413:11)
at spawn (node:child_process:757:9)
at spawn (/Users/mili.myname/Library/pnpm/global/5/.pnpm/pnpm@8.1.0/node_modules/pnpm/dist/pnpm.cjs:83493:19)
at runCmd_ (/Users/mili.myname/Library/pnpm/global/5/.pnpm/pnpm@8.1.0/node_modules/pnpm/dist/pnpm.cjs:99641:20)
at runCmd (/Users/mili.myname/Library/pnpm/global/5/.pnpm/pnpm@8.1.0/node_modules/pnpm/dist/pnpm.cjs:99582:9)
at runPackageLifecycle (/Users/mili.myname/Library/pnpm/global/5/.pnpm/pnpm@8.1.0/node_modules/pnpm/dist/pnpm.cjs:99549:7)
at Array. (/Users/mili.myname/Library/pnpm/global/5/.pnpm/pnpm@8.1.0/node_modules/pnpm/dist/pnpm.cjs:99022:13)
at LOOP (/Users/mili.myname/Library/pnpm/global/5/.pnpm/pnpm@8.1.0/node_modules/pnpm/dist/pnpm.cjs:99049:18)
at chain (/Users/mili.myname/Library/pnpm/global/5/.pnpm/pnpm@8.1.0/node_modules/pnpm/dist/pnpm.cjs:99056:9)
at lifecycle_ (/Users/mili.myname/Library/pnpm/global/5/.pnpm/pnpm@8.1.0/node_modules/pnpm/dist/pnpm.cjs:99523:7) {
errno: -7,
code: 'E2BIG',
syscall: 'spawn'
}

ok, got it. it seems the problem is with the postinstall script where the package seems to do something wrong. I guess is something related to git...
will try to fix it now. Keep you posted

I'm going to release a fixed version


Claims parameter should be configured as a dictionary

OIDC spec:

claims
    OPTIONAL. This parameter is used to request that specific Claims be returned.
    The value is a JSON object listing the requested Claims.

We can specify this in the config as a yaml dict (to avoid ugly escaped-json-in-a-string) and serialize it into a json string for the request. serde_json::Map or (if must be) serde_json::Value may be appropriate types for this.

Maybe as part of #99 to avoid more breaking changes


Library name change request

Library repository URL
https://github.com/ultiblox/SerialLogger.git

Hi @maker-zone . I am confirming your request.
Unlike submissions, this type of request is still handled manually. The Library Manager index maintainer occasionally comes through to clear all the outstanding requests. They will close this issue when it is done. You will get a notification from GitHub at that time.
After that, you can monitor the indexing of the library via its dedicated logs web page.
Information about that here:
https://github.com/arduino/library-registry/blob/main/FAQ.md#can-i-check-on-library-releases-being-added-to-library-manager

Done:
2024/11/12 14:46:55 Loaded 7466 libraries from DB
Removing UltiBlox SerialLogger
Success!


how to receive the request from XML?Thanks.

I wrote the code：
var Api = new Restivus({
apiPath: 'family/third/',
useDefaultAuth: true,
defaultHeaders: {
'Content-Type': 'application/json'
},
prettyJson: true
});
Api.addRoute('syncUser', {authRequired: false,headers: {
'Content-Type': 'application/xml',
'X-Custom-Header': 'custom value'
}}, {
post: function () {
console.log(this.bodyParams);
return "";
}
})
but this But it prints out "{}".
So I want to ask how to solve.Thanks

Maybe this issue can help you #61


ArcDPS Addon for Blish-HUD stops working after a while.

Appart from not appearing the skill names (The "skill.Name" appears as "Unknown" when displaying it) it works fine, but after a while of playing the addon stops working, but i can still open the addon ArcDPS without any problem.
I tried to deactivate and activate the module again but doesn't seem to work, once it goes down it doesn't come back until i restart the whole game and BlishHUD.
Edit: Small update, it seem it happens when i enter the Shroud with the necromancer. I tested it and played for an hour without using it and it worked fine, just the "Unknown" at the skill names.

Found the Issue and the solution:

Issue:

Found the Issue and the solution:

Issue: Due to the Computer System being in a different language than the game it generates a file with the skills in the computer system language, but the game tries to obtain said names in the game language, an example is:
-  Computer System Language: Spanish
-  Game Language: English
-  File with the skills generated in Spanish
Solution: Uninstall the addon "Scrolling Text" from BlishHUB, change the language of your computer system to the language you are using in game, re-install the addon and it should work now.

@Tharylia worth taking a look when you have a moment.

You don't actually need to change your OS language. It's sufficient to match gw2 and blish language. Maybe delete the skills.json and last_updated file to force a reload


Separate kwargs

Please check if the PR fulfills these requirements

[ ] Tests have been conducted on the PR
[x] Docs have been added / updated

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Changes arguments to key word arguments where there was a mix of names and ids

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
References to the affected Client methods

This pull request introduces 1 alert when merging 017d180837a7963dec1c1aad36c54f4957fc265f into 19805c3b5a818724233583a8b3e5bec3e70623b6 - view on LGTM.com
new alerts:

1 for Unused import

Comment posted by LGTM.com


test(Alu): Fix alu test, demonstrate testing style

So this fixes just the ALU tests, because fixing all the tests will take awhile and it's more important to demonstrate how to do this.
Notable stuff:
nyu::getDUT<>
You need to grab references to a given device using:
#include <NyuTestUtil.hpp>

static void some_test_function() {
   auto& device {nyu::getDUT<VDevice>()};
   // ...
}

The reason for this is because of the way the test runner and the coverage reporter interact. The coverage reporter expects the lifetime of the device to be longer than the surrounding test-case, nyu::getDUT ensures this happens.
nyu::eval()
Similarly, you should be using nyu::eval() instead of device.eval(). This is because when using "tracers" instead of devices, there's no device method to call and you need to use the freestanding nyu::eval() overload. For uniformity (and because it greatly simplifies debugging), always use nyu::eval().
This is actually fixed now and either style works, there's no advantage to nyu::eval() except the consistency with nyu::reset() and nyu::tick() and the case mentioned below.
This has some advantages as well, if you want to call .eval() 5 times, the overload lets you do that directly:
// Before
for(int i=0; i < 5; ++i)
  device.eval();

// After
nyu::eval(device, 5);

Large input space coverage
Most of the tests use random integers where doing so is inappropriate and leads to "random" amounts of coverage being reported which can go up or down a few percent. This is wrong, and should never be the only mechanism to test a device. At the least, each bit of the input space should be tested in isolation so that the coverage is always reported consistently. The ALU tests now demonstrate how to do that, as with the following:
for(std::uint32_t opA {1}; opA; opA <<= 1)
  for(std::uint32_t opB {1}; opB; opB <<= 1)
    run_a_test(opA, opB);

This has been rebased onto #147
The reason is that correctly testing the ALU revealed several bugs in the existing version, notably both SLTs are wrong and instead perform <=, the ARS also worked incorrectly for reasons I didn't decode


Hkg with the Haskell backend

Bits and pieces merged in other PRs, one working HKG proof on haskell backend.


Running out of memory when using hundreds of same Image

Description
I am using react-native-maps to draw about 750 markers on the map.
Each marker is using same Image
Reproduction Steps and Sample Code
const markerImage = <Image source={images.marker} />;
export default class Main extends Component {
  render() {
    return (
      <MapView style={StyleSheet.absoluteFill}>
        { coordinates.map(coordinate => {
              return (
                <Marker
                  key={coordinate.id}
                  coordinate={coordinate}
                  children={markerImage}
                />
              );
            })}
      </MapView>
    )
  }
}

Possible Solution
Re-using UIImage
http://stackoverflow.com/questions/25555778/optimising-custom-marker-image-performance-with-google-maps-sdk-for-ios
However, I do not know how to do this in React Native as React abstracts away the view layer.
Additional Information

React Native version: ["0.41.2"]
react-native-maps: ["^0.13.0"]
Platform: [both]
Development Operating System: [MacOS]
Dev tools: [Xcode: 8.3, iPhone 7(10.3), GalaxyS6(6.0.1)]

this is a stackoverflow question

https://stackoverflow.com/questions/43105313/running-out-of-memory-when-using-hundreds-of-same-image


updated navbar, fix the UI of about section added bit transition effect and fixed the reviews and testimonials section

Changes Made:
Updated the navigation bar for improved usability and design.
Fixed UI issues in the about section.
Added transition effects  in services part
Fixed the reviews and testimonials section.
Created a separate page for feedback.

Thank you @Aradhya-005


Compatibility with v4 api for Users::block and Users::unblock

Changes from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9371.

Thank you for review!


Allow newer versions of gems

We have several clients using our rails application. To not install backup gem on each server we added it to Gemfile (with require: false). But we got a conflict with virtus gem. Virtus depends on axiom-types and axiom-types requires thread_safe to be >= 0.3.1, ~> 0.3 while backup requires thread_safe to be exactly 0.1.3.

I'm building a docker image for Postgres which contains some ruby dependencies for management. sequel_pg in particular depends on activesupport which depends on thread_safe. Having a Gemfile with all my gem dependencies in it for management including backup would make my code more clear and maintainable. Is there any chance you would relax/update the thread_safe dependency? Thanks!

Hi @arnau I just answered this in another issue, so I will redirect you there: https://github.com/meskyanichi/backup/pull/620#issuecomment-68524048
Short story: We're not going to update gems or make the version locks any less strict than it is now, if there's no really good reason to do so.

Ok, sounds reasonable. Thanks, it's a great gem anyway.


feat: support custom fallback group for wildcards in group_imports

To support custom fallback positions, we store the config ["*"] as a Fallback variant of the (now) enum WildcardGroup.
In the matches fn, if we have a Fallback variant, we always return false.
After that, in group_imports_custom, we get the position of enum in the WildcardGroups vec which is of the variant Fallback or use groups.len() - 1 as default (unchanged).

Thanks!


Should we split up JSON/CBOR into separate formats/specs?

I have the feeling that it's not the best idea to have the JSON and CBOR variants merged into a single specification and under the same name. It not only creates confusion but also bloats it up unnecessarily. Any opinions?

This would also make it easier to release CoverageJSON more quickly, and let CoverageCBOR (?) follow if there is a need for it and we've proven that it actually performs better in certain situations (see #41).

If you think it's better to separate them then this is fine with me, particularly since the real-world benefits of CBOR are not entirely clear yet. But how much difference do you think there will be between the versions? Would they not be very similar, apart from some differences in array encoding?

They would be very similar yes, and I wouldn't copy-paste everything, just describe the differences, which are currently: structural+data type (range encoding, e.g. offset/factor), or just data type (typed array encoding in domain without change of structure).

So the main changes are in the range, and perhaps in the domain (e.g. curvilinear grids that benefit from a more efficient encoding of coordinate values)?
Do you think we could restrict this just to the range values? This would simplify and isolate the changes. It's not clear to me that the domain encoding will benefit greatly from CBOR.

Another example would be if the domain contains big explicit numeric axes, like rectilinear ones. Also, the bounds currently have to be given explicitly if they are given (no regular encoding).
One of the requirements of a CoverageCBOR format would be that arrays can be encoded as typed arrays (an extension of CBOR not widely supported yet). With this requirement, I don't see a reason why the use of typed arrays should be restricted to a particular area. The only one I can think of is that typed arrays in JS don't have all the functions of normal arrays yet and browser support varies, and this could lead to subtle bugs/exceptions. That's probably a good reason for restriction though... OK, I agree, since the main savings can be made in the range data, we should focus on that first.

Yes, although we could benefit from some efficiency in encoding the domain, I feel that these benefits would probably be quite marginal (even for bounds, these are only 1D axes). The largest "domain" objects are likely to be the curvilinear coordinates, but we are deferring this for now. I would suggest that we focus on the range encoding, where the range is encoded in a separate document.

Why do you say "in a separate document"? I don't think we should
differentiate whether it's embedded or not.
Am 28.01.2016 um 09:16 schrieb Jon Blower:

Yes, although we could benefit from some efficiency in encoding the
domain, I feel that these benefits would probably be quite marginal
(even for bounds, these are only 1D axes). The largest "domain"
objects are likely to be the curvilinear coordinates, but we are
deferring this for now. I would suggest that we focus on the range
encoding, where the range is encoded in a separate document.
—
Reply to this email directly or view it on GitHub
https://github.com/Reading-eScience-Centre/coveragejson/issues/44#issuecomment-176077479.

Maybe I haven't understood CBOR properly, but I thought that a document would either be encoded entirely in text-JSON or binary-JSON. So a text-JSON document could hold the domain, parameters etc but contain a link to a binary-JSON document holding the range. I didn't think it was possible to embed a binary-JSON object in a text-JSON document but I may be wrong.

No you're right. But sometimes it makes sense to have the complete
coverage including domain in a single document, which can also be at the
discretion of the server because it may have a rule to include small
ranges directly to save the client from launching another request.
The more important thing here though is that you mention mixing JSON and
CBOR. Although that's possible, I think if JSON is offered, then any
links to ranges must also be offered in at least JSON. Whether a CBOR
document is accessible at the same URL via content-negotiation doesn't
matter. And I think this is a crucial discussion point when splitting it
into two formats (JSON and CBOR) since they should be independent from
each other in my opinion.
Am 28.01.2016 um 09:24 schrieb Jon Blower:

Maybe I haven't understood CBOR properly, but I thought that a
document would either be encoded entirely in text-JSON or binary-JSON.
So a text-JSON document could hold the domain, parameters etc but
contain a link to a binary-JSON document holding the range. I didn't
think it was possible to embed a binary-JSON object in a text-JSON
document but I may be wrong.
—
Reply to this email directly or view it on GitHub
https://github.com/Reading-eScience-Centre/coveragejson/issues/44#issuecomment-176079893.

Right - but if the ranges are small and it makes sense to encode the whole coverage in a single document, then there's no real need for CBOR, right? I would think the most useful cases are:

Whole coverage offered as text-JSON document
Coverage (without ranges) offered as text-JSON, links to range objects also offered as text-JSON
Coverage (without ranges) offered as text-JSON, links to range objects offered as CBOR

As you say, conneg can distinguish between 2 and 3. I don't think it's particularly useful to offer a whole coverage as CBOR, although it would be possible of course.

Sure, if the coverages are small, then there's no reason that the data
provider offers CBOR at all.
Hm... I went back and forth while writing this comment, not that
straight forward actually. There are different things to consider.

What I don't want is a dependency to CBOR in the CoverageJSON spec,
since this would mean that clients are forced to support CBOR at a minimum.
Clients should be able to know whether they can load the full
coverage before trying to actually load e.g. the range.

Possible solutions:
A) The easy way would be to force JSON throughout if the media type is
application/prs.coverage+json, including ranges. And the same for CBOR.
Then each format is independent, the client knows what to expect, and
there can be implementations focused on each individually.
B) CoverageJSON does not restrict the range at a referenced URL to any
particular format, but instead a mapping from media type to URL has to
be explicitly included so that the client can explicitly select between
formats. This would allow custom multi-dimensional array encodings, e.g.
if the range is a 2D categorical grid with less than 256 categories, you
could use a monochrome PNG where alpha=nodata (and this would then need
a custom media type and not just image/png).
Option B would mean a restructuring of how ranges are linked. On the
upside it may be more compliant to the JSON vision of the OGC, but I
haven't fully understand that yet. For example, what WCS's
DescribeCoverage is supposed to return, and if this is identical to the
first part of a multipart GetCoverage request. And whether
DescribeCoverage includes links to the range (I think not, which may be
a problem).
On 28/01/2016 09:48, Jon Blower wrote:

Right - but if the ranges are small and it makes sense to encode the
whole coverage in a single document, then there's no real need for
CBOR, right? I would think the most useful cases are:

Whole coverage offered as text-JSON document
Coverage (without ranges) offered as text-JSON, links to range
objects also offered as text-JSON
Coverage (without ranges) offered as text-JSON, links to range
objects offered as CBOR

As you say, conneg can distinguish between 2 and 3. I don't think it's
particularly useful to offer a whole coverage as CBOR, although it
would be possible of course.
—
Reply to this email directly or view it on GitHub
https://github.com/Reading-eScience-Centre/coveragejson/issues/44#issuecomment-176091120.

I don't think we need a dependency on CBOR in the CovJSON spec. We could say that offering all data as text-JSON is the minimum that all servers should offer. Offering range data as other formats is optional.
So, how does a provider advertise the formats that ranges can be served in? I guess your Option B is the solution - if we use conneg then a client would have to interrogate the range endpoint(s) to find the supported formats.
There's a potential issue (also faced by WCS and other related things) that some formats naturally encode more than the range. A NetCDF file, for instance, encodes the whole coverage. We could:

Allow full-coverage formats like NetCDF or HDF to be range formats, noting that any domain encoded in the file must be consistent with the one advertised in the CoverageJSON document; or
Disallow this, allowing only formats that encode only the range (e.g. JSON, CBOR, PNG, plain binary, custom XML...). Clearly the ordering of data values in the file should match the rangeAxisOrder advertised.

We could even consider restricting the range encoding to a fixed list, for which we can easily specify the behaviour. (e.g. a PNG file might not make sense for the range of a timeseries coverage, but CBOR or JSON would always work).
Maybe the range formats need to be inherently 1D?

Some more thoughts on WCS / OGC model:
A GeoTIFF can be used as rangeset in WCS, where channel order is defined by the order of the rangeType elements (our parameters). This is currently incompatible with CoverageJSON for two reasons:

We don't allow to link to a complete range set, but only to a single range (=parameter).
Even if we would allow to link to a range set, we don't define any parameter ordering currently.

So, just saying, if CoverageJSON should maybe become the JSON serialization for DescribeCoverage and the first part of a multi-part GetCoverage, then those things have to be addressed.

Good point. Is it a big task to enable multi-parameter ranges in CovJSON?

Well, first we would have to include some kind of optional "order": 0 (1, 2..) property within a parameter if one of the offered range formats depends on the order. Then we would have to add a new root level CovJSON document type "RangeSet". And the reason I didn't want the latter initially is that you then have random local keys (the parameter keys) in your "standalone" document that don't have any meaning by themselves. But thinking about it... it's just what it is, a collection of arrays indexed by some keys without meaning.
A harder issue is at what level you are describing the different range formats. In WCS, it's at the rangeset level. So we would not describe formats for individual ranges, but for the whole set of ranges. Let's write some JSON to make it more concrete:
"ranges": {
  "application/netcdf": "http://.../data.nc",
  "application/prs.coverage+json": {
    "temperature": "http://../temp.covjson" // or directly embedded
  },
  "application/prs.coverage+cbor": {
    "temperature": "http://../temp.covcbor"
  }
}

I guess for netCDF ranges, the parameter key would also have to match the variable name.

Fixed some of the JSON, should be ok now. If the media type is a JSON variant, then it can be embedded, otherwise just a URL.

But there is still a problem with this. The structure above would not allow to load a single CBOR range without first loading the rangeset, when starting from a CovJSON coverage document.

And you're right about the issue that some formats encode more than the range. If you do a WCS GetCoverage with format CovCBOR, you would expect the complete coverage with domain and parameters right? And probably just a single rangeset of type CovCBOR? However, for DescribeCoverage, you would get a CovJSON document, and I'm not sure if this should contain the rangeSets structure above, and if it did, then from a WCS point of view, a range set is what you get with GetCoverage, so this would point to a full CovCBOR coverage and not just the rangeset. And then we're getting into a loop.

I think we have been looking at it from a slightly wrong angle.
All the coverage formats that I know do not allow linking to remote parts. They are standalone and have a certain degree of domain and parameter metadata. Which means there is also no mix of formats within one format. CoverageJSON is more flexible and does allow linking to remote ranges. In addition to that, we now wanted to introduce even more flexibility by allowing different formats for the remote ranges.
To put that into perspective, let's get back to WCS's DescribeCoverage. This is really just a description of the coverage domain, the parameters, and the available coverage formats. It does not have actual links to concrete formats of the coverage, which makes sense for WCS as it has a fixed query API. And especially, it does not have links to range sets for a given format.
I think we cannot use CovJSON as-is for DescribeCoverage, without changing WCS itself. However, we could derive a coverage description format based on CovJSON, which basically just includes the domain and parameters and in addition information about the available formats. It would not have "type": "Coverage" but "type": "CoverageDescription". Even though it is not directly CovJSON, reusing elements of it would provide some consistency if CovJSON would become an actual WCS coverage format.
I think the WCS model makes sense from a semantic point of view. DescribeCoverage is just a format-independent abstract coverage description. And the coverage formats offered in it and retrievable with GetCoverage are coverages, not just range sets. So it makes sense to serve netCDF-CF, GeoTIFF etc. instead of TIFF without geo-referencing data.
Coming back to CovJSON, I think it would be wrong to serve a coverage format as a range set, such as a netCDF-CF file. Why? Because it would mean that we allow coverage formats and then we could link to a CovJSON coverage, which obviously would not make sense. So, you are right above that this should be disallowed and only actual range formats (like a CovJSON range document) can be linked to. I see the issue though, do you just strip metadata from a netCDF file or make the range variable one-dimensional? I think the main problem is that range-only formats are not defined, and WCS gets around that by not working on that level. OPeNDAP4 may be suitable as a range-only format.
Remote range sets with WCS (e.g. linked from a CovJSON coverage) are possible in theory but I'm not sure how much sense that makes, since you would need a separate server that serves those ranges and that's not really realistic for common WCS setups. That in turn would mean that range sets have to be embedded within the coverage, and for CovJSON this would mean a CovJSON range set and nothing else (no other formats). That could be a WCS-specific restriction/profile for CovJSON.
There is a big exception to all this which is the WCS multipart encoding, where the GetCoverage response would consist of a GML-encoded coverage where the range set contains an internal link to the second multipart part which is the range set. And that rangeset part is in a rangeset-only format, e.g. a plain tiff. And this is what Joan probably had in mind somehow when creating his first draft of CovJSON with the URLs for the ranges. However, since WCS specifically restricts this to exactly 2 parts (coverage without rangeset + rangeset) I don't know how you would be able to link to specific range files. I think the multipart encoding of WCS/GML would have to be extended to make that work.
Even though we won't use multipart in our projects, it looks like CovJSON is compatible to it (after introducing "RangeSet" as a root level document). The idea would be to have (next to GML) a CovJSON coverage encoding for the first part of a multipart, which then links to the other multipart part which is a CovJSON range set, and it would be important that this is not restricted to CovJSON range sets, but any format. So this is one more factor to consider when thinking about the "rangeSet" JSON structure.
WCS would only allow a single range set format in a response, a typical URL would look like ?request=GetCoverage&mediaType=multipart/related&format=image/tiff where if the mediaType parameter exists, it must be multipart/related (and this currently forces a GML encoding for the coverage) and the format determines the range set format. To support JSON, something would have to be changed to indicate that you want JSON and not GML. But that's another issue.
Conclusions...

Allowing arbitrary range set formats in a CovJSON coverage seems to be necessary to be most compatible to WCS.
A CovJSON "standalone" profile would have to be defined where there is only a single embedded range set in the form of a CovJSON rangeset, and this would be what you get with a non-multipart request=GetCoverage&format=application/prs.coverage+json request.
Having a DescribeCoverage JSON format is on the agenda of OGC, so it would make sense to align that if possible with CovJSON structures, in some derived covjson coverage description format (not sure you can still call it covjson then).
Linking to individual ranges of a range set within a CovJSON coverage document does not make sense (I think) within WCS but that doesn't matter and it is relevent for our own use cases and possibly other APIs. So this flexibility should stay. We should ask Joan about that point since he included this functionality in his JSON format as well, but I can't see the relation to OGC/WCS.

Remaining problems:

As mentioned in an earlier comment, (and this is unrelated to OGC/WCS support), in CovJSON we cannot yet link to specific ranges in a non-JSON format, assuming the proposed "rangeSet" structure. I think the issue here is that making this possible would require to define yet another type of format, next to coverage and range set formats, which are range formats. We have that in CovJSON/CovCBOR, but range formats as such are not defined/mentioned in OGC world.
Probably other things not conforming to the coverage model of OGC, like having a single CRS for the whole domain.

Thanks, this is interesting. Regarding multipart WCS responses, I'm not sure this has been fully thought through in WCS yet. There have been attempts at allowing NetCDF and OPeNDAP as range formats, but these suffer from the above problem that they are really coverage formats.
My points/questions would be:

Should we promote CovJSON-without-ranges as a DescribeCoverage format? I think it might make sense to do so, provided that we can completely replicate a DescribeCoverage document in CovJSON -I'm not sure this is the case at the moment: we would probably have to work out how to serialise all the possible GML options that DescribeCoverage allows, which might be more than we want to do. The CRS issue is problematic here - I personally don't think it's a good idea to have exactly one CRS for a coverage, because it's clearer if the different CRSs (xy, z and t) are separated.

In either case, I think we agree that we can see CovJSON as a bona fide coverage format (and a valid output of a WCS), and the rangeset should just contain ranges (not full coverages). Because CovJSON is "our" format we can choose whether or not to allow single ranges or multiple ranges in the same rangeset document (I think we should allow both, noting that if CovJSON is used as a DescribeCoverage response we need to support a single multivariate rangeset document).

The multipart thing is interesting in terms of range format support. I can see that it might be advantageous to restrict the number of range formats to a set of formats that makes sense and can be well defined (e.g. JSON, CBOR, even plain binary if we define it). If we allow any range format then how do we advertise this to clients? CovJSON would be advertised as the WCS output format, but I don't know if there is a way to advertise the possible formats of a multipart response?

I don't understand the second sentence of point 2: "to allow single ranges or multiple ranges in the same rangeset document". Do you mean multiple formats of the same range? Because a rangeset can have multiple ranges anyway (in the same format). Also, how is this connected to DescribeCoverage? DescribeCoverage does not link to a range set, it just lists the available coverage formats without any links.
To point 3, no idea, I just checked WCS 2.0 and couldn't even find how formats at all are listed for a coverage. It only mentions a native format in that structure within DescribeCoverage:
<wcs:ServiceParameters>
  <wcs:CoverageSubtype>GridCoverage</wcs:CoverageSubtype>
  <wcs:nativeFormat>image/tiff</wcs: nativeFormat>
</wcs:ServiceParameters>

Later it says:

The encoding format in which the coverage will be returned is specified by the combination of format and mediaType parameter. Admissible values (i.e, formats supported) are those listed in the server’s Capabilities document. Default is the coverage’s Native Format.

So that means whatever coverages you offer within one WCS endpoint must be offered in all formats you list in the GetCapabilities document, and you would have to read that document to know them. So I guess I was wrong partly, maybe the formats got listed in WCS 1.x, since I saw that in examples around the web.
A WCS 2 GetCapabilities response has this:
<wcs:ServiceMetadata>
 <wcs:formatSupported>image/tiff</wcs:formatSupported>
</wcs:ServiceMetadata>

There doesn't seem to be any distinction between coverage and range set formats. I then would agree that the multipart thing is not fully thought through.
I think this is just too much pain to handle for us. I would say...

Let's ignore multipart completely, nobody's going to use it anyway.
If someone asks, we can help with the JSON version of DescribeCoverage, but it's not a priority for us.
Let's focus on making CovJSON a WCS output format.
What we do with ranges, range sets, formats within CovJSON shouldn't matter for WCS. It's just a degree of flexibility within the format and we can decide how flexible we want to make it.

So let's get back to the example:
"rangeSet": {
  "application/netcdf": "http://.../data.nc",
  "application/prs.coverage+json": {
    "type": "RangeSet",
    "temperature": "http://../temp.covjson" // or directly embedded
  },
  "application/prs.coverage+cbor": "http://../rangeset.covcbor"
}

To solve the issue that you want to have access to single ranges for non-JSON formats, let's change what is allowed as value of a media type property and add an explicit "ranges" property to separate the keys more:
"rangeSet": {
  "application/netcdf": "http://.../data.nc",
  "application/prs.coverage+json": {
    "type": "RangeSet",
    "ranges": {
      "temperature": "http://../temp.covjson" // or directly embedded
    }
  },
  "application/prs.coverage+cbor": {
    "type": "RangeSet",
    "ranges": {
      "temperature": "http://../temp.covcbor" // cannot be embedded
    }
  }
}

Everything under a given media type must be in that format, no mixing. Also, note that when you decide to expose individual ranges (as for CovJSON and CovCBOR above) then you can't give a URL for the complete range set. If there is a need for that we can still add that later, but I think it's not necessary since it would just be because of an optimization of the number of server requests, and with HTTP/2 (see also SPDY) this problem doesn't exist anymore anyway.
And you're right, for this to work we would have to define how a range set and range looks like in existing formats like netcdf, image formats etc.
You mentioned an approach of a video encoding as range set format where you had I think tiles inside the video. For those kinds of advanced encodings you would need additional information about the layout that is not embedded and that we couldn't define statically once for such a format (which would just be video/mp4). Where would those parameters go? That is important when defining the above JSON structure.

I agree with your proposals (starting "I would say..." above). I also think we should remove CBOR from the CovJSON spec for now, and maybe allude to an "unsolved issue" around supported range formats.
I'm not sure whether using the MIME type as a key in the rangeSet is a good idea. It's quite an awkward string to use as a key and contains full stops, making it not suitable as a key in a JavaScript hashmap. Maybe it should look like this, at the expense of an extra parameter:
"rangeSet": {
  "netcdf": {    // arbitrary string, intended for easy reading in code
    "type": "RangeSet",
    "mimeType": "application/netcdf",
    "location": "http://.../data.nc"
  }, {
  ...
  }
}

or the list of formats could be an array?

I removed CBOR from the spec now and copied relevant parts into cbor.md.
Honestly, I don't see the point of having an arbitrary string as key there just so that one can write rangeSet.netcdf instead of rangeSet['application/netcdf']. The local key made sense for parameters since this is reused for associating a range. If your client is moderately clever then there will be an abstraction layer anyway around the range fetching which would pick the most suitable format automatically. Of course it doesn't help that we don't have a registered media type yet. Maybe we should do that first? Should be quite easy in the prs. tree.

Some more WCS details:
For GeoTIFF, the WCS encoding profile adds several query parameters for GetCoverage that influence how the TIFF is encoded (e.g. compression, jpeg quality (if compression=jpeg), and tiling). This is again at the coverage level. But since we may want to support alternative range set formats, this is relevant here as well. A typical use case would be that the clients first fetches a low-quality jpeg-encoded tiff file, and then on demand fetches the non-lossy variant.
So are we really targeting such use cases at the range set level? One problem I can see is that when you link to a coverage (via URI) as being an input to an operation like intercomparison (e.g. for provenance purposes), then you couldn't link to a specific range set encoding, but this is relevant in the case of lossy encodings, and in some cases a high-quality lossy encoding may be enough for a certain operation, but you still want to know that. On the other hand, a coverage URI should represent the coverage itself, meaning the domain, parameters, range values independent of format. So I would say that a lossy version of that is in effect a different logical coverage, derived from the original one, with a different URI. And this view conflicts a bit with just putting random formats into the range set construct. And this is equal to allowing CBOR with an offset/factor encoding (if this is lossy).
Not sure yet how to solve this.

How about we go back to the roots here...
Originally, we allowed a full coverage to be encoded as CBOR, not just the ranges. Why not do that? I see absolutely no problem in having the domain and parameters in CBOR as well, it is just another self-describing coverage format. From an implementation perspective, there is nearly no difference, since json = CBOR.decode(cbor) more or less. The problem of how to advertise different coverage formats is best handled at the HTTP level: Link headers, as in:
GET /cov
Accept: text/html, */*

HTTP/1.1 303 See Other
Location: /cov.html

GET /cov.html
Accept: text/html, */*

Content-type: text/html
Link: </cov.covjson>; rel="alternate"; type="application/prs.coverage+json"
Link: </cov.nc>; rel="alternate"; type="application/netcdf"

<html>..</html>

Similarly when you start with Accept: application/prs.coverage+json you would get the Link headers pointing to alternative coverage formats.
And I would really separate lossy from non-lossy versions here. The lossy version has to be linked somehow from the non-lossy version but it does not represent the same data.
Doing it like that would eliminate many pain points we are seeing. We could simply reuse OGC definitions of coverage formats and don't have to worry about defining our own range set formats (apart within json of course).

Just in case we choose the flexible range formats variant, another suggestion, inspired by the Link type of ActivityStreams:
"rangeSet": [{
  "type": "RangeSet",
  "mediaType": "application/netcdf",
  // either or both "href" or "ranges" is required
  "href": "http://.../data.nc",
  "ranges": {
     "temperature": "http://../temp.nc",
     "wind_speed": "http://../wind.nc"
  }
}, {
  // fully embedded CovJSON
  "type": "RangeSet",
  "mediaType": "application/prs.coverage+json",
  "ranges": {
     "temperature":  { ... }, // can also be linked with URL
     "wind_speed": { ... }
  }
}, {
  // external covcbor without href
  "type": "RangeSet",
  "mediaType": "application/prs.coverage+cbor",
  // could also have "href" but is not offered, just single ranges:
  "ranges": {
     "temperature": "http://../temp.covcbor",
     "wind_speed": "http://../wind.covcbor"
  }
}]

So, a RangeSet then is a special type of Link that allows to embed range data or link to specific ranges in a range set.
For each media type we'd have to define the specific encoding (like WCS format encoding profiles).

Looks promising. An application might like an easy way to distinguish between fully-embedded CovJSON and ranges that are linked via URL. I guess they could do a test on cov.rangeSet[i].ranges.temperature to see if this is a string or an object, but that feels a bit hacky.
Also, could the rangeSet be an object (keyed by some semi-human-readable strings) rather than an array?

Some more reflections...

I had application/netcdf as a format for range sets in the examples, but this is not going to happen anyway in browsers, so we should not consider this case. It's not a "download" format also, since then you would want the complete coverage, not just the range set.
Testing against string vs object is not a problem and not hacky at all, it's common practice, see e.g. here. JSON-LD also does the same.
I still feel that introducing range set format flexibility makes it too complex for the 99% case. And also for us since we have to define what a range set format is, which doesn't exist yet. Also, non-JSON formats will always be second-class citizens in that case since they cannot be embedded, making a second network roundtrip necessary. This would not be the case with something like CovCBOR. I think we have to ask ourselves: do we really need it? Do we really want to encode ranges as JPEG for example? Since JPEG is 2D, this would only apply to a small amount of domains. So are we restricting it to cube-supporting formats? Which ones are these? I can't think of any webby ones, except our variant of CBOR.

OK, I agree. I don't think we want to encode ranges as NetCDF or JPEG, or things like that. And I don't think we need range set format flexibility now - maybe we'll find it's useful later, but I agree that it introduces too many complexities.
So are we saying that a CovJSON document (and ranges that are linked from it) must be entirely text-JSON or CBOR, but no mixes? I.e. we couldn't link a CBOR range from a text-JSON document? I think that's OK.
Or we could say that the URL in a linked range will always return the same format as the original document. The server may implement content negotiation to return a different format (e.g. CBOR), but that's for the client to negotiate.

So are we saying that a CovJSON document (and ranges that are linked
from it) must be entirely text-JSON or CBOR, but no mixes? I.e. we
couldn't link a CBOR range from a text-JSON document? I think that's OK.

I would say so, yes. More precisely, you have to link to a resource
which offers a CovJSON representation. Other resource representations
(e.g. HTML, or CovCBOR) may be offered as well at the given URL, but
these are explicitly ignored by the CovJSON spec. If we define a
separate format based on CovJSON called CovCBOR, then this would
similarly say that the linked range resource has to offer a CovCBOR
representation. Whether and how exactly those two formats are mixed via
content negotiation I think is out of scope here. But since it is
actually easy to support once conneg is available in the server I
wouldn't worry too much. The main thing is: If you start with JSON, you
are guaranteed to get JSON. Even if we just define CBOR for the ranges
themselves (I'm not in favour of that), then effectively we require
conneg (since there's just a single range URL) if people want to use
that from CovJSON in addition (because their clients are smarter and
know CBOR), and I think that's fine. So... let's stop worrying, and
close this... I don't think we're blocking any roads here in the future,
there's enough ways for extension.
Resolution:

JSON/CBOR split up: yes
built-in non-HTTP range format negotiation: no

Ok?

Yes, agreed.


buf-breaking-action issue with subdirectory option

Hi there 👋
I've just added github actions for automated protobuf checks for PRs in a private repository (sorry cannot share).
Here is the hierarchy of the repo:
$ tree
.
└── proto
    ├── service
    │   └── v1
    │        └── service.proto
    └── buf.yaml

And this is my protobuf github action yaml file:
name: protobuf-checks
on: pull_request
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: bufbuild/buf-setup-action@v1
      - uses: bufbuild/buf-lint-action@v1
        with:
          input: "proto"
      - uses: bufbuild/buf-breaking-action@v1
        with:
          input: "proto"
          against: "https://github.com/${GITHUB_REPOSITORY}.git#branch=master,ref=HEAD~1,subdir=proto"

And here goes the github actions error logs:
Run bufbuild/buf-breaking-action@v1
  with:
    input: proto
    against: https://github.com/${GITHUB_REPOSITORY}.git#branch=master,ref=HEAD~1,subdir=proto
    buf_input_https_username: ...
    buf_input_https_password: ***
Failure: no .proto target files found
Error: Failure: no .proto target files found

Not 100% sure I didn't miss anything so sorry in advance if its the case.

Ok my bad here ... missed the ref=HEAD~1
No issue at all


Note that FloatField must be finite

This patch to docs addresses https://code.djangoproject.com/ticket/34260#ticket in dev-version documentation.
I wasn't clear how backports to older versions worked. I'm happy to open PRs against the stable/* branches if that's easiest, or perhaps you have some other process. This change can go back to all supported Django versions.

Closing per comment.


New and improved version of the website

New and improved version of the TUF website, based on the Docsy Hugo theme, which will allow for easier maintenance and growth of the website.
Initial work by LFX Term 2 TUF project mentee  @Dindihub, who also completed the TUF Documentation Analysis for the CNCF techdocs team. Thank you Sandra, and well done! 🙌🏻 ✨
Website migration completed by myself (@chalin)
Contributes to #85
All content from the existing website has a home in this new version of the website.
Feedback by TUF approvers is welcome.

Preview: https://deploy-preview-105--theupdateframework.netlify.app/

Looks nice.
On content/en/spec.md:

is the idea that spec maintainers should update this page too when they make a specification release? This feels like unnecessary process. I would suggest replacing the list with:

Large button to current TUF specification
A bit of additional info like: "Specification is maintained at https://github.com/theupdateframework/specification/, full  list  of releases is available in ..."

Currently the link for list of releases /specification/list/ is broken: should be /specification/

Also header for the "spec" tab seems wrong --  it's got a large image  that looks a bit placeholdery
Compare partial screenshot from docs and spec tab:

Approved by @JustinCappos et al.: see Slack #tuf thread, and a Slack message to @lukpueh and myself. Merging now.
@jku - thanks for your comments. I'll open issue(s) to track those and address them separately.
All: here's a link to the current version of the website. We can keep this around for reference for a little while, for those times where we wonder "how was it before" :) -- https://pre-lfx-2024--theupdateframework.netlify.app

Yes, this also looks great.   I approve!
On Sat, Oct 12, 2024 at 1:10 PM Patrice Chalin @.***>
wrote:

@.**** commented on this pull request.
In netlify.toml
https://github.com/theupdateframework/theupdateframework.io/pull/105#discussion_r1797733953
:

[[headers]]
for = "/*"
[headers.values]

Content-Security-Policy = "default-src 'self' code.jquery.com fonts.googleapis.com fonts.gstatic.com use.fontawesome.com app.netlify.com netlify-cdp-loader.netlify.app youtube.com; frame-src youtube.com www.youtube.com"

Content-Security-Policy = "default-src 'self' code.jquery.com fonts.googleapis.com fonts.gstatic.com cse.google.com www.google.com use.fontawesome.com app.netlify.com netlify-cdp-loader.netlify.app youtube.com; frame-src youtube.com www.youtube.com"

@JustinCappos https://github.com/JustinCappos et al.: I wanted to
highlight this addition to the CSP, i.e., two google.com sites, which I
added while experimenting with custom Google search for the website (#91
https://github.com/theupdateframework/theupdateframework.io/issues/91).
Please confirm that you are ok with this addition, otherwise I'll roll it
back.
—
Reply to this email directly, view it on GitHub
https://github.com/theupdateframework/theupdateframework.io/pull/105#pullrequestreview-2364053443,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGROD6QRJRUCDP4RMK4QFDZ3FJXFAVCNFSM6AAAAABPTHRYFSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGNRUGA2TGNBUGM
.
You are receiving this because you were mentioned.Message ID:
<theupdateframework/theupdateframework.io/pull/105/review/2364053443@
github.com>

@jku - I created the following issue to track your comments:

#107


Ensure non-blocking process wait and correctly report process exit status

Waiting or a process to finish was potentially blocking both on windows and posix systems. It was only ever called when the child process was killed beforehand or has closed both stdout and stderr, so the actual risk to block was low, but still. Now it calls waitpid (and the windows equivalent) with WNOHANG (on windows with timeout of 0) to ensure it does not block. If the process is still running at that point, a timer is scheduled to poll the process using the non-blocking waitpid.
During testing I discovered that processes terminated by signals were usually reported as exited with exit-code 0, which is wrong. I changed the ProcessNotify.dispose signature to receive a Signaled or Exited class containing signal number or exit code.
This works pretty well, the only case this does not catch is, when a process exits and sets an exit-code in a signal handler. ProcessNotify.dispose will be called with Signaled, not with Exited and the exit code is basically lost. But I still prefer this.
As this is a breaking change, I thought to keep it as draft at first, in order to discuss it.
I would consider the non-blocking waitpid call as internal and the improved exit status reporting as actually fixing a bug, that is why I didn't create an RFC for this.

This still needs to be tested on windows, CI doesnt run the process tests on windows.

Ok, here we go! Tests run fine on windows! :tada:

@cquinn can you take a look at this?

@SeanTAllen all good to go from my side. How about you?

@mfelsche 0.34.1 has been released. you can merge this whenever. can you add the release notes to the 0.34.2 issue?

@mfelsche don't forget to SQUASH when you merge this! ;)
I forget sometimes, thought I would remind you just in case.

Thanks, much appreciated!


visualize the object detection bbox

Hello, your model is very helpful to me, but now there is a problem, that is, the detectron2 image segmentation model, the visualization result is only masked, how to generate the object detection bbox

Hello, thank you for your reply. I'm just getting started and don't know much about the program. Can I just call this function to realize the visualization of the detection box


Pace Purification returns a vertical velocity when used on a nonmoving item

Version: 0.10.3 Fabric

I had a cyclic wisp reveal the item's velocity once per tick. This was the output, repeating infinitely:
(0.00, -0.00, 0.00)
(0.00, -0.04, 0.00)
(0.00, -0.08, 0.00)
(0.00, -0.12, 0.00)

This is probably just Mojank, but it's still weird, so we should check and see if it's still an issue on the latest 1.20.1 prereleases.

hexcasting-forge-1.20.1-0.11.1-7-pre-609 AND hexcasting-fabric-1.20.1-0.11.1-7-pre-609

Yeah, this still happens; this is probably the funniest bug I've seen
I just made a hex that reveals Scout's Distillation and got the similar results


PathPrefixStrip Is not working as intended

Given the follow compose file
  apiv1:
    image: wouterla/whoami
    networks:
    - proxy
    environment:
      - WHOAMIserviceName=apiv1
    deploy:
      replicas: 2
      labels:
      - traefik.frontend.rule=PathPrefixStrip:/api/v1
      - traefik.priority = 1
      - traefik.docker.network=proxy
      - traefik.port=8000
      - traefik.enable=true
  apiv2:
    image: wouterla/whoami
    networks:
    - proxy
    environment:
      - WHOAMIserviceName=apiv2
    deploy:
      replicas: 2
      labels:
      - traefik.frontend.rule=PathPrefixStrip:/api/v2;/api
      - traefik.priority = 2
      - traefik.docker.network=proxy
      - traefik.port=8000
      - traefik.enable=true

Expected

/api and /api/v2 hits apiv2 backend
/api/v1 hits the apiv1 backend

Actual

/api returns 404
/api/v2 hits apiv2 backend
/api/v1 hits apiv1 backend

I also tried
traefik.frontend.rule=PathPrefixStrip:/api/v2,/api
But this resolves all routes to apiv2
Thanks in advance

Hello @ray-matos-mpf .
Many thanks for your interest in the project.
Can you send us the version of Træfik you use?
Thanks in advance.

Hello @ray-matos-mpf ,
We analyzed deeply your issue and it appears it contains mistakes which explain why it does not work as expected.

The labels traefik.priority have to be renamed into traefik.frontend.priority,
The spaces in the right part of the labels traefik.frontend.priority have to be removed
The ; in the second rule has to be replaced by a ,
The priority are not specified correctly, you can refer to the documentation for more details.

The configuration described below contains all the modification and works well :
  apiv1:
    image: wouterla/whoami
    networks:
    - proxy
    environment:
      - WHOAMIserviceName=apiv1
    deploy:
      replicas: 2
      labels:
      - traefik.frontend.rule=PathPrefixStrip:/api/v1
      - traefik.frontend.priority=5
      - traefik.docker.network=proxy
      - traefik.port=8000
      - traefik.enable=true
  apiv2:
    image: wouterla/whoami
    networks:
    - proxy
    environment:
      - WHOAMIserviceName=apiv2
    deploy:
      replicas: 2
      labels:
      - traefik.frontend.rule=PathPrefixStrip:/api/v2,/api
      - traefik.frontend.priority=1
      - traefik.docker.network=proxy
      - traefik.port=8000
      - traefik.enable=true

The documentation about priorities will be improved in a Pull Request to propose configuration like yours.

Documentation fixed in #2984.
Thanks @jbdoumenjou.
I close the issue


[BUG] System Center Virtual Machine Manager Inventory Items List API cannot immediately return a list of Inventory Items after System Center Virtual Machine Manager Server is created

API Spec link
https://github.com/Azure/azure-rest-api-specs/blob/cf5ad1932d00c7d15497705ad6b71171d3d68b1e/specification/scvmm/resource-manager/Microsoft.ScVmm/stable/2023-10-07/scvmm.json#L1986
API Spec version
2023-10-07
Describe the bug
After tested, I found Inventory Items List API wouldn't immediately return a list of inventory items after SCVMM Server is created. But I can get the list after SCVMM Server is created and then wait for a while like 1 minute. Seems it's a bug. Please fix it asap. Thanks.
Expected behavior
System Center Virtual Machine Manager Inventory Items List API can immediately return a list of Inventory Items after System Center Virtual Machine Manager Server is created.
Actual behavior
Inventory Items List API wouldn't immediately return a list of inventory items after SCVMM Server is created. But I can get the list after SCVMM Server is created and then wait for a while like 1 minute.
Reproduction Steps

Create a resource group
Create a System Center Virtual Machine Manager Server
Invoke Inventory Items List API to get a list of System Center Virtual Machine Manager Inventory Items

Environment
Production

@hsurana06 Please help have a look, thank you.

After a successful PUT VMM Server, CRs (Custom Resources using CR Definition) corresponding to all the resources (ResourceType - Cloud, Virtual Network, Virtual Machine, Virtual Machine Template) present on the on-Premises SCVMM Server are created in the Operator. Post that corresponding to all these CRs, Operator syncs it with RPaaS and creates the ARM SCVMM InventoryItem resource.
This is by design that it takes some time to have InventoryItem resources in ARM and this delay depends upon the number of inventory items discovered on the SCVMM server.
FYI: For the synthetics job that we have for internal testing we have developed a polling mechanism for the InventoryItem resources with a timeout of 9 minutes. Generally, it takes less than 2 minutes, but this is again dependent on the number of inventory items discovered.
@zzhxiaofeng @neil-yechenwei


[RS-183] accept negative values

Description
Fix next issue:
When write negative values there is no validation and apply the changes
@jard_ave has added -2500 Indie Tokens to @Zyruks's wallet.
Related Issue
 183
 bug
https://github.com/serudda/reward-system/issues/183
Motivation and Context
 So as not to affect the user's portfolios
Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ x] Bug fix
[ ] New feature
[x ] Breaking change (fix or feature that would cause existing functionality to change)

[ ] My code follows the code style this project.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

@jardave21 gracias por tu aporte...
Se resolvio el issue de una forma mas simple en este PR: https://github.com/serudda/reward-system/pull/203


ElideLabel: Fix API inherited from QLabel

This PR fixes the ElideLabel API inherited from QLabel.
For consistency and interoperability purpose.
Closes #3641
Changelog:

ElideLabel: Fix API inherited from QLabel

I assume it is working with QtDesigner.
We don't have the setup for anyway, and we dont use it this way anyway.


is there a complete tutorial that guides me through using BitNet from scratch？

Is there a complete tutorial that guides me through using BitNet from scratch, for example, starting with an 8B LLaMA model, first quantizing it to 1-bit, and then performing inference?

https://github.com/microsoft/BitNet?tab=readme-ov-file#build-from-source


Use the compiler's TSX output

Changes
Previously, we used dubious regexes to convert Astro files to TSX in order to get TypeScript working. This PR changes this so we instead use a TSX output and a source map provided by the Astro compiler
This should fix all the issues listed here apart from 248, which require using the compiler in another way
Testing
WIP
Docs
WIP

Is this fixed? I'm still having AlpineJS linting errors. =(

Is this fixed? I'm still having AlpineJS linting errors. =(

Hello, this is currently available under the 0.29.0 Pre-Release. You can access it by pressing the "Switch to Pre-Release" button on the extension's page inside VS Code. For other editors, just updating the language-server package should be enough
Since this is a major change, we're keeping it in the oven just a tad longer before releasing it publicly!

I switched it to pre-release and restarted VS code, but it doesn't seem to be working still. T_T
:id="$id('dropdown-button')" still gives errors.

I switched it to pre-release and restarted VS code, but it doesn't seem to be working still. T_T
:id="$id('dropdown-button')" still gives errors.

Hmm, I think we might still have problems with attributes starting with :, I'll take a look, thank you!


Properly formatting ProxyList.txt file

Hey there,
Just looking for some basic info. I'm trying to figure out how to properly build my ProxyList.txt file. I've got the IP addresses from HMA pro but i'm not sure how to locate the port which goes at the end. I've tried searching on google how to find the ports but still not sure. Is there another free service i could use to find the information I need(IP address and port)?
Thanks a ton

Hi.
You could use this : https://www.sslproxies.org/ first column is ip address and second column is the port.


Add Balancer pow function

Part of #586.
The Balancer contract implements a custom pow function that is used to compute traded amounts. This PR adds code to replicate the smart contract code defining pow, which will be used in future PRs.
Test Plan
New unit tests.

Lets merge this baby!


REQUEST: New membership for nicolejms

GitHub Username
nicolejms
Requirements

[x] I have reviewed the community membership guidelines
[x ] I have enabled 2FA on my GitHub account, see https://github.com/settings/security
[ x] I have subscribed to the Radius community Discord server
[ x] I am contributing (any of the following apply: issues, discussions, PRs, reviews) to 1 or more Radius repositories

List of contributions to the Radius project

PRs reviewed / authored
https://github.com/radius-project/radius/pull/6274
Issues responded to
https://github.com/radius-project/radius/issues/7856
https://github.com/radius-project/radius/issues/7700
https://github.com/radius-project/radius/issues/6132

Requesting owner membership


Use environmental variable substitution on OTG input

Expand ${varname} in input OTG with matching env var value. Good use case is defining location param for OTH ports.

implementation on create is in #14

implementation on run is in #22


How can i get the uri when using a key binding to exec command

I have a command to generate template files, i set a explorer/context menu to exec the command. But how can i get the uri when using a key binding to exec command. Some extension's author use the activeTextEditor to get the active file uri, but i think this not the optimality.

Please ask your question on StackOverflow. We have a great community over there. They have already answered thousands of questions and are happy to answer yours as well. See also our issue reporting guidelines.
Happy Coding!


Add minkowski metric in polar coordinates

🐞 Problem
Currently minkowski metric is defined in cartesian coordinates. We need MinkowskiPolar.
🎯 Goal
The metric expression is diag(-1, 1, r ** 2, r ** 2 * sin(theta) ** 2). Include c(speed of light) in a similar fashion to that of given below.
💡 Possible solutions
New addition expected in the same file as given below :
https://github.com/einsteinpy/einsteinpy/blob/08411f159293955bc3456125aac7b98ac7c8db5f/src/einsteinpy/symbolic/predefined/minkowski.py#L7-L20
📋  Steps to solve the problem

Comment below about what you've started working on.
Add, commit, push your changes
Submit a pull request and add this in comments - Addresses #<put issue number here>
Ask for a review in comments section of pull request
Celebrate your contribution to this project 🎉

I would love to work on this issue if i can.

Good first issues are meant to be a starting point to newcomers.
Please try to look for more advanced issues from now on :)
On Sun, Mar 22, 2020 at 9:47 PM Swastik Singh<EMAIL_ADDRESS>wrote:

I would love to work on this issue if i can.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/einsteinpy/einsteinpy/issues/450#issuecomment-602233641,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF4NHVF6KUDFSSKC73I22WDRIY22FANCNFSM4LRJNVKQ
.

Okay.

@ritzvik  Can I work on this?

@ritzvik Can I work on this?

Go ahead 😃

Hi, I'm interested on this issue.


Some CLI commands don't respect .env file

Bug description
When running some of the setup CLI commands, the environment variables from the .env file are not loaded.
I have tested init and generate while adding the PRISMA_MIGRATION_ENGINE_BINARY and PRISMA_QUERY_ENGINE_LIBRARY environment variables to an .env file in the project root.
I ran into this while trying to start a new project within my company's proxy/firewall configuration where, there is a rule that blocks the download of the sha256, therefore I manually downloaded the engines and put them in a folder to point to with the environment variables.
I thought I was doing something wrong until I realised the commands worked if I exported the environment variables directly in the terminal, with set -a; source .env; set+a; for example, which was not the behaviour I expected.
Possibly is just certain environment variables that have this problem.
How to reproduce
I managed to test this only on windows, I'm also using git bash.

Set up a basic project following the prisma getting started documentation:

npm init -y
npm install prisma typescript ts-node @types/node --save-dev
npx tsc --init

Download the prisma engines into a ./engines folder;

- engines
   - migration-engine.exe
   - query_engine.dll.node

Create a .env file with the following contents:

PRISMA_MIGRATION_ENGINE_BINARY=${PWD}/engines/migration-engine.exe
PRISMA_QUERY_ENGINE_LIBRARY=${PWD}/engines/query_engine.dll.node

If you don't have connection problems with the binaries mirror, you can turn off your internet access.

Run npx prisma init

You should see an error similar to:
Error: request to https://binaries.prisma.sh/...

even though we are declaring in the .env file that we should use local files.
On the other hand, if you export these variable in the terminal (say by running set -a; source .env; set +a;), the command works as expected.
Expected behavior
All CLI commands should consume from the .env file.
This section of the documentation made me expect that: Docs
Prisma information
All of this happens before enve having a prisma setup.
Environment & setup

OS: Windows
Database: Irrelevant I think, but PostgreSQL is what I was trying to set up
Node.js version: v18.12.1

Prisma Version
Again, when running prisma -v without exporting vairables directly in the terminal, it fails with the same request error.
With them exported:
Environment variables loaded from .env
prisma                  : 4.10.1
@prisma/client          : 4.10.1
Current platform        : windows
Query Engine (Node-API) : libquery-engine aead147aa326ccb985dcfed5b065b4fdabd44b19 (at engines\query_engine.dll.node, resolved by PRISMA_QUERY_ENGINE_LIBRARY)
Migration Engine        : migration-engine-cli aead147aa326ccb985dcfed5b065b4fdabd44b19 (at engines\migration-engine.exe, resolved by PRISMA_MIGRATION_ENGINE_BINARY)
Format Wasm             : @prisma/prisma-fmt-wasm 4.10.1-1.80b351cc7c06d352abe81be19b8a89e9c6b7c110
Default Engines Hash    : aead147aa326ccb985dcfed5b065b4fdabd44b19
Studio                  : 0.481.0

Hello!
Any news on this?
Do you need any more information about the issue that I can provide?

Can you please show the full error message and not cut the actual file name off? Thanks.
Does it work if you define the engine file paths absolutely instead of using ${PWD}?


Exporting mistral model to neuron fails with ModuleNotFoundError: No module named 'optimum.commands.env'

System Info
optimum-neuron            0.0.18
optimum                   1.16.2
platform: amazon linux 2
Python 3.8.16

Traceback (most recent call last):
  File "[venv path]/optimum-cli", line 5, in <module>
    from optimum.commands.optimum_cli import main
  File "[venv path]/lib64/python3.8/site-packages/optimum/commands/__init__.py", line 16, in <module>
    from .env import EnvironmentCommand
ModuleNotFoundError: No module named 'optimum.commands.env'

Who can help?
No response
Information

[X] The official example scripts
[ ] My own modified scripts

Tasks

[ ] An officially supported task in the examples folder (such as GLUE/SQuAD, ...)
[X] My own task or dataset (give details below)

Reproduction (minimal, reproducible, runnable)
Install python, neuron, optimum, optimum neuron versions above on amazon linux 2.
Try to export a local fine-tuned mistral model to neuron using any --task (I tried text-classification)
command I used: optimum-cli export neuron --model base_model --task text-classification --sequence_length 4096 --batch_size 1 pytorch_model_neuron/
Expected behavior
Model should export to neuron

Please specify the underlying hardware (inferentia2/inferentia1/trainium etc.)

I trying to compile on AL2 non inferentia instance to inf1 or inf2

I am slightly confused by your reply, what do you mean by "non inferentia instance to inf1 or inf2"?
Basically, if you want to compile a neuron-supported model for inf1 or inf2, the compilation needs to happen on inf1 or inf2.

I see, will try compiling on inf1 or inf2 and post an update

Compiling on inf2 worked, thanks


Kirki with Bedrock as mu-plugin - url path leads to 404

Issue description:
Prior notices
I am trying to use Kirki as a dependency of a custom mu-plugin used in a local wordpress installation which uses bedrock.
About bedrock:
In short, bedrock is a boilerplate for creating wordpress within a subdirectory.
So basically it moves the wp-content to a separated directory and renames it to app.
This is done by using the wordpress native constants i.e. (WP_CONTENT_DIR, WP_PLUGIN_DIR, WP_PLUGIN_URL, PLUGINDIR).
Little notice here: By default it does not seem to use the constant MUPLUGINDIR, but I added it by myself in the bedrock application.php. (which is the preferred way for adding wp-config constants as referenced in their documentation).
In my specific case I installed Kirki using Composer within my plugin. But even if I use it as a "normal" mu-plugin, by downloading the plugin from the Wordpress Plugin Directory and manually move it into mu-plugins, the following issue will occur.
The issue
Panel and sections show up in customizer as intended. But fields do not.
Instead no JS dependencies can be loaded (404 not found), because of the wrong url path.

After some investigation its the following function of the Class Kirki_Init which seem to cause the issue in context of "is_admin" (in backend customizer only):
//Class Kirki_Init
public static function set_url() {
	if ( Kirki_Util::is_plugin() ) {
		return;
	}

	// Get correct URL and path to wp-content.
	$content_url = untrailingslashit( dirname( dirname( get_stylesheet_directory_uri() ) ) );
	$content_dir = wp_normalize_path( untrailingslashit( WP_CONTENT_DIR ) );
	Kirki::$url = str_replace( $content_dir, $content_url, wp_normalize_path( Kirki::$path ) );
	// Apply the kirki_config filter.
	$config = apply_filters( 'kirki_config', array() );
	if ( isset( $config['url_path'] ) ) {
		Kirki::$url = $config['url_path'];
	}

	// Make sure the right protocol is used.
	Kirki::$url = set_url_scheme( Kirki::$url );
}

I checked the $url variable in some random scopes and the value mostly seem fine, but when var_dumping the $url value within your "enqueue" function (in class "Kirki_Control_Base") the value is wrong.
Version used:
3.0.39 installed via Composer
alternatively
3.0.39 downloaded via Wordpress Plugin Directory and manually
Called via requiring the kirki.php file and then setup (1 demo: Config, Panel, Section, Field) as described in your docs.

ok looks like I am blind somethimes... :smirk:
just had to use your filter
/**
 * Configuration sample for the Kirki Customizer
 */
function my_config() {

    $args = array(
        'url_path'      => 'my_path',
    );

    return $args;

}
add_filter( 'kirki/config', 'my_config' );

to set the $config['url_path']

Yeah, the filter is the easy way... I was trying to think of a way to accommodate mu-plugin installations but didn't have time to really check this, I'm working on the 4.0 refactors at the time and I had more basic issues to deal with. :yum:
I opened #2145 just as a reminder to check this when I'm done with the basics of the 4.0 implementation.
In the refactor everything is getting split to separate packages and I have a package dedicated to getting the URLs from paths, you can see it here: https://github.com/kirki-framework/url-getter/blob/master/src/URL.php#L121
Instructions are on the README file on that repo if you're in the mood to test it :+1:


Python binding release failed

Describe the bug
https://github.com/apache/opendal/actions/runs/10367226638/job/28698185879
The following warnings were emitted during compilation:

warning<EMAIL_ADDRESS>CMAKE environment variable set: cmake
warning<EMAIL_ADDRESS>Generating bindings - external bindgen. Platform: armv7-unknown-linux-gnueabihf

error: failed to run custom build command for `aws-lc-sys v0.20.1`
note: To improve backtraces for build dependencies, set the CARGO_PROFILE_RELEASE_BUILD_OVERRIDE_DEBUG=true environment variable to enable debug information generation.

Caused by:
  process didn't exit successfully: `/home/runner/work/opendal/opendal/bindings/python/target/release/build/aws-lc-sys-388626e311f91bd8/build-script-main` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=AWS_LC_SYS_NO_PREFIX
  cargo:rerun-if-env-changed=AWS_LC_SYS_INTERNAL_BINDGEN
  cargo:rerun-if-env-changed=AWS_LC_SYS_EXTERNAL_BINDGEN
  cargo:rerun-if-env-changed=AWS_LC_SYS_NO_ASM
  cargo:rerun-if-env-changed=AWS_LC_SYS_CMAKE_BUILDER
  cargo:rerun-if-env-changed=AWS_LC_SYS_STATIC
  cargo:rerun-if-env-changed=CMAKE
  cargo:rerun-if-env-changed=CMAKE
  cargo:warning=CMAKE environment variable set: cmake
  cargo:warning=Generating bindings - external bindgen. Platform: armv7-unknown-linux-gnueabihf

  --- stderr
  Consider installing the bindgen-cli: `cargo install --force --locked bindgen-cli`
  See our User Guide for more information about bindgen:https://aws.github.io/aws-lc-rs/index.html
  Failure invoking external bindgen! External bindgen command failed.
  thread 'main' panicked at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/aws-lc-sys-0.20.1/builder/main.rs:469:5:
  aws-lc-sys build failed. Please enable the 'bindgen' feature on aws-lc-rs or aws-lc-sys.For more information, see the aws-lc-rs User Guide: https://aws.github.io/aws-lc-rs/index.html
  stack backtrace:
     0: rust_begin_unwind
     1: core::panicking::panic_fmt
     2: build_script_main::main
     3: core::ops::function::FnOnce::call_once
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...
💥 maturin failed
  Caused by: Failed to build a native library through cargo
  Caused by: Cargo build finished with "exit status: 101": `env -u CARGO "cargo" "rustc" "--features" "pyo3/extension-module,services-all" "--target" "armv7-unknown-linux-gnueabihf" "--message-format" "json-render-diagnostics" "--manifest-path" "/home/runner/work/opendal/opendal/bindings/python/Cargo.toml" "--release" "--lib" "--" "-C" "link-arg=-s"`
Error: The process '/usr/bin/docker' failed with exit code 1
    at ExecState._setResult (/home/runner/work/_actions/PyO3/maturin-action/v1/dist/index.js:1702:25)
    at ExecState.CheckComplete (/home/runner/work/_actions/PyO3/maturin-action/v1/dist/index.js:1685:18)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/PyO3/maturin-action/v1/dist/index.js:1579:27)
Error: The process '/usr/bin/docker' failed with exit code 1
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1105:16)
    at ChildProcess._handle.onexit (node:internal/child_process:305:5)

Steps to Reproduce
Happen during building opendal-python.
Expected Behavior
Build pass.
Additional Context
No response
Are you willing to submit a PR to fix this bug?

[ ] Yes, I would like to submit a PR.

Hi, @messense, do you have any suggestions for getting it fixed?

Try enable ring instead of the default aws-lc-rs (which seems to require bindgen) feature in rustls.

Try enable ring instead of the default aws-lc-rs (which seems to require bindgen) feature in rustls.

We are using reqwest now which should enable ring by default?

Maybe check cargo tree -i aws-lc-rs to see what brings it into dependency graph?

Thanks for @messense to find out: https://github.com/blackbeam/mysql_async/pull/304

Fixed.

As we use sqlx now, we should be able to revert this comment out?