Cds satellite lai fapar

Opening a draft PR for fixing/discussing the last open issues for CMORizing a dataset from the CDS, see #1191. Thanks for your help !
This PR also needs addition of a custom CMOR variable, this is done in the following PR for ESMValCore: https://github.com/ESMValGroup/ESMValCore/pull/147
Open issues:

Where do I find guidance on how to deal with the Iris warnings? Is this something to go through for each warning, or is there already an overview somewhere listing motivation for filtering out certain warnings?
This dataset has one variable that 'lives' in CMIP5 table (lai), and another one in the 'custom' table (fapar). I found a way to deal with this, but I think this can be done better:
https://github.com/ESMValGroup/ESMValTool/blob/5a1934a163726d8c597e923d03540b5c494ce17a/esmvaltool/cmorizers/obs/cmorize_obs_cds_satellite_lai_fapar.py#L59-L63
This dataset has very custom time boundaries that do not coincide with the start and end of each month. The time_bnds are created from reading them from each files metadata. See:
https://github.com/ESMValGroup/ESMValTool/blob/5a1934a163726d8c597e923d03540b5c494ce17a/esmvaltool/cmorizers/obs/cmorize_obs_cds_satellite_lai_fapar.py#L132-L159
Of course the cmor check fails on this. Is there the possibility to keep the time axis as is? I noted that @bouweandela created a seperate 'project' for dealing with the 1h time resolution for ERA5 data.
At the moment intermediate files are written to rawobsdir, this will be changed to workdir

Where do I find guidance on how to deal with the Iris warnings? Is this something to go through for each warning, or is there already an overview somewhere listing motivation for filtering out certain warnings?

Your code should not generate warnings if things are running as expected. Usually iris warnings mean that the the data does not follow the cf conventions, so iris cannot understand it.

This dataset has one variable that 'lives' in CMIP5 table (lai), and another one in the 'custom' table (fapar). I found a way to deal with this, but I think this can be done better:

Use project OBS instead of using the custom table directly

Of course the cmor check fails on this. Is there the possibility to keep the time axis as is?

Can you help out here, @jvegasbsc ?

I noted that @bouweandela created a seperate 'project' for dealing with the 1h time resolution for ERA5 data.

Initially I did that, but later we decided to instead create an OBS6 project (i.e. CMIP6 + custom), because in CMIP6 there is an E1hr mip that could be extended with custom variable entries.

Your code should not generate warnings if things are running as expected. Usually iris warnings mean that the the data does not follow the cf conventions, so iris cannot understand it.

There are also some of them that are thrown and data is perfectly fine, like the infamous  missing cell measure areacell@ that appears because areacell@ is defined in other file to avoid replication of data. This is CF compliant but Iris shows a warning because it can't know if it is missing or in other file

Of course the cmor check fails on this. Is there the possibility to keep the time axis as is?

Can you help out here, @jvegasbsc ?

Are you doing this on Jasmin? If that's the case, please tell me so I can start testing directly from your data

Of course the cmor check fails on this. Is there the possibility to keep the time axis as is?

Can you help out here, @jvegasbsc ?

Are you doing this on Jasmin? If that's the case, please tell me so I can start testing directly from your data
No, I am not on Jasmin, running ESMValTool on a local cluster... You can download just a small sample of the data to get started (take both variables, bug e.g. just one year of data). Is it desirable that I create an account on Jasmin to add the data?

There are also some of them that are thrown and data is perfectly fine, like the infamous missing cell measure areacell@ that appears because areacell@ is defined in other file to avoid replication of data. This is CF compliant but Iris shows a warning because it can't know if it is missing or in other file

This is a problem with iris, I think we should address this at some point or decide to filter the warning everywhere.
Unfortunately the solution is not as easy as loading both files at the same time:
>>> import iris
>>> iris.load(["/badc/cmip5/data/cmip5/output1/BCC/bcc-csm1-1/historical/fx/atmos/fx/r0i0p0/latest/areacella/areacella_fx_bcc-csm1-1_historical_r0i0p0.nc", "/badc/cmip5/data/cmip5/output1/BCC/bcc-csm1-1/historical/mon/atmos/Amon/r1i1p1/latest/tas/tas_Amon_bcc-csm1-1_historical_r1i1p1_185001-201212.nc"])
/group_workspaces/jasmin2/cp4cds1/magic-test/tmp-bandela/version2_development/conda/envs/esmvaltool/lib/python3.6/site-packages/iris/fileformats/cf.py:798: UserWarning: Missing CF-netCDF measure variable 'areacella', referenced by netCDF variable 'tas'
  warnings.warn(message % (variable_name, nc_var_name))
[<iris 'Cube' of air_temperature / (K) (time: 1956; latitude: 64; longitude: 128)>,
<iris 'Cube' of cell_area / (m2) (latitude: 64; longitude: 128)>]

still shows the warning.

This is a problem with iris, I think we should address this at some point or decide to filter the warning everywhere.

They are well aware of this /SciTools/iris#3329

Here is the link to apply for membership for esmeval group workspacce: https://accounts.jasmin.ac.uk/services/group_workspaces/esmeval/

I am awaiting approval.

@BenMGeo  Could you try out the script on FPAR as well and confirm if it works? This is also a good check if I described the data retrieval part correctly.

Status update: data is being rsynced now to the RAWOBSDIR on Jasmin (~180GB). I thought it would be good to get the RAW data there, that gives us (me and @jvegasbsc) more flexibility in testing this CMOR script.

please merge the latest version2_development into your branch to solve the failed test(s)

@BenMGeo Do you want to test/review this? Note that you need latest ESMValCore including the custom variable fapar. If you don't have time I suggest to move on and merge after approval by @bouweandela and/or @valeriupredoi.
Recipe check_obs did not complain about time_bnds, that is good news and from my side there is no need to further look into this by @jvegasbsc .

@bouweandela  Any idea why the test fails now?

Do you have an idea why the test fails now?

Unfortunately not

@mattiarighi Code looks fine to me. Could you please test?

Do you have an idea why the test fails now?

Unfortunately not

Clicking re-run seems to have fixed it.

Waiting for the download request... :sleeping:

Thank you @bascrezee!
I'm getting the data and will test asap.

Tested successfully!
I have just renamed the dataset to upper case, for consistency with the other CDS datasets.

Shouldn't we maybe go for lower case for all CDS datasets? So instead we change CDS-SATELLITE-SOIL-MOISTURE to cds-satellite-soil-moisture. For the other new OBS datasets I already changed to lower case actually.

Apart from a few exceptions, we use upper case for almost all observations, see overview table.
Also the models mostly use upper case names.
If it's matter of plotting labels, this can be changed in the individual diagnostics based on user's preference.

Ok, fine with me.


Fabric/Fluent Icon Issue

Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Developer environment
Windows
What browser(s) / client(s) have you tested

[ ] 💥 Internet Explorer
[X] 💥 Microsoft Edge
[X] 💥 Google Chrome
[ ] 💥 FireFox
[ ] 💥 Safari
[ ] mobile (iOS/iPadOS)
[ ] mobile (Android)
[ ] not applicable
[ ] other (enter in the "Additional environment details" area below)

Additional environment details

browser version
SPFx version : 1.15.0
Node.js version : 16.x
etc

Describe the bug / error
In image attached, I use the SetAction icon.  Notice in the https://uifabricicons.azurewebsites.net/ site, that the icon lightning bolt is not filled in, but in my tenant it is.  Also notice that the font family in https://uifabricicons.azurewebsites.net/ is "FabricMDL2Icons", but in my tenant is "Fluent MDL2 Hybrid Icons".  I observe with other icons as well.
import { Icon } from 'office-ui-fabric-react/lib/Icon'

Steps to reproduce

in my particular tenant, use SetAction icon (import { Icon } from 'office-ui-fabric-react/lib/Icon' in SPFx customization)
deploy customization
3.observe customization (see screenshot)

Expected behavior
Icons are consistent with those in https://uifabricicons.azurewebsites.net/

@brianpmccullough - icons are mostly consistent.
We know that currently the font has been updated and some icons may not be in sync with the provided url.
I would use this statement: if you select the icon from the URL - it will definitely work.
There might be additional icons that are already available in the service but not updated in the list.
We're working on syncing the lists.

@AJIXuMuK  - so I am confused.  there is work being done to update  to match what is published in the site: https://uifabricicons.azurewebsites.net/?  Or there is work being done to update the site with updated icons?

@brianpmccullough - update what is published at https://uifabricicons.azurewebsites.net/


Setting Publication Language to 'en_GB' rather than 'en' doesn't change spell check in editor

Issue Summary
We are publishing a website using Ghost in British English. We have set the Publication Language to 'en_GB' rather than 'en'. However even after doing so spell check in post editor still put red lines under words spelt correctly for English (UK), and then proposed US English spellings.

Steps to Reproduce

Change Publication Language to 'en_GB'
Type word 'characterise' into post editor and see if red line appears.

Ghost Version
4.32
Node.js Version
v14.18.1
How did you install Ghost?
debian
Database type
MySQL 8
Browser & OS version
FireFox 98.0.2 (64-bit)
Relevant log / error output
N/A

Code of Conduct

[X] I agree to be friendly and polite to people in this repository

To the best of my knowledge modern browsers do not provide a consistent, reliable API to set the language on a content editable field, instead the user's language choice in the browser is always preferred.
If it was even possible, we'd then need to discuss whether changing the language in the editor is a desired impact of the language setting, as the current intention of the setting is to do with the output of the frontend.
As this is the first ever mention, I'm going to close for now as a wont/cant fix 🙂  Feel free to raise a feature request on the forum to see if there's wider interest & if anyone knows a way to do this reliably, then we can always revisit.


Low Priority - Enhancement Request: Add version number to UI

I know the codebase doesn't have a proper version number to it right now, but it would be nice to see from the webpage if I'm on the latest version or not instead of checking the repo for recent commits.
To build on top of that, a future enhancement to this request could be the app checking for updates and prompting the user.

@Intecpsp yeah I've been thinking of the same just to help in reporting errors and setting up a GitHub issue template.
We would need bare minimum for this is the repository Sha. Later add in a raspberrypi build version (beta1, beta2, beta3) and device firmware for each registered device that has made requests to the server.
This feature could just be a footer implementation, but I also see it helpful to have an /about page that has this an "update" type button that does the same as the system menu update/restart system. While also helping with how to use the server.
Thanks for the feature request, let's track this work and collaboration here.

In theory we could switch to semantic versioning and have a "beta" and "stable" tag to reduce blast radius of changes introduced... But don't think that is worth it right now.
Another thing I wanted to build to make development easier is to setup on that about page a "developer mode" (opt-in toggle in config.yaml) to add a "repo" and "branch" text field where you could pull down custom builds of the server from another git remote and branch.

@Intecpsp just to provide some update on where I am here. I'm working on providing both OS level information (mac vs win vs linux vs raspbian) as well as git file information (are there local file changes that conflict with an update, git sha, and latest remote git sha).

Later I want to be able to have a "dev=true" hidden mode here to be able to hook up a custom remote and/or custom branch for updates. This would allow for easy testing of provided PRs and/or a long lived feature branch before making it widely available.
Let me know if this is answering the need for "Add version number to UI" lol. Likely I'll work on a consistent footer as well so screenshots have a consistent and easy way to telling the number without having to also navigate to /about for additional information.

Dude, that is awesome! This totally meets the request requirements, and exceeds them, nice work! I like the use of the commit number compare. All a user would need to know is IF there is an update, not necessarily how many versions they are behind. A question on the conflict feature, will an update (as it's written today) overwrite them and would there be a way to prevent that without copying out and back in?

As currently written @Intecpsp the update will fail the git pull. It was more about giving a visual if the update would be allowed or not. All resolution will need to be handled manually by the owner of the server via ssh or whatever based on their setup.
If you have conflicted files... you more than likely already know your way around git or we the maintainers of the server did something wrong/explicit like when we removed the config.yaml from source control. If the later, which should always be seen as a last resort, then there will be explicit instructions given to users as to how to upgrade.
What could be done is to stash these into the .git directly... but that requires git to be configured which isn't done today and I would prefer not do configure git and allow owners to choose to do that or not themselves.
Maybe what you are calling out is that the "Update/Restart Server" should be disabled when there are conflicting files as the update will fail anyways.


Create presentation to introduce Morph

We'd like to have a presentation to introduce Morph to the company.
The goal is for the company to be aware of us, our goals, as well as our next step.
Timeline:
March 10th, Friday - Finish the draft
March 17th, Friday - Confirm a time for the presentation
TBD - Present
Google Slides - https://docs.google.com/presentation/d/1_XKxF0c3QbQKGIIvL1UdsNl9iNQTfsKoVWMgTX8MmYI/edit

Hey team! Please add your planning poker estimate with Zenhub @Akatori-Design @brianacnguyen @garrettbear @xinnanyemm


copied your code and PR'd

A bit of extra stuff too. Would be interested if maybe you know that the type conversion there is too fragile to be useful (it works in my one case that I tried).
https://github.com/RDFLib/sparqlwrapper/pull/112

Interesting. Thanks for the heads up.
I hadn't really thought about passing types from SPARQL to pandas. The code I posted will use pandas internal mechanism for inferring types. Not sure what is a better approach and could depend on the number of rows you are trying to load at once.


Make mutating Arena methods more flexible

Allow Arena::mutate to return references inside the object graph, as long as they don't mention the 'gc lifetime. This is safe because drops can only occurs while collecting, which requires exclusive access to the arena.

This has also the nice side-effect of reducing the number of lifetimes the user has to care about.

Add Arena::mutate_root, which allows mutating the root set.

All of this makes sense to me, and I agree it looks sound! Thank you very much!


dependent gem versions should depend on major version only

otherwise in future you will have REACT::VERSION = 1.2
then you upgrade to 1.3 for some minor thing
and now all other gems have to be re-released even though nothing has changed in them.

now a user reports a problem. to check you need to know all versions of all gems, maybe, depending on the depth of the problem, and verify.
I prefer the rails way here, rails 5.1.4 is what it is, even some gems didnt change, but its "a well defined entity"
First option: Likewise "hyperloop 1.0.1" for everything being 1.0.1
Second option: But image "hyperloop 1.0.0, hyper-operation 1.0.2, hyper-react 1.0.3, hyper-mesh 1.0.5 ..."
Now a problem report:

Something doesnt work

What version do you use?
First option:

hyperloop 1.0.1

Second option:

Well, errm, hyperloop 1.0.1
Ok, cool, please list the versions of alle the gems involved ...

Further on, reproduction:
First option: to reproduce, give me your peace of code, i run it against 1.0.1
Second options: to reproduce, give me your piece of code, and i have to install the exact gem versions of the user and then i can run it
Further on, solution:
First option: Fixed, just install hyperloop 1.0.2 -> new tested set, well defined entity
Second option: make sure to include the following gems with the following version ....
Keeping them all synchronized makes support much easier. Yes, some gems sometimes are released with no changes, ok, but thats not the issue. The benefit of reducing the supported set (varieties of gems and versions), reducing complexity, makes support and development easier.
Imagine 1.0.0 going to 1.0.21, the supported set will explode and problems appear, that are non issues, if the supported set would be clearly defined.

I think there is a difference between dependency and how things are released.
Rails AFAIK does not FORCE you to keep all of its sub-gems in sync.  That is all I am saying.

I understand your concern, i agree, if somebody wants to run production like this, the versioning needs to be relaxed.


Update OpenIdConnectRequestType

#373

Hi @ChenYan98, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Yan Chen). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

:shipit: You will need to rebase before merging.

+1


detector: llm as judge

fork an llm like atkgen does
ask a q like "is {text} an instance of {phenomenon}"
look for answer in output

@leondz I'd love to take crack at this


[Bug] Apple Silicon - DllNotFoundException

[REQUIRED] Please fill in the following fields:

Unity editor version: 2021.2.0b4 Apple Silicon
Firebase Unity SDK version: 8.1.0
Source you installed the SDK: .unitypackage
Problematic Firebase Component: Auth and others
Other Firebase Components in use: None
Additional SDKs you are using: None
Platform you are using the Unity editor on: Mac / MacBook Air M1
Platform you are targeting: iOS (Any)
Scripting Runtime: Mono (Any)

[REQUIRED] Please describe the issue here:
(Please list the full steps to reproduce the issue. Include device logs, Unity logs, and stack traces if available.)
After importing the FirebaseAuth package into an empty Unity project with the Apple Silicon Version of the Unity Editor and initializing the the module with a simple
FirebaseAuth auth = FirebaseAuth.DefaultInstance;
I get the following Exception when entering play mode:
DllNotFoundException: FirebaseCppApp-8_1_0 assembly: type: member:(null)
Firebase.AppUtilPINVOKE+SWIGExceptionHelper..cctor () (at Z:/tmp/tmp.9PHv6s9T8D/firebase/app/client/unity/proxy/AppUtilPINVOKE.cs:117)
Rethrow as TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception.
Firebase.AppUtilPINVOKE..cctor () (at Z:/tmp/tmp.9PHv6s9T8D/firebase/app/client/unity/proxy/AppUtilPINVOKE.cs:137)
Rethrow as TypeInitializationException: The type initializer for 'Firebase.AppUtilPINVOKE' threw an exception.
Firebase.AppUtil.SetLogFunction (Firebase.LogUtil+LogMessageDelegate arg0) (at Z:/tmp/tmp.9PHv6s9T8D/firebase/app/client/unity/proxy/AppUtil.cs:64)
Firebase.LogUtil..ctor () (at Z:/tmp/tmp.9PHv6s9T8D/firebase/app/client/unity/proxy/LogUtil.cs:81)
Firebase.LogUtil..cctor () (at Z:/tmp/tmp.9PHv6s9T8D/firebase/app/client/unity/proxy/LogUtil.cs:37)
Rethrow as TypeInitializationException: The type initializer for 'Firebase.LogUtil' threw an exception.
Firebase.FirebaseApp..cctor () (at Z:/tmp/tmp.9PHv6s9T8D/firebase/app/client/unity/proxy/FirebaseApp.cs:67)
Rethrow as TypeInitializationException: The type initializer for 'Firebase.FirebaseApp' threw an exception.
Firebase.Auth.FirebaseAuth.get_DefaultInstance () (at Z:/tmp/tmp.fXb0dO0rk8/firebase/auth/client/unity/proxy/FirebaseAuth.cs:295)
FirebaseAuthTest.Start () (at Assets/FirebaseAuthTest.cs:11)
When doing the same in the Intel version of the Unity beta then a popup appears about an untrusted developer for FirebaseCppApp-8_1_0.bundle, which can be worked around by allowing execution through the MacOs system security settings. But in the Apple Silicon version this popup does never appear.

A dirty workaround that works for me with 8.10.0 is to use the FirebaseCppApp-8_8_0.bundle from the bundles @samskivert  provided above, rename it to FirebaseCppApp-8_10_0.bundle and call /usr/bin/xattr -d com.apple.quarantine path/to/project/Assets/Firebase/Plugins/x86_64/FirebaseCppAuth.bundle on it

I created repo with actual modified .tgz files supporting Apple silicon for Firebase SDK 8.10.1. Feel free to use it and hopefully Google will start to provide it as soon as possible in official releases. It is ridiculous why it took them so long. If there will be any problems let me know pls.
https://github.com/nodrock/firebase_sdk_silicon

@steffen-roemer Thx for the tip. I did the exact same thing but for some kind of reason it just doesn't work for me. I'm still getting the DllNotFoundException.

OK, updated 8.8.0 bundles are here: https://samskivert.com/firebase-bundles.zip

Hi @samskivert
Please can you update bundle in firebase 8.9.0 version ?
it's huge for us.

Hi all,
I built the latest bits for 8.10.1, which are at the same URL: https://samskivert.com/firebase-bundles.zip
I have only tested Firebase Core, Auth and Messaging as those are the packages we use, but everything else is built and included in the .zip file.
As mentioned, hopefully this will be the last release for which we need our own custom .bundle files.

@samskivert Thanks for the bundles!
I don't have any idea how to use them though. Any help would be appreciated.

Import Firebase libs into your project using unity packages
Go to Assets/Firebase/Plugins folder and create arm64 folder
Copy all arm64 bundles into that folder just as it's in x86_64
Then you need to configure bundle files to be used on macs with apple silicon CPU. It's done in Unity Editor

Thank you!

Hi all,
We've released a new version of the Firebase for Unity SDK, 9.0.0, available here: https://github.com/firebase/firebase-unity-sdk/releases/tag/v9.0.0, which adds support for Apple Silicon chips.
Sorry it took a while to add this support, and thanks to all the folks who provided workarounds in the meantime.

I still got DllNotFoundException: FirebaseCppApp-9_0_0
Not sure it related to this issue. But I use latest unity 2022.1

DllNotFoundException: FirebaseCppApp-9_1_0  still have the problem


fix: Change to FilterQuality.medium instead of high

Description
According to the Flutter docs, tests and #2551 FilterQuality.high is actually producing worse output than FilterQuality.medium in almost all cases (the exception is when you use a very high scale factor).
This PRs set the places we have defined as high to medium instead.
Checklist

[x] I have followed the Contributor Guide when preparing my PR.
[x] I have updated/added tests for ALL new/updated/fixed functionality.
[x] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[x] I have updated/added relevant examples in examples or docs.

Breaking Change?

[x] No, this PR is not a breaking change.

Related Issues
Closes #2551

I feel that ever since flame got to life, we change such thing at least once a year :(

Haha yeah, it hasn't updated on the Flutter side though, it's just that we've been bad at reading the docs. 😅


Build all packages before running linters

go vet, in particular, is known for relying on the package cache
for code analysis.

What does this do / why do we need it?
On my local machine, lint.bash produces the following output:
cmd/dep/godep_importer_test.go:108: github.com/golang/dep/internal/test.Writer composite literal uses unkeyed fields
exit status 1
internal/gps/manager_test.go:48: github.com/golang/dep/internal/test.Writer composite literal uses unkeyed fields
internal/gps/manager_test.go:69: github.com/golang/dep/internal/test.Writer composite literal uses unkeyed fields
internal/gps/manager_test.go:91: github.com/golang/dep/internal/test.Writer composite literal uses unkeyed fields
internal/gps/manager_test.go:147: github.com/golang/dep/internal/test.Writer composite literal uses unkeyed fields
internal/gps/result_test.go:129: github.com/golang/dep/internal/test.Writer composite literal uses unkeyed fields
internal/gps/solve_test.go:28: github.com/golang/dep/internal/test.Writer composite literal uses unkeyed fields
internal/gps/solver_inputs_test.go:174: github.com/golang/dep/internal/test.Writer composite literal uses unkeyed fields
internal/gps/source_cache_bolt_test.go:24: github.com/golang/dep/internal/test.Writer composite literal uses unkeyed fields
internal/gps/source_cache_test.go:28: github.com/golang/dep/internal/test.Writer composite literal uses unkeyed fields
internal/gps/source_manager_test.go:97: github.com/golang/dep/internal/test.Writer composite literal uses unkeyed fields
internal/gps/source_test.go:43: github.com/golang/dep/internal/test.Writer composite literal uses unkeyed fields
exit status 1

I believe the missing call to go test -i is the reason we're not seeing these issues in travis.
What should your reviewer look out for in this PR?
Nothing yet, but I'll probably amend this with the fixes once travis (hopefully) fails.
Do you need help or clarification on anything?
No.
Which issue(s) does this PR fix?
None.

Yep, travis failed. Hurray! I'm amending the commit with fixes.

oh man, this has driven me nuts forever. i'd basically just lost faith that travis was telling me true things on some linters.

Can someone hit the merge for me?


[WIP] Use gob with websockets ...

... with the intention of caching the gob engines.
Very hacky, just a proof of concept.
As an alternative to solve #854

Unfortunately this doesn't seem to help at all. When running Scope locally (with a single app and probe), it takes double as much CPU as the generated JSON decoders ( #916  ) and I get this app CPU profile:
pprof.<IP_ADDRESS>:4040.samples.cpu.011.pb.gz

Surprisingly, even if a single  encoding/gob.Decoder is used, compileDec() (which createsthe gob engines) executes 40%. This isn't expected since the engines should be cached within the Decoder.

OK, it seems that some engines are not being cached. After adding some logging for the cache misses of getDecEnginePtr():
 fmt.Printf("Decoder cache miss for type %s (remote id %d)\n", rt.Name(), remoteId)

I see:
$ docker logs  weavescope |& grep Decoder | sort | uniq -c
 182943 Decoder cache miss for type arrayType (remote id 17)
 182943 Decoder cache miss for type CommonType (remote id 18)
      1 Decoder cache miss for type Control (remote id 79)
  29517 Decoder cache miss for type EdgeMetadata (remote id 84)
 182943 Decoder cache miss for type fieldType (remote id 21)
 182943 Decoder cache miss for type gobEncoderType (remote id 24)
  29517 Decoder cache miss for type LatestEntry (remote id 86)
 182943 Decoder cache miss for type mapType (remote id 23)
      1 Decoder cache miss for type NodeControls (remote id 72)
      1 Decoder cache miss for type Node (remote id 67)
 182943 Decoder cache miss for type  (remote id 16)
      1 Decoder cache miss for type  (remote id 65)
  29517 Decoder cache miss for type  (remote id 82)
  59034 Decoder cache miss for type  (remote id 83)
  29517 Decoder cache miss for type  (remote id 85)
  29517 Decoder cache miss for type  (remote id 87)
  35357 Decoder cache miss for type  (remote id 88)
  35357 Decoder cache miss for type Sample (remote id 89)
      1 Decoder cache miss for type Sampling (remote id 81)
 182943 Decoder cache miss for type sliceType (remote id 19)
 182943 Decoder cache miss for type structType (remote id 20)
      1 Decoder cache miss for type Topology (remote id 66)

OK, this is because counters.go, latest_map.go etc ... all provide GobDecode which in turn creates buffers and other decoders. Let's see if I can thread the top-level decoder in.

Now that I think about it, this is also the case with JSON in #916

There isn't a  way to pass in the same encoder. Using encoding/gob.Register to avoid intermediate representations for ps.Map (11d517a) didn't fly either.

Closing in favor of #916

PS: it seems like the Golang maintainers don't have any plans to improve the interface to allow more efficient serialization of custom intermediate types. https://groups.google.com/forum/#!topic/golang-nuts/BQsVtMiu0W4


Upgrade to Kubernetes 1.10?

Feature Request
Upgrade to Kubernetes 1.10
What is the release plan for next tectonic version with k8s 1.10?
Environment
What hardware/cloud provider/hypervisor is being used with Tectonic?
bare metal

Hi  , i just wanted to share.
I have requested the same to tectonic  community while ago on another thread, however there was  no reply to that since from August . I think due to Tectonic (Coreos) acquistion by Redhat and Redhat acquired by IBM. This will lead to some uncertinity until we hear back from the product management of COREOS/tectonic/Redhat ?

Agree, but we've moved on. Tectonic worked great for us, but needed some of new features for our deployments, so had to move on to something that's better maintained and is in sync with kubernetes upstream (though without the one-click upgrades).

you can check SUSE CAASP which is opensource and works nicely with ISO image bootstrape of kubernetes cluster anywhere whether baremetal or virtual ? just download and bootstarp ISO after that you can decide the master/worker cluster through a nice workflow application..
here is the link.
https://www.suse.com/products/caas-platform/

I think those who are acquainted with tectonic might find https://typhoon.psdn.io/ to be the most comfortable to switch to without much of an extra learning curve. It has the same tectonic like terraform support (infact the author is same).


Why is the code obfuscated?

Hi. I really wanna learn from this hack so I can create hacks myself. However, the code is just a tad bit hard to read. Can you make a un-obfuscated version or give me the reason why it is?

Where is the obfuscated code?

It's obfuscated because there's an 80% chance it's a rat


New package: Try v0.1.0

Registering package: Try
Repository: https://github.com/tkf/Try.jl
Created by: @tkf
Version: v0.1.0
Commit: 442fc6ecf509e59cb3eecedb163b26b5dbba2126
Reviewed by: @tkf
Reference: https://github.com/tkf/Try.jl/commit/442fc6ecf509e59cb3eecedb163b26b5dbba2126#commitcomment-69235345
Description: Zero-overhead and debuggable error handling

I think "Try" is the best word describing the philosophy behind this package. For example, quoting the first paragraph in a discussion section Focus on actions; not the types:

Try.jl aims at providing generic tools for composing failable procedures.  This emphasis on performing actions that can fail contrasts with other similar Julia packages focusing on types and is reflected in the name of the package: Try.  This is an important guideline on designing APIs for dynamic programming languages like Julia in which high-level code should be expressible without managing types.

Given that there are some broader interests in this type of error handling  https://github.com/JuliaLang/julia/discussions/43773, I'm also willing to hand this over to a larger organization once this package is sufficiently matured and tested in the wild (e.g., to JuliaLang if Base needs to use something like this).
[noblock]


use @Unsecured Service in auth-test-suite instead of repository

provide protected clearUsers method which uses private Repository


[WIP] Documentation refactoring

Purpose
See #219
Background (Problem in detail)
Adds:

CONTRIBUTING.md
docs/index.md as the main documentation file
mkdocs.yml config file

Solution

Install MkDocs
Checkout this branch
run mkdocs serve -f mkdocs.yml
check out the docs at localhost:8000 (default)

Can you link to the API docs from the README and remove the contents from the README?

@benjamingr Yes will do :+1:

@benjamingr @SimenB thanks for your detailed feedback. I will change this accordingly!


Publish task does not preserve links

This is a bit obscure, so bear with me:
When using the publish task to copy an .app with a framework reference from a mac agent, symbolic links are lost (I believe). This manifests when downloading the .app artifact from VSTS and attempting to sign it with:
codesign --force --sign [THUMBPRINT] --deep myapp.app
This returns bundle format is ambiguous (could be app or framework) in subcomponent: /path/to/dependent.framework
We have worked around this issue by using our own copy task that calls a .sh which mounts a share, and then copies the artifacts with:
cp -R folder/to/copy/to location/of/myapp.app
According to http://www.delorie.com/gnu/docs/fileutils/fileutils_38.html -R verses -r:
"Copy directories recursively, preserving non-directories"
Note: when we used copy -r we had the same issue as the using the publish task.
Using the capital R argument allows me to sign the .app using codesign.
I believe using the -a argument would work as well, but I have not verified.

👍 Getting this too.  Using hosted agents, passing a .app between phases, not sure how will workaround right now but probabbly zip... 🤔

@mitchdenny I'm doing a clean-up triage of our GitHub issues. Is this something you think we can fix in the new Pipeline Artifacts tasks, or should we close/WF it?

It is something we want to solve but we don't have a solution yet. I think we can mark it as won't fix and when we eventually come up with a way of making it work then we will.

Sounds good. Closing as WF.


Call previously unused methods EnumType::parseValue() and EnumType::parseLiteral()

This pull request continues work done by @ruudk in https://github.com/webonyx/graphql-php/pull/1007 and opens up more flexible ways of implementing enum types. Previously, the methods EnumType::parseValue() and EnumType::parseLiteral() were defined but not used. Now they are used during the appropriate phases of query resolution, both simplifying the code and enabling overwrites.

@ruudk please review.

This week I'm busy with other things but I'll try to find some time next week to try this out. Thanks for this PR. 🙏🏻

Btw, I am targeting master/v15 with this pull request. Given there is slight potential of breakage, I wonder if we should even backport to v14.
I have tried out this branch in nuwave/lighthouse, where we have the EnumType implementation I previously mentioned to you. Everything seems to be fine.

I checked the tests and it looks good.
When merged I can also try it out by using the v15/dev version.

When merged

done!

It seems that I'm blocked by overblog/graphql-bundle not being compatible yet with dev-master. Would it be possible to also backport this to v14?

Nope, the potential for breakage is too high.


make cli to run tezos contracts with taquito

Problem
To achieve #61 we should be able to run tezos contracts directly from the node, this currently is not possible.
Solution
Instead of reimplementing the logic to talk to a Tezos RPC and handle things like waiting for confirmations, this PR proposes that we use taquito by making node CLIs that can be in the future called by the node itself.
Essentially an API to talk to Ligo contracts provided by the sidechain.
About code
I've used JSDoc to at least document the interface as IIRC typescript doesn't work well with esy sadly, also because this avoids a build step for now.
Related

#61

@anchpop that's exactly it, it sorts the payload by key, then drop the keys, because of how Ligo works all records are compiled in alphabetical order as { a, b, c, d, e } will become something like (pair (pair (pair a b) (pair c d)) e) the following. So we just use the values sorted by name that will duplicate the behavior from Ligo. Also don't like it but it works.
Opened an issue so that we on the future don't need to rely on duplicated logic for this.


Remove unwanted quotes in action output on Windows

Closes #23

@miyouzi, to be sure this fixes the issue, could you try this out by using this branch in your workflow?
    - name: Get tag message
      id: tag_data
-     uses: ericcornelissen/git-tag-annotation-action@v1
+     uses: ericcornelissen/git-tag-annotation-action@bug-23/quotes-with-windows

I have tried. It seems have some problems

Action output: https://github.com/miyouzi/aniGamerPlus/runs/3208708430
Commit here: https://github.com/miyouzi/aniGamerPlus/commit/8bc78dd199cc3a7d37e89b2c5bec6cd9945e57ad

Ah yes, forgot to point this out :sweat_smile: Because of the way run: values are parsed you need to change your "Test ENV" step to include quotes when echoing this action's output. If you don't do that it thinks the lines in the commit message are supposed to be commands.
    - name: Test ENV
      run: |
        echo $RELEASE_VERSION
        echo ${{ env.RELEASE_VERSION }}
        echo $RELEASE_TITLE
        echo ${{ env.RELEASE_TITLE }}
        echo $RELEASE_FILENAME
        echo ${{ env.RELEASE_FILENAME }}
        echo $TAG_MESSAGE
-       echo ${{ steps.tag_data.outputs.git-tag-annotation }}
+       echo '${{ steps.tag_data.outputs.git-tag-annotation }}'

Great ! It works well now ! Thank you very much ! ❤

And thank you for verifying the fix and initially reporting the bug!
I'll merge this now and release a new version. You can switch back to v1 as shown below once that is done :slightly_smiling_face:
    - name: Get tag message
      id: tag_data
-     uses: ericcornelissen/git-tag-annotation-action@bug-23/quotes-with-windows
+     uses: ericcornelissen/git-tag-annotation-action@v1

并感谢您验证修复并最初报告错误！
我现在将合并它并发布一个新版本。可以切换回v1如下图~一旦完成~ 现在 🙂
    - 名称：获取标签消息
      id：标签数据
-     使用：ericcornelissen/git-tag-annotation-action@bug-23/quotes-with-windows
+     使用：ericcornelissen/git-tag-annotation-action@v1

OK. Thank you !


The e2e tests for viewer-components-react are timing out

For some reason, e2e tests for viewer-components-react get cancelled. It looks like there is timeout after 60 min.
https://github.com/iTwin/viewer-components-react/pull/1042/checks?check_run_id=30186426650
This restricts pull request from getting merged.

@tejassutar2024, it looks like the job doesn't hand and is just taking too long... E.g. the first run managed to complete all but 2 tests until it hit the timeout... For the time being I just increased the timeout: https://github.com/iTwin/viewer-components-react/pull/1049. Will look into how to improve the job performance a bit later.


Echo 2. Generation wont find HA Bridge

Hello together,
i updated my echo dot second generation to a new Echo device.
But the echo wont find my HA Bridge devices.
When i connect the dot then all devices were found and they are controllable from both Echo devices.
But when i disconnect the dot ... the HA Bridge devices are gone on the Echo.
I resetet the Echo many times but im not able to find the HA Bridge :-(

the port must be 80

me too

Pleas turn on trace upnp in the bridge control panel and send me your log.

This is a duplicate of #810, Put any other info in that issue.


Views on top of inputs don't fire on_clicks

When I have a view that is positioned absolute over an input field the on_clicks on that view won't fire.
Consider this code:
use floem::{
    reactive::create_rw_signal,
    style::Position,
    view::View,
    views::{container, label, stack, Decorators},
    widgets::text_input,
};

fn app_view() -> impl View {
    let value = create_rw_signal(String::from(""));
    stack((
        container(text_input(value)),
        label(move || "Label on top")
            .style(|s| {
                s.position(Position::Absolute)
                    .inset_top(8.5)
                    .inset_left(7)
                    .background(floem::peniko::Color::rgba8(255, 0, 0, 150))
            })
            .on_click_cont(|_| {
                println!("Click continue");
            })
            .on_click_stop(|_| {
                println!("Click stop");
            }),
    ))
    .style(|s| {
        s.position(Position::Relative)
            .margin(10)
            .height(30)
            .items_center()
            .justify_center()
    })
}

fn main() {
    floem::launch(app_view);
}

This will render something like this:

A label with a red background is positioned on top of an input field.
this is what happens when you try to click on the label:

Note there is no print output in stdout in the terminal below. Neither for on_click_cont nor for on_click_stop.

Found what is happening
This is something specific to the click listener. Click is registered and marked as handled after both pointer down and pointer up. But before the pointer up is handled the input gets the pointer down event and requests to be active which means that it will receive prioritized events so the label never gets the pointer up.
If you use on_event_stop pointer down with the on_click then both fire because the label marks the event as handled after the pointer down and the input doesn't see the event.
I'm not sure this is really a bug so much as a specific weird case.

Run into the same issue using a dropdown widget:

Can't select "Two" from the list.
When selecting "Four" from the list, the button underneath the list registers a click.

@habics the issue with the dropdown is fixed in #376

@jrmoulton
Still the same issue unfortunately, here is the example that shows it:
use floem::reactive::{create_rw_signal, create_signal};
use strum::IntoEnumIterator;

use floem::view::View;
use floem::views::{h_stack, label, v_stack, Decorators};
use floem::widgets::dropdown::dropdown;
use floem::widgets::{button, checkbox};

fn main() {
    floem::launch(app_view);
}

fn app_view() -> impl View {
    let (counter, set_counter) = create_signal(0);
    let input_name = create_rw_signal("input".to_string());

    v_stack((
        dropdown_view(),
        checkbox_view(),
        input_text(input_name),
        label(move || format!("Value: {}", counter.get())),
        h_stack((
            button(|| "Increment").on_click_stop(move |_| {
                set_counter.update(|value| *value += 1);
            }),
            button(|| "Decrement").on_click_stop(move |_| {
                set_counter.update(|value| *value -= 1);
            }),
        )),
    ))
    .style(|s| s.padding(20.0))
    .style(|s| s.items_center())
    .style(|s| s.width_full())
    .style(|s| s.height_full())
}

pub fn input_text(buffer: floem::reactive::RwSignal<String>) -> impl View {
    floem::widgets::text_input(buffer)
}

#[derive(strum::EnumIter, Debug, PartialEq, Clone, Copy)]
enum Values {
    One,
    Two,
    Three,
    Four,
    Five,
}
impl std::fmt::Display for Values {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        f.write_fmt(format_args!("{:?}", self))
    }
}

pub fn dropdown_view() -> impl View {
    let show_dropdown = create_rw_signal(false);

    dropdown(
        move || Values::One,
        move |item| label(move || item).any(),
        Values::iter(),
        |item| label(move || item).any(),
    )
    .show_list(move || show_dropdown.get())
    .on_accept(move |_val| show_dropdown.set(false))
}

pub fn checkbox_view() -> impl View {
    let (is_checked, set_is_checked) = create_signal(true);
    checkbox(move || is_checked.get())
        .on_update(move |checked| {
            set_is_checked.set(checked);
        })
        .style(|s| s.margin(5.0))
}

@jrmoulton Now looking at this issue again, I feel like #379 might not be the right solution for it. on_click intercepts the PointerDown event bubbling by default actually caused an issue with dragging.
For @dominikwilkowski, it can be fixed by adding .on_event_stop(EventListener::PointerDown, |_| {}) on the label. The reason is that without stopping PointerDown bubbling from the label to the text_input, the text_input will make itself active and the next pointer events will only be sent to the text_input.
For @habics It's the same issue and it can be fixed by adding on_event_stop to the list in the dropdown widget.

Ok I checked this out and indeed this code works and fires the events:
use floem::{
    event::EventListener,
    reactive::create_rw_signal,
    style::Position,
    view::View,
    views::{container, label, stack, Decorators},
    widgets::text_input,
};

fn app_view() -> impl View {
    let value = create_rw_signal(String::from(""));
    stack((
        container(text_input(value)),
        label(move || "Label on top")
            .style(|s| {
                s.position(Position::Absolute)
                    .inset_top(8.5)
                    .inset_left(7)
                    .background(floem::peniko::Color::rgba8(255, 0, 0, 150))
            })
            .on_click_cont(|_| {
                println!("Click continue");
            })
            .on_click_stop(|_| {
                println!("Click stop");
            })
            .on_event_stop(EventListener::PointerDown, |_| {}),
    ))
    .style(|s| {
        s.position(Position::Relative)
            .margin(10)
            .height(30)
            .items_center()
            .justify_center()
    })
}

fn main() {
    floem::launch(app_view);
}

I don't see how that makes sense though. Why am I adding an on_event_stop event onto the label to make the other events work? That's neither obvious nor intuitive and I can't see any docs about this. Still feels like a bug or something we should fix @dzhou121

I also feel that simply reverting isn't a sufficient fix.

Maybe the simplest fix would be to have on-click require eventpropagation specifically for the pointer down.

If you put on_click on top of another on_click, it works as intended that only the top on_click will fire.
The actual issue here is the text_input makes itself active when receiving PointerDown. So a fix would be only making it active after it starts to drag.


Floating insert menu keyboard navigation fixes

Problem:
Tabbing in the floating insert menu to higlight the checkboxes would clear out the filter input text. Pressing enter while the checkboxes are higlighted would dismiss the dialog.

**Fix:**
I lifted the input text to be controlled state of the `FloatingMenu` instead of controlled internally by react-select. Then I needed a way to expose the current highlighted item, so I copied @Rheeseyb 's aria solution. Works loke a charm!
Commit Details:

Switched to react-winowed-select to get the latest version to access the aria event stream
new activelySelectedInsertOptionRef contains the highlighted insertion option
new state filterInputValue that holds the input text typed by the user
only call setFilterInputValue on legit input changes, do not allow clearing on input-blur
useHandleCloseOnESCOrEnter now submits onChange on Enter.

Rheese I'm gonna assume you approved this! ❤

Rheese I'm gonna assume you approved this!

Yeah I was just waiting on the answer to that question about closing it and maintaining the state. :+1:


IllegalArgumentException: unexpected url: /api/v1/users/me/presence

This exception seems pretty common; it seems like we're somehow passing in a relative URL?
https://sentry.io/zulip/zulip-mobile/issues/319501790/
IllegalArgumentException: unexpected url: /api/v1/users/me/presence
    at okhttp3.Request$Builder.url(Request.java:142)
    at com.facebook.react.modules.network.NetworkingModule.sendRequest(NetworkingModule.java:171)
    at java.lang.reflect.Method.invoke(Method.java)
    at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:363)
    at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:162)
...
(7 additional frame(s) were not displayed)

unexpected url: /api/v1/users/me/presence

We had an issue in a previous Beta, that we did a faulty check for the realm format, did not append the https:// and allowed white-space, which caused several issues to be reported. This is likely related.

I think it is fixed now.

Reopening, as it is happening again.
My guess will be that focusPing is being called when logged out, thus realm is ''


fix(externals): use version rather than the whole json

Current dependencies on/for this PR:

main

PR #18   👈

This comment was auto-generated by Graphite.


Version 5 core components discussion

In version 5, I would like to remove most of the components that are currently in version 4. The thinking here is that backpack-ui should contain the core building blocks for the UI. If we're talking about atomic design, then backpack-ui should contain mostly atoms and maybe some molecules that are reusable.
I did a quick audit of our UI and here's a list of components I think we can start with:

ad
avatar
button
checkbox
container
dialog / modal
divider (would replace border-bottom on a lot of things)
grid (container for CSS grid layout)
heading
icon
iconButton
image
input
moreLink
panel (maybe just a box with drop shadow? we have some UI that could fit this)
radio
shareButton
text (we have a handful of text components now, not sure if we should keep them grouped)
textarea
toast

There are probably some more molecule-type components that could be built with the atoms above and be kept in backpack-ui, like a shareMenu maybe, but I think first we figure out what the atoms are.
Are there any I missed? Any thoughts about this approach?

approach sounds good. I think we have a lot of repetition currently that could be broken down to these smaller pieces.
As far as thinking through all the smaller atom components that are needed I think this is a great start.
What we will probably want to firm up before we dive into v5 is the proper way to submit new components, ie starting with a PR that just describes the component with some screenshots. I think a solid process will keep the library cleaner and more concise

Yeah for sure. I definitely want to put rules in place to help define when something should be added and what it should have when added (i.e., test coverage, readme)

Should the larger molecules and/or organisms, more frequently reused complex components, be kept elsewhere in backpack , or otherwise, as an additional package(s)? I think you are right in that there really aren't very many of these larger components that are really reused more than a couple times.

@shawncothran I think those type of components you mention could be placed along site atom-type components in backpack with whatever approach we take in #617.


pyfr input folder doesn't contain pyfr.ini

The folder passed to the pyfr task flow doesn't contain ini file?

working on this, issue points to here, testing it now
https://github.com/Kitware/HPCCloud/commit/c463e7442cb3eebf0a8a34ee75ebcd25a1d97102#diff-c98089493a98f571e58bbac982b5da80R13


Fix depwarn on 0.5

String, Symbol, precision(BigFloat)
Also fix an incorrect use of unsafe_convert.
Requires a new tag of Compat.
Also includes https://github.com/stevengj/PyCall.jl/pull/260
Requires https://github.com/JuliaLang/Compat.jl/pull/192

General comment about passing julia object to C.
If you want to pass an julia object v to C in the same format it would have been passed in ccall as an argument of type T with explicit control of the object lifetime, the correct way to do this is (with the exception if T is Any since it is handled specially),
root = Base.cconvert(T, v) # this object controls the lifetime
cobj = Base.unsafe_convert(T, v) # this is the C value

The name of the pointer field comes from pointerfree. I can rename it to GC root if it's more clear.

Oh, right.   The cconvert function is very confusingly named, because I keep expecting it to act like convert; it's weird that cconvert(T, v) does not produce an object of type T.   Maybe gcroot would be a more descriptive name.

Maybe gcroot would be a more descriptive name.

gc_convert ;-p (not sure if it actually worth changing the name though....)
Another note is that pointer should generally be avoided whenever possible. It is usually only necessary for interacting with C code (ok, I admit I've used it to workaround LLVM vectorization issue......) and in such case the cconvert, unsafe_convert is much safer (despite possibly confusing names.....) and should automatically happen for ccall.

It's weird that cconvert(T, v) does not produce an object of type T.

It's true that it can return whatever type it feels like as long as it keeps the result of unsafe_convert on the same type alive. This indeed doesn't sound like what a *convert should do (except that it is part of the full conversion (cconvert + unsafe_convert) to a C object) so I now see why it is confusing.......... (started in 0.4 time, I've never seen the old interface and have naturally accepted the new one....)

Updated.
There is one API change here. I take this as it doesn't matter....

Coverage decreased (-0.5%) to 58.895% when pulling baa6180e4f0b1ce9f2418994ec9a6db3a1eee7d1 on yuyichao:0.5-deps into eb8d70a975689e71d0553ba7f29874cb41a8e870 on stevengj:master.

Yeah, using ByteString there on 0.5 should be fine.

Travis failure:
ERROR: LoadError: PyError (:PyObject_Call) <type 'exceptions.TypeError'>
TypeError('type() argument 1 must be string, not unicode',)

Probably the string conversion needs to be:
function PyObject(s::AbstractString)
    sb = String(s)
    if pyunicode_literals || !isascii(sb)
        PyObject(@pycheckn ccall(@pysym(PyUnicode_DecodeUTF8),
                                 PyPtr, (Ptr{UInt8}, Int, Ptr{UInt8}),
                                 sb, sizeof(sb), C_NULL))
    else
        PyObject(@pycheckn ccall(@pysym(PyString_FromStringAndSize),
                                 PyPtr, (Ptr{UInt8}, Int), sb, sizeof(sb)))
    end
end

and you can get rid of PyObject(::String).

............ python unicode coupled with julia string change ...........
Yeah, I only tested on python3.... I'll fix it soon.

Done

Coverage decreased (-0.07%) to 59.354% when pulling 6ff74153c417e4bacbccbf3dcc10f18c2e6396bc on yuyichao:0.5-deps into eb8d70a975689e71d0553ba7f29874cb41a8e870 on stevengj:master.

ping.

Thanks!


RubyLSP recieves requests for "fake" sorbet rbi files

Description
Reproduction steps

Create a new typed: true ruby file in a project that uses sorbet.
Have the vscode sorbet extension installed
Type TRUE and press F12 to move to its definition
Open the extension output terminal and observe the error

024-07-30 12:24:35.677 [info] (ruby-lsp) [Error - 12:24:35 PM] Request textDocument/semanticTokens/range failed.
2024-07-30 12:24:35.677 [info] (ruby-lsp)   Message: /home/user/code/ruby-lsp/lib/ruby_lsp/store.rb:44:in `get': sorbet:https%3A//github.com/sorbet/sorbet/tree/090ed6096a83dd7a5fe52bd3f9338c1eca5178eb/rbi/core/constants.rbi (RubyLsp::Store::NonExistingDocumentError)
	from /home/user/code/ruby-lsp/lib/ruby_lsp/server.rb:393:in `text_document_semantic_tokens_range'
	from /home/user/code/ruby-lsp/lib/ruby_lsp/server.rb:46:in `process_message'
	from /home/user/code/ruby-lsp/lib/ruby_lsp/base_server.rb:128:in `block in new_worker'

  Code: -32602

Notice the uri: sorbet:https%3A//github.com/sorbet/sorbet/tree/090ed6096a83dd7a5fe52bd3f9338c1eca5178eb/rbi/core/constants.rbi
The location doesn't actually exist and is probably provided on-demand by the sorbet extension yet ruby-lsp still tries to look it up in its index.
I don't notice anything else wrong except for the error happening. Don't think there is user impact but something unexpected is happening.

Thanks, I can reproduce.

We can probably fix this by returning early if uri.scheme != 'file'.

If possible, I would avoid restricting the scheme. For example, when you are using VS Code's diff editor, the files being compared do not use the file scheme, but the git one. Providing proper highlighting, hover and go to definition on that scheme is nice because it makes reviewing diffs a bit more complete.
It's hard to anticipate what other schemes will be used. As another example, maybe code blocks inside Copilot chat windows will have their own URI scheme too and we would like to provide features there. While I'm not sure if the VS Code team is looking into this, it would further integrate the LLM experience to language server features.
My suggestion is to suppress any output related to this error since it's expected to happen on certain scenarios.


Trying to get the ConfiguredSlaDomain from the command Get-RscMssqlInstance -HostName but gets null

When running Get-RscMssqlInstance -HostName <IP_ADDRESS> -Debug we can see the assigned SLA but not with the regular command, then its null.
Any ideas why? BUG?
Get-RscMssqlInstance -HostName <IP_ADDRESS>
AuthorizedOperations              :
ObjectType                        : MSSQL_INSTANCE
SlaAssignment                     : DIRECT
ConfiguredSlaDomain               :
EffectiveRetentionSlaDomain       :
EffectiveSlaDomain                : RubrikSecurityCloud.Types.GlobalSlaReply
PendingSla                        :
ReplicatedObjects                 :
HasLogConfigFromSla               : True
HostLogRetention                  :
Id                                : 92cde7-a83a-56cb-a355-3138d54
LogBackupFrequencyInSeconds       :
LogBackupRetentionInHours         :
Name                              : MSSQLSERVER
NumWorkloadDescendants            : 5
ReplicatedObjectCount             :
SlaPauseStatus                    : False
UnprotectableReasons              :
AllOrgs                           :
Cluster                           : RubrikSecurityCloud.Types.Cluster
CrossAccountReplicatedObjectInfos :
DescendantConnection              :
EffectiveSlaSourceObject          :
LatestUserNote                    :
LogicalChildConnection            :
LogicalPath                       :
PendingObjectDeletionStatus       :
PhysicalPath                      : {<IP_ADDRESS>}
PrimaryClusterLocation            :
SnapshotDistribution              :
Vars                              : RubrikSecurityCloud.Types.MssqlInstance+InlineVars

The SLA that is in effect can be found in the EffectiveSLADomain object. In that object you can see the ID and Name of the SLA that is currently assigned to the object and in use.
Closing this issue out, reopen if this needs an additional fix.


Pushing not working: "LF will be replaced by CRLF"

Whenever I try to push, this error shows up:
Uncaught (in promise) Error: warning: LF will be replaced by CRLF in .obsidian/plugins/obsidian-citation-plugin/main.js.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in .obsidian/plugins/obsidian-citation-plugin/styles.css.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in .obsidian/plugins/templater-obsidian/main.js.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in .obsidian/workspace.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in proton.md.

the error message goes on for lots of files, possibly every file in the vault, and ends on this:
warning: LF will be replaced by CRLF in fonction (math).mapp.js:1), <anonymous>:2304:85)
    at GitExecutorChain.eval (eval at <anonymous> (app.js:1), <anonymous>:2295:28)
    at Generator.throw (<anonymous>)
    at rejected (eval at <anonymous> (app.js:1), <anonymous>:2249:65)

The initial commit worked, and I checked and realized that no push ever worked since.
Any help/idea is appreciated.
on Windows 10 x64

Hi @uuuser-name
I recently got the same error message from git on MacOS.
Here is my understanding of the problem and how I fixed this issue.
Why?
TLDR;
Here is the long story:  http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
Workaround
# Replace all `CR``LF` with `LF` (keeping dates unchanged)
find .obsidian/plugins -type f | xargs dos2unix -k

git add .obsidian

If you do not have dos2unix you can install with brew (a package manager), like so:
brew install dos2unix
Solution
The ideal solution IMHO would be for plugin authors to use the following git configuration:
On Windows: git config --global core.autocrlf true
When committing a text file to the repository git replaces CR+LF with LF.
When checking out a text file from the repository git replaces LF with CR+LF.
Working Directory =========> Repository
                              CRLF ==> LF

Working Directory <========= Repository
                              CRLF <== LF

On Linux and MacOS: git config --global core.autocrlf input
When committing a text file to the repository git replaces CR+LF with LF.
When checking out a text file from the repository git does not do any replacement.
Working Directory =========> Repository
                              CRLF ==> LF

Working Directory <========= Repository
                              No Change

Sources

https://stackoverflow.com/q/3206843/386517
http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
https://docs.github.com/en/github/using-git/configuring-git-to-handle-line-endings

As you are on Windows, you can give these dos2unix alternative a try:

https://stackoverflow.com/questions/20368781/anything-like-dos2unix-for-windows
https://koenaerts.ca/dos2unix-equivalent/

Closing because of no response of @uuuser-name .

this is an installation setting when installing Git. What is the ideal setting when using Obsidian and GIT in Windows?

This article from github gives IMHO a good overview of the suggested default for git users.
Make sure to select Window in the top menu beforehand.

Hey there. I am on windows as well and I am getting the same issue as above, although I can push no problem. ie. I have the setting @ebouchut  suggested set to true by default I constantly see files that I haven't changed appear as they are changed. I think obsidian is touching these files and messes with their original line endings. Whenever I commit those files, git is changing those back and discards the changes, therefore I am not committing anything on those files. As you can understand I am seeing ghost changes triggered from obsidian which is annoying. Could we have obsidian respecting the line endings instead of changing them to unix?

I came here for ghost changes and warnings.
My Problem was probably that I just used SmartGit and hadn't a Git Bash installed.
When installing this I think git config --global core.autocrlf true was set like suggested some times.
For now this seems to remove the ghost changes at least.
But sadly I still have a warning for every commit.
I am wondering why there is never a finale statement on any discussion clearly stating this:
E.G. in the Forum there is also an unfinished discussion.
So it is probably not solved yet?

I'm about to be tortured crazy by this feature. It turns out that there is no simple solution to this problem, thank you.

This is seemingly a workaround, and im not sure it fits every case. However on a windows machine, try creating new folder, and new dummy files within that folder - if you can commit that, then make replica folders of those throwing issues, and move the files over.
That solved the issue for me, and i can use git obsidian now.


Upgrade guide from 6.17.0 to 6.28.1

Hello @yajra
Is there any breaking changes when upgrading from the noted versions?
As I have upgraded recently and it seems the filterColumn custom DB column names is not working as expected.

Yes there are. Please see http://yajrabox.com/docs/laravel-datatables/7.0/upgrade for details. Thanks!

Oh my bad, it's v6..  Reviewing...

AFAIK, I think there was a recent drop on dompdf dependency that may have cause a breaking change..
Found the thread: https://github.com/yajra/laravel-datatables/pull/1026
Aside from this, I think there is no breaking change added.

Looking at merge PR's and seems fine with me: https://github.com/yajra/laravel-datatables/pulls?utf8=✓&q=is%3Apr is%3Aclosed [6.0]

@yajra Thanks for the details. What do you suggest to get the custom column naming and filter work again in the newer version?
BTW, How we can downgrade to 6.17.0?

To downgrade, I think you can just specify 6.17.0 on composer and do an update.
For filterColumn, just use the same name you used on javascript.


RMD file upload for ScholarSphere deposit not working

Both the user and I have tried to upload a file for publication 512607. I'm getting the error message: "We're sorry, but something went wrong. If you are the application owner check the logs for more information."
Here is the file: GCA-D-22-00332_R1-clean.pdf
I used this feature successfully on Friday, and I see a few successful ScholarSphere work deposits from this morning (but perhaps not as many as I'd expect for the 179 emails that went out).

There are some bugs causing ScholarSphere upload errors that I've fixed in this PR: #589

@anaelizabethenriquez This is fixed and deployed to production.


Patch 1

Regex improved and also modified because there were a single space between all HTML tags
Inline JS and CSS compression feature added.
Stopped inline scripts from being skipped. However I hope to know what you have skipped them from the first place, so I can consider that either.
I will provide modification for the other two skipped items after some tests. In my opinion there is no need to skip the whole file from being compressed, because of some trouble-making codes.

This won't work if blade code generates the inline css/js.

Use the minification middleware to minify inline content.

https://github.com/GrahamCampbell/Laravel-HTMLMin/blob/master/src/Http/Middleware/MinifyMiddleware.php

This won't work if blade code generates the inline css/js.

My blade code is generating inline css/js and I have no problem using either your code (force mode) or my improved one, because both of them are working fine. I think you had better take another look. Wish I could see the blade code you get problem with, in programming world nothing is impossible to get solved.

Use the minification middleware to minify inline content.

You know better that using that affects performance in a bad way. I prefer compression at blade compile time which is get cached after that.


Update import rule to not require parent directories

Changes
Updated the common and server-common import rule to not require parent directory directory tokens.
Motivation
We encounter this scenario now, and it seems like VSCode will auto-import with no parent directories sometimes. We still want to fix the path to not have a src.
Testing
I added two unit tests to cover this case.

@drew-vanta Does this apply to imports into web?


Issue with /docs/user-guide/walkthrough/

This is a...

[ ] Feature Request
[x ] Bug Report

Problem:
After following instructions, when trying to deploy a pod i get the following:
[root@km01 nginx]# kubectl create -f pod-nginx.yaml
Error from server (ServerTimeout): error when creating "pod-nginx.yaml": No API token found for service account "default", retry after the token is automatically created and added to the service account
Proposed Solution:
Page to Update:
https://kubernetes.io/docs/getting-started-guides/centos/centos_manual_config/

kubernetes-master-1.5.2-0.2.gitc55cf2b.el7.x86_64
kubernetes-client-1.5.2-0.2.gitc55cf2b.el7.x86_64
kubernetes-1.5.2-0.2.gitc55cf2b.el7.x86_64
kubernetes-node-1.5.2-0.2.gitc55cf2b.el7.x86_64

[root@km01 nginx]# uname -a
Linux km01.home.local 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@km01 nginx]# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core)
Tried repo from the document first, then stock centos repo, both had exact same results.

@rriouxr Are you still experiencing this issue?

@rriouxr Are you still experiencing this issue?

Honesty I moved on from the issue. I believe I switched OS'es ...


[Github] Label 'New-Run Plugin'

Would it make sense to have such a label?

we have new feature and Run - plugin.  those two == what this is


Cell tree phylogeny format

Format In the phyloXML format we need to specifiy the following fields:

species with a name for the species the cell belongs to;
epi-state with a +/- value
sampling if we intend to dump a uinque phylogenetic tree for a simulation with multiple samples collected over time and space, we need a unique code that tells us when and where the cell has been sampled.

That is all we need to identify cell states.
Branch length
I still need to understand though if our current tree is actually modelling branch length as standard in phylogenies  -- I suspect no.
Right now I believe that the dots are past cell division events, so branch length models the number of divisions. Instead, in a phylogeny, the length of each branch should report the number of mutations that have accumulated.
It would be best to have both info in our model:

cell division events  + internal cell states, so we know past states of cells etc
a distance of n if there have been n mutations accumulated between the cell i to i+1 (in a single-division)

Unfortunately, the standard phyloXML does not appear to support extensions. Hence, we can add tags, but none but our tools will be able to deal with them.
The proposed sampling tag is only meaningful in the phylogenetic tree leaves.
About the branch length: at the moment, the phylogenetic tree is produced before the mutation simulation. Each dot represents a cell birth, and the length of an edge depicts the cell life span. An edge connects two cells if they are in parent/child relation.
If we want a tree whose branch lengths depend on the number of mutations, we must simulate the mutations first and then produce the tree.
Why do we need all these pieces of information about the tree? Do we want to plot it? Do we need to pass the tree to another tool? In the former case, we do not need to export all these pieces of information in XML to reload them and plot the tree.

Unfortunately, the standard phyloXML does not appear to support extensions. Hence, we can add tags, but none but our tools will be able to deal with them.

It is OK if we add tags that our wrapper tools can interpret. In the same way now you have added the colour scheme, we can add any tag that is important for other tools to plot.

The proposed sampling tag is only meaningful in the phylogenetic tree leaves.

Yes, of course.

About the branch length: at the moment, the phylogenetic tree is produced before the mutation simulation. Each dot represents a cell birth, and the length of an edge depicts the cell life span. An edge connects two cells if they are in parent/child relation. If we want a tree whose branch lengths depend on the number of mutations, we must simulate the mutations first and then produce the tree.

I understand, and in fact what we plot now is the tree of cell divisions, not a cell phylogeny. Both are useful, but a phylogeny by definition always reports the number of mutations among species as branch length.

Why do we need all these pieces of information about the tree? Do we want to plot it? Do we need to pass the tree to another tool? In the former case, we do not need to export all these pieces of information in XML to reload them and plot the tree.

We generally need all these pieces of information because we want to take sequencing data (bulk/single-cell etc) to make inferences about the process. Essentially we want to infer stats from this tree, which is the reason need to dump all this data to disk for wrapper tools to load them (post hoc), and compute statistics.
An example of what one might want to do is: https://en.wikipedia.org/wiki/Coalescent_theory

I understand, and in fact what we plot now is the tree of cell divisions, not a cell phylogeny. Both are useful, but a phylogeny by definition always reports the number of mutations among species as branch length.

So let us produce two different trees.

We generally need all these pieces of information because we want to take sequencing data (bulk/single-cell etc) to make inferences about the process. Essentially we want to infer stats from this tree, which is the reason need to dump all this data to disk for wrapper tools to load them (post hoc), and compute statistics.

My point was: "Do we really need to reverse all these pieces of information in an XML file or provide API to get them directly from the RACES structures?" What if our tree nodes store the cell ids and we have a function species(cell_id)?

Sure that is a possibility. I think that if we go for the API approach then all these things will become APIs.


Refactor setting of property

tests/integration/components/sl-modal-test.js
Change this.set( 'isOpen', 'initial Value' ); to this.set( 'isOpen' ); in the "Property isOpen is set appropriately" test.

@notmessenger please assign to me.

Closed by https://github.com/softlayer/sl-ember-components/pull/738


fix: app url in terms is incorrect

Description of the Changes
export the app URL accordingly to the env
Checklist

[ ] Changes have been done against master branch, and PR does not conflict
[ ] New unit / functional tests have been added (whenever applicable)
[ ] Test are passing in local environment
[ ] Docs have been updated
[ ] PR title is follow the Conventional Commits convention: <type>[optional scope]: <description>, e.g: fix: prevent racing of requests

This change is

:tada: This PR is included in version 1.7.0-dev.5 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Digital Twin KIT, Request for some changes

Description
I would like to request some changes to the data in the submodel descriptor, because the current status is IMHO unneccessarily restrictive. The current template looks like this:
{
  "id": "urn:uuid:e5c96ab5-896a-1234-8761-efd74777ca97",
  "idShort": "myAas",
  "specificAssetIds": [
    {
      "name": "manufacturerPartId",
      "value": "123-345-567103",
      "externalSubjectId": {
        "type": "ExternalReference",
        "keys": [
          {
            "type": "GlobalReference",
            "value": "{{BPN of the party privileged}}"
          }
        ]
      }
    }
  ],
  "submodelDescriptors": [
    {
      "id": "e5c96ab5-896a-482c-8761-efd74777ca97",
      "semanticId": {
        "type": "ExternalReference",
        "keys": [
          {
            "type": "GlobalReference",
            "value": "urn:bamm:io.catenax.material_for_recycling:1.1.0#MaterialForRecycling"
          }
        ]
      },
      "endpoints": [
        {
          "interface": "SUBMODEL-3.0",
          "protocolInformation": {
            "href": "https://edc.data.plane/mypath/submodel",
            "endpointProtocol": "HTTP",
            "endpointProtocolVersion": [
              "1.1"
            ],
            "subprotocol": "DSP",
            "subprotocolBody": "id=123;dspEndpoint=http://edc.control.plane/api/v1/dsp",
            "subprotocolBodyEncoding": "plain",
            "securityAttributes": [
              {
                "type": "NONE",
                "key": "NONE",
                "value": "NONE"
              }
            ]
          }
        }
      ]
    }
  ]
}

Request 1: Please make the usage of the asset id in the "subprotocolBody" non-mandatory / optional
As we know, an AAS is typically created and readable for multiple partners. I.e the "specificAssetIds" section contains several entries, but not all of them are meant to be visible for all partners. However, the entries in the "submodelDescriptors" section, are readable for all partners that have any access to this AAS. That means, they would have to be the same for all partners.
Currently, we are required to state an EDC asset Id in the "subprotocolBody" field, that works for all partners. In the explanatory text, it is further stated, that the participants are expected to request the catalog from the control plane via its protocol url. So far so good. But then it is further pointed out, that the participants are expected to filter the catalog for that specific asset id.
My objection with this way of identifying the wanted asset in the catalog is, that it`s too restrictive. As we all know, it is equally possible (and to my best knowledge probably even more common) to filter the catalog for a set of given properties. After all, even the registration of the DTR asset uses a set of properties that allow for the identification of the DTR asset in an EDC catalog, see this excerpt:
{
...
"properties": {
    "dct:type": {
      "@id": "cx-taxo:DigitalTwinRegistry"
    },
    "cx-common:version": "3.0",
    "asset:prop:type": "data.core.digitalTwinRegistry"
  },
...
 }

The point is now, that various submodels (like for instance the ItemStock Submodel) have defined their own set of properties criteria that are currently used to identify them in the EDC catalog. The big advantage of this approach is, that it allows us, to register one ItemStock Submodel asset per partner.
Since we are making use of BPNL-restricted policies in our project, this guarantees, that each partner who reqeusts a catalog from a partner's EDC control plane, will only get to see that single asset, that was registered specifically for him, in the catalog he then receives.
Now the real adavantage of that approach is the following: Since we create an ItemStock submodel asset per partner at the EDC, we can assign a partner-specific "baseUrl" within the "DataAddress" field.
This is a great security feature, because it makes it technically impossible that any partner can claim any other BPNL but his own. That means, it is not possible that Partner A with his BPNL1234567890ZZ can send a request to the asset endpoint while claiming that his BPNL is, for instance the BPNL of another Partner B with BPNL0987654321AA.
The EDC policy framework in combination with the MIW are guaranteeing here, that the asset is only reachable for exactly the partner, we want to respond to.
That means, the backend server, that implements and provides the services for the ItemStock submodel can fully trust in the fact, that the sender of a request is no one else but exactly the partner with the BPNL, that is encoded in the baseUrl.
However, this nice and very sensible approach would be made impossible, if we were forced to have only one single asset (with only one single asset id!).
Therefore, I would like to request that the usage of the id that we are required to specify in the AAS in the "subprotocolBody" field is no longer mandatory but optional.
Request 2: Please make the usage of the "href" field non-mandatory / optional
Currently, the "href" field requires us to specify the public URL of a data plane, where the submodel can be accessed. To be honest, that is in fact not needed. Let us recall, how the access to an EDC asset in general works:
Firstly, we do a request for a catalog via the protocol URL of a specific partner.
Then we pick the asset we want from that catalog. After that, we negotiate for a contract with that partner's control plane, that allows us to access the asset. After the contract is agreed upon by both sides, we can request a transfer. If you are choosing the pull transfer variant (this is what we do here), then we are sent JSON data object, that contains all information we could possibly need. It looks like this:
{
  "id": "591bb609-1edb-4a6b-babe-50f1eca3e1e9",
  "endpoint": "http://localhost:29291/public/",
  "authKey": "Authorization",
  "authCode": "{{auth-code}}",
  "properties": {
    "cid": "1:1e47895f-9025-49e1-971d-eb865c38d540"
  }
}

Example from the official EDC Samples
As you can see, it contains not only the authKey/authCode data that are needed for authorization of the request at the providing partner's data plane. It also contains the URL, where these credentials can be used.
The thng is: All of these steps need to be executed anyways. I.e. we will always have to negotiate for the asset and then request the above mentioned credential data, if we want to access the given asset.
That means, we are always automatically given information about the URL of a data plane public API. So there is simply no need to specify any data plane URL in the "href" field of the submodelDesciptor.
Beyond that, this requirement also sadly ignores the fact, that any partner, who runs an EDC, is free at any time to register additional data plane - instances to his control plane. That means, we always have to account for the possibility, that the data plane URL that is stated in the submodelDescriptor may become outdated, because the owner of the remote EDC control plane had to replace it with a different data plane instance.
My request here in the short term is the fowllowing:
Please make the usage of the data plane URL stated in the "href" field optional, when instead the data plane URL that is received alongside the credential JSON object (see above) is used.

Hi @eschrewe
regarding your request number 1:
Would it be an option for you to have the following structure?
1 asset, 2 (or n) policies, 2 (or n) contractdefinitions
With this, you do what is described with 1 asset (or better dataset id) in the subprotocolbody field and depending on who (BPN) looks up the catalog can see (or not) a result, based on what you have configured in the policy.
A contractdefinition basically links 1 asset and 1 policy together that results in an Offer in the Catalog.
That means you can have multiple such policies. Each for every BPN you want to grant access and still use the same asset.
Would this help in your situation?
--
Matthias Binzer

Hi @eschrewe regarding your request number 1: Would it be an option for you to have the following structure?
1 asset, 2 (or n) policies, 2 (or n) contractdefinitions
With this, you do what is described with 1 asset (or better dataset id) in the subprotocolbody field and depending on who (BPN) looks up the catalog can see (or not) a result, based on what you have configured in the policy.
A contractdefinition basically links 1 asset and 1 policy together that results in an Offer in the Catalog. That means you can have multiple such policies. Each for every BPN you want to grant access and still use the same asset.
Would this help in your situation?
-- Matthias Binzer

Hi @matgnt ,
thanks for your input. I am aware of the fact, that a single asset can be tied together in a contractdefinition with multiple policy defintions.
What I didn't know however, when I wrote that Issue one week ago was, that the BPNL also gets automatically inserted in the HTTP Header (key: "edc-bpn"), when it is forwarded by the Data plane during a transfer request. But luckily someone hinted me on that a short time later :)
That means, on my backend server I can evaluate that Header entry and I can trust on the fact, that the EDC has confirmed that the sender of that message is indeed the owner of that BPNL. So in fact, there is a proper alternative to the approach that I was describing above.
However, in principle the point, I was trying to make there, still stands:
Is is really neccessary to be restricted to one single asset id, that must be valid for all participants?
I think the details on how a wanted submodel EDC asset is to be identified in the EDC catalog should be made left to be laid out in detail within the respective specifications of each submodel.
Any client, who finds a GlobalReference, that points to a certain submodel (in the example above, for instance: "urn:bamm:io.catenax.material_for_recycling:1.1.0#MaterialForRecycling") needs
a) to know what this submodel is all about and why and when he might want to use it,
b) to lookup all further details for proper interactions with that submodel
Both of these things can only be solved by reading the detailed specification of the given submodel anyways. The best thing, the DTR can possibly do is, in my opinion to give a link to the official documentation of the submodels.

Hi @matgnt ,

As I understand your request, you would additionally allow something like:
"subprotocolBody": "asset:prop:type=data.core.digitalTwinRegistry;dspEndpoint=http://edc.control.plane/api/v1/dsp",

sorry no, that's not what I'm proposing or requesting. My request is, that the DTR KIT should simply remain neutral on the issue, how an EDC asset (that is offering a submodel service) can or should be identified within an EDC catalog.
All details in this regard should be exclusively described in the respective specification of each submodel.
As I pointed out, anyone who, finds for instance the "urn:bamm:io.catenax.material_for_recycling:1.1.0#MaterialForRecycling" submodel within an AAS, needs to lookup and know that submodel's detailed specification anyways in order to make proper use of it.
I'm not a big fan of either of these two ways. But I am raising the question, whether it is wise or neccessary to make one of these ways de facto mandatory.
So in essence, my proposal would look more like this:
"subprotocolBody": "http://edc.control.plane/api/v1/dsp"

Providing the EDC protocol URL, where that specific submodel asset can be obtained, is in general a good idea in my opinion, because it allows for the possibility that the submodel is not registered on the same EDC connector as the DTR's api asset. I.e. the EDC connector which is hosting the DTR, where we got a certain AAS from a partner, does not have to be the same where all the submodel API assets are registered.
On a minor sidenote, I think it's also in general not a good idea to put two different informations in one single JSON-string field, separated only by a semicolon. This makes deserialization more error prone. If both of these informations were equally important, why not give them a separate JSON key each? But that's far besides the point I am making here. In my opinion, the protocol URL alone is sufficient here.
But apart from that, I'd actually be very interested in hearing your thoughts on my other request too, @matgnt  :)

Hi @eschrewe

sorry no, that's not what I'm proposing or requesting. My request is, that the DTR KIT should simply remain neutral on the issue, how an EDC asset (that is offering a submodel service) can or should be identified within an EDC catalog.

All details in this regard should be exclusively described in the respective specification of each submodel.

I think this should be avoided. It kind of delegates the 'logic' even further away from the AAS logic.
AAS and its clients in general don't know anything about a Dataspace protocol and that they need to negotiate a data usage contract first. We in Catena-X make this mandatory, spec-wise by the standards that we publish and technically, by the information "subprotocol": "DSP", so that a client understands what needs to be done.
In what you propose, we would need to further distinguishe the logic, by e.g. introducing "subprotocol": "DSP-materialforrecycling". Which is possible, but I think this delegates logic into too tiny use cases. AAS started with a more higher level concept and we should not go too far away from it.

Providing the EDC protocol URL, where that specific submodel asset can be obtained, is in general a good idea in my opinion, because it allows for the possibility that the submodel is not registered on the same EDC connector as the DTR's api asset. I.e. the EDC connector which is hosting the DTR, where we got a certain AAS from a partner, does not have to be the same where all the submodel API assets are registered.

This is a general topic to discuss. We thought about not doing this, but rather using the BPN here, which goes more into the direction you thought, right?
I personally prefer not to have to many CX specifics in here. The goal is to make this a standard way of connecting AAS and Dataspace protocol. If we would introduce BPNs and consequently the BPN lookup services here as well, there is no chance to get this accepted as a broader standard - and this should be the goal for better interoperability!

On a minor sidenote, I think it's also in general not a good idea to put two different informations in one single JSON-string field, separated only by a semicolon. This makes deserialization more error prone. If both of these informations were equally important, why not give them a separate JSON key each? But that's far besides the point I am making here. In my opinion, the protocol URL alone is sufficient here.

Absolutely agree here! The only reason we did it like that, was the limitation of the AAS standard. Our goal in CX is to be AAS compliant. Separate fields are not supported in AAS, but subprotocol fields is a standardized field and is e.g. used in OPC UA. In the future - I hope - we can integrate more specific fields in the AAS standards to better align the Dataspace Protocol and the AAS - not only for us in CX, but also other Dataspaces to come :-)

But apart from that, I'd actually be very interested in hearing your thoughts on my other request too, @matgnt :)

I just wanted to finish part 1 to not mix too many questions :-)
But since you ask :-)
Short answer: href is mandatory in AAS standards
https://industrialdigitaltwin.org/wp-content/uploads/2023/04/IDTA-01002-3-0_SpecificationAssetAdministrationShell_Part2_API.pdf
(I hope this is the correct link to the latest docs...)
Longer answer: For a client it should be completely invisible whether there is a EDC data plane, or any other API Gateway or an integrated-into-the-AAS-server in place. A Client just fetches the data from what is referenced in the href - as it does in any other AAS use case outside of CX. The only difference in CX is, that we have a special Auth-Token in the Authorization header - which is the result from the Dataspace Transfer process.
Right now, many implementations use the EDC data plane, but in the future, many solutions will implement that token check into existing API gateways or existing AAS Servers. The logic doesn't do much. Just a JWT token check with round about 20-40 lines of code.


Create and show publish permissions for snippets with DraftStateMixin applied

Fixes #9720.
Use the post_migrate signal to create Permission objects with the publish_rawmodelname codename for models with DraftStateMixin applied. This ensures that after a migrate run, such models have their corresponding permissions in the database. If developers have already created the permissions, then we ignore the creation.
In addition, we now show the "Publish" permission as part of the main permissions in the "Object permissions" section of the Group edit form, instead of being put in the "Custom permissions". This column only shows up if any of the models have the publish permission in the database, which means that it normally won't show up if none of the models extends DraftStateMixin.
Before
(if the publish permissions haven't been created, or if none of the models has DraftStateMixin)

After

Refs:

https://github.com/django/django/blob/d526d1569ca4a1e62bb6a1dd779d2068766d348c/django/contrib/auth/management/__init__.py#L21-L34
https://github.com/django/django/blob/64b3c413da011f55469165256261f406a277e822/django/contrib/auth/apps.py#L19-L22
https://github.com/django/django/blob/64b3c413da011f55469165256261f406a277e822/django/contrib/auth/management/__init__.py#L37-L106

Please check the following:

[x] Do the tests still pass?[^1]
[x] Does the code comply with the style guide?

[x] Run make lint from the Wagtail root.

[x] For Python changes: Have you added tests to cover the new/fixed behaviour?

Please describe additional details for testing this change.
[^1]: Development Testing
[^2]: Browser and device support
[^3]: Accessibility Target

Merged in 1f143cf8ca5b65c91a77cfb7aa625c82d10cc2f3


Slow loading on macOS Catalina

Bug Report
Current Behavior
fish-shell loading very slow or never (sometimes, most of time slow loading times)
Expected Behavior
It should load fast as default theme
Relevant Fish Configuration

set -g fish_user_paths "/usr/local/sbin" $fish_user_paths

Environment

Spacefish version: [the output of echo $SPACEFISH_VERSION]: 2.7.0
Fish version: [the output of fish --version]: fish, version 3.0.2
Fish plugin manager: [e.g. oh-my-fish, fisher, fin]: oh-my-fish
Terminal emulator: [e.g. iTerm, Hyper, Terminator]: iTerm
Operating system: [e.g. OSX 10.13.4, Windows 10]: macOS Catalina 10.15.1 (Latest update)

Possible Solution
If Docker (Dinghy) enabled, loads fast. When disabled very sloow.
Additional context/Screenshots
Add any other context about the problem here. If applicable, add screenshots to help explain.
Related issue: https://github.com/fish-shell/fish-shell/issues/6408

Setting set -g SPACEFISH_DOCKER_SHOW false in config helped for me.
I sure, if it matches docker-compose.yml in folder, waiting for Docker for version.

Hi @dalisoft. Thank you for opening an issue.
Unfortunately, spacefish is no longer under active development, but I suggest you take a look at its successor https://github.com/starship/starship, which has considerably faster loading times.
That said, if someone comes around with a PR to fix this bug, I'll gladly review and merge it. 😄

Thanks for response. Currently passing env is workaround. Starship also does not have Docker support, so seem removing that little faster, but cannot replace this awesome shell prompt/theme.
We can close this issue, workaround have, but I don’t have time to PR (sorry)


Feature: Add/Remove network adapters from VM's

This will allow you to manage the network lifecycle for your VM

initial release for 0.3.0 milestone


ROX-16906: Swap to MA images for AdmissionControllerTest

Upated GCR nginx image to multi-arch nginx image hosted on quay.io, for AdmissinoControllerTest

/test ocp-4-10-qa-e2e-tests
/test ocp-4-12-qa-e2e-tests

Closing this PR since the MA changes were added as part of https://github.com/stackrox/stackrox/pull/6826


Typespec too aggressive in prepass

No longer change the value info in Prepass during TypeSpec.
This was leading to some instruction to be typespec'ed too aggressively and thus removing some bailouts.

Hold off on this review. I found an introduced bug by this. I am investigating it right now.


feat(backfill): do not require at least 1 record to be read per epoch, if rate limit enabled

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
We have a requirement to read at least 1 record per barrier from snapshot for backfill.
This means we are forced to have the following distribution in our stream:
barrier -> record -> barrier -> record -> barrier

Which means the barrier latency is tied to processing times for the records.
In cases where the processing time is long, e.g. UDF with high latencies, the barrier latency will spike as well.
In the associated test case, we show that when UDF calls have 5s latency, the test should take a long time to complete.
This occurs even when rate limit set, disrupting its usefulness.
The solution is to check if rate limit can currently read a record, before applying the read at least 1 record per epoch step.
If it can't, just skip over. Eventually we will get to read a record.
If it can, then continue to apply this step.

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

I didn't get it.
The motivation of requiring at least 1 record to be read per epoch is to prevent the livelock of scanning from storage #12780

This is so we don't lose tombstone iteration progress for that epoch.

The problem exists regardless of whether rate limit was enabled or not. They are unrelated. Don't understand why associating them together.

Let me guess. Suppose you met a case that event 1 record per epoch is unacceptable. If so, I believe we should find a better implmentation for #12780, such as holding a delete-tomb-aware iterator, or something like that.
Fixing a new problem while creating an known problem sounds bad to me.

Let me guess. Suppose you met a case that even 1 record per epoch is unacceptable. If so, I believe we should find a better implementation for #12780, such as holding a delete-tomb-aware iterator, or something like that.
Fixing a new problem while creating an known problem sounds bad to me.

This PR does not lead to any regression. Consider the case when we don't read at least 1 record. This is when rate limiter tells us that we have hit the snapshot read rate limit, and should not read a new record.
That's totally fine, because subsequently, when rate limit capacity frees up, we can apply this requirement of 1 record per epoch again.
1 record per epoch is unacceptable in cases where the latency of processing a single record is high. If we apply rate limit to this scenario, it still can't change the distribution of the stream.
After this PR however, we can make the distribution like so instead if rate limit is set:
barrier -> record -> barrier -> barrier

The provided test case will take an extremely long time without the fix in this PR.
For sure we can have this:  such as holding a delete-tomb-aware iterator, or something like that.
But this is much more complex than the current solution, which already fixes the issue without causing any regression.

Does 1.9.0 need to war for this or included in minor version is also ok?

Does 1.9.0 need to war for this or included in minor version is also ok?

Minor version is ok


nixos: append ccid as a plugin

I got bitten by the fact that additional plugins removed the default one.

So I guess if I explicitly not want ccid support, I can still mkForce?

Yup!