Performance data propagation

See linked RFC document →
Initial commit for RFC on Performance data

So my main question is why do we need this structs?  if we want to add a field we need to update the MLAPI and I am not sure why they need to be this explicit when at the end of the day its key value pairs that get displayed on a screen or passed to the Unity profiler. I also worry about if the transport wants to report specific data that may not be shared for all transport we just don't get that data.
We also get into this case where this struct just ends up growing forever because we can't remove or change fields in the future for fear of breaking the API contract we have with already released packages that depend on MLAPI.
I also know @LukeStampfli brought this up but I don't get why we aren't just allowing the Transport to subscribe to some callback from the profiler system instead of changing the Transport API.
I would much rather see in the Transport:
void Init(){
  ProfilerSystem.OnGetProfilerData += GetProfilerData;
}

List<ProfilerCounterData> GetProfilerData() {
   return data;
}

So my main question is why do we need this structs? if we want to add a field we need to update the MLAPI and I am not sure why they need to be this explicit when at the end of the day its key value pairs that get displayed on a screen or passed to the Unity profiler. I also worry about if the transport wants to report specific data that may not be shared for all transport we just don't get that data.
We also get into this case where this struct just ends up growing forever because we can't remove or change fields in the future for fear of breaking the API contract we have with already released packages that depend on MLAPI.
I also know @LukeStampfli brought this up but I don't get why we aren't just allowing the Transport to subscribe to some callback from the profiler system instead of changing the Transport API.
I would much rather see in the Transport:
void Init(){
  ProfilerSystem.OnGetProfilerData += GetProfilerData;
}

List<ProfilerCounterData> GetProfilerData() {
   return data;
}

I had it as a struct with a  dictionary for unknown cases. Then we went struct. Now dictionary. I have no fight in which method. Whomever is closer to the transport should just make the call here. Its not big issue to me (performance or API wise)
The only difference between the callback and direct call is the expectation that every transport implements (or is aware) the contract. As a callback the transport may never implement the event. I'm fine with switching it.

So my main question is why do we need this structs? if we want to add a field we need to update the MLAPI and I am not sure why they need to be this explicit when at the end of the day its key value pairs that get displayed on a screen or passed to the Unity profiler. I also worry about if the transport wants to report specific data that may not be shared for all transport we just don't get that data.
We also get into this case where this struct just ends up growing forever because we can't remove or change fields in the future for fear of breaking the API contract we have with already released packages that depend on MLAPI.
I also know @LukeStampfli brought this up but I don't get why we aren't just allowing the Transport to subscribe to some callback from the profiler system instead of changing the Transport API.
I would much rather see in the Transport:
void Init(){
  ProfilerSystem.OnGetProfilerData += GetProfilerData;
}

List<ProfilerCounterData> GetProfilerData() {
   return data;
}

I had it as a struct with a dictionary for unknown cases. Then we went struct. Now dictionary. I have no fight in which method. Whomever is closer to the transport should just make the call here. Its not big issue to me (performance or API wise)
The only difference between the callback and direct call is the expectation that every transport implements (or is aware) the contract. As a callback the transport may never implement the event. I'm fine with switching it.

I guess I am not clear on why we don't just use the dictionary in all cases ?
As for the callback, I mean there is nothing requiring the transport for filling out the struct either. I just worry about breaking the transport or adding something to it when we are wanting to change it and if the structs are needed.

So my main question is why do we need this structs? if we want to add a field we need to update the MLAPI and I am not sure why they need to be this explicit when at the end of the day its key value pairs that get displayed on a screen or passed to the Unity profiler. I also worry about if the transport wants to report specific data that may not be shared for all transport we just don't get that data.
We also get into this case where this struct just ends up growing forever because we can't remove or change fields in the future for fear of breaking the API contract we have with already released packages that depend on MLAPI.
I also know @LukeStampfli brought this up but I don't get why we aren't just allowing the Transport to subscribe to some callback from the profiler system instead of changing the Transport API.
I would much rather see in the Transport:
void Init(){
  ProfilerSystem.OnGetProfilerData += GetProfilerData;
}

List<ProfilerCounterData> GetProfilerData() {
   return data;
}

I had it as a struct with a dictionary for unknown cases. Then we went struct. Now dictionary. I have no fight in which method. Whomever is closer to the transport should just make the call here. Its not big issue to me (performance or API wise)
The only difference between the callback and direct call is the expectation that every transport implements (or is aware) the contract. As a callback the transport may never implement the event. I'm fine with switching it.

I guess I am not clear on why we don't just use the dictionary in all cases ?
As for the callback, I mean there is nothing requiring the transport for filling out the struct either. I just worry about breaking the transport or adding something to it when we are wanting to change it and if the structs are needed.

Switching to Dictionary and callback from transport.
In regards to the Dictionary, the concern was boxing and performance but i think this is mostly negligible. I'll refactor to Dict<Enum,int> which should handle 90% of cases if not all

So my main question is why do we need this structs? if we want to add a field we need to update the MLAPI and I am not sure why they need to be this explicit when at the end of the day its key value pairs that get displayed on a screen or passed to the Unity profiler. I also worry about if the transport wants to report specific data that may not be shared for all transport we just don't get that data.
We also get into this case where this struct just ends up growing forever because we can't remove or change fields in the future for fear of breaking the API contract we have with already released packages that depend on MLAPI.
I also know @LukeStampfli brought this up but I don't get why we aren't just allowing the Transport to subscribe to some callback from the profiler system instead of changing the Transport API.
I would much rather see in the Transport:
void Init(){
  ProfilerSystem.OnGetProfilerData += GetProfilerData;
}

List<ProfilerCounterData> GetProfilerData() {
   return data;
}

I had it as a struct with a dictionary for unknown cases. Then we went struct. Now dictionary. I have no fight in which method. Whomever is closer to the transport should just make the call here. Its not big issue to me (performance or API wise)
The only difference between the callback and direct call is the expectation that every transport implements (or is aware) the contract. As a callback the transport may never implement the event. I'm fine with switching it.

I guess I am not clear on why we don't just use the dictionary in all cases ?
As for the callback, I mean there is nothing requiring the transport for filling out the struct either. I just worry about breaking the transport or adding something to it when we are wanting to change it and if the structs are needed.

Switching to Dictionary and callback from transport.
In regards to the Dictionary, the concern was boxing and performance but i think this is mostly negligible. I'll refactor to Dict<Enum,int> which should handle 90% of cases if not all

Suggestion for the dictionary to use string keys instead of a predefined enum. unintuitively, it's actually better for performance (enums as dictionary keys actually get boxed 🤢). and if we're going to go with a flexible approach, lets maximize that instead of restricting them to predefined keys, that way users building their own tools for their own custom transport could extend. we can still provide predefined keys for the user in a constants class so that we can guarantee good data for our profiler.

Not sure if this is the callback pattern you're referring to but want to comment on this snippet that Andrew posted
`void Init(){
ProfilerSystem.OnGetProfilerData += GetProfilerData;
}
List GetProfilerData() {
return data;
}`
this seems like a problematic api design. return values on multicast delegates is basically nonsensical. (i think c# lets you do it, but only returns the result of one of the delegates). we should either correctly support multiple return values or limit it to only one registered callback.
that said, i'm also not really a big fan of this approach. from an api design perspective it's a very indirect way of providing profiler data. if we're looking for an opt-in approach, i'd recommend that we add an interface that the transport can optionally implement, and MLAPI will try-cast the transport to that interface to see if it can gather profiler data.

Not sure if this is the callback pattern you're referring to but want to comment on this snippet that Andrew posted
void Init(){
  ProfilerSystem.OnGetProfilerData += GetProfilerData;
}

List<ProfilerCounterData> GetProfilerData() {
   return data;
}

this seems like a problematic api design. return values on multicast delegates is basically nonsensical. (i think c# lets you do it, but only returns the result of one of the delegates). we should either correctly support multiple return values or limit it to only one registered callback.
that said, i'm also not really a big fan of this approach. from an api design perspective it's a very indirect way of providing profiler data. if we're looking for an opt-in approach, i'd recommend that we add an interface that the transport can optionally implement, and MLAPI will try-cast the transport to that interface to see if it can gather profiler data.

This was just a suggestion :D I would not be against a Interface and that may indeed allow for the most flexibility without breaking anything.

So my main question is why do we need this structs? if we want to add a field we need to update the MLAPI and I am not sure why they need to be this explicit when at the end of the day its key value pairs that get displayed on a screen or passed to the Unity profiler. I also worry about if the transport wants to report specific data that may not be shared for all transport we just don't get that data.
We also get into this case where this struct just ends up growing forever because we can't remove or change fields in the future for fear of breaking the API contract we have with already released packages that depend on MLAPI.
I also know @LukeStampfli brought this up but I don't get why we aren't just allowing the Transport to subscribe to some callback from the profiler system instead of changing the Transport API.
I would much rather see in the Transport:
void Init(){
  ProfilerSystem.OnGetProfilerData += GetProfilerData;
}

List<ProfilerCounterData> GetProfilerData() {
   return data;
}

I had it as a struct with a dictionary for unknown cases. Then we went struct. Now dictionary. I have no fight in which method. Whomever is closer to the transport should just make the call here. Its not big issue to me (performance or API wise)
The only difference between the callback and direct call is the expectation that every transport implements (or is aware) the contract. As a callback the transport may never implement the event. I'm fine with switching it.

I guess I am not clear on why we don't just use the dictionary in all cases ?
As for the callback, I mean there is nothing requiring the transport for filling out the struct either. I just worry about breaking the transport or adding something to it when we are wanting to change it and if the structs are needed.

Switching to Dictionary and callback from transport.
In regards to the Dictionary, the concern was boxing and performance but i think this is mostly negligible. I'll refactor to Dict<Enum,int> which should handle 90% of cases if not all

Suggestion for the dictionary to use string keys instead of a predefined enum. unintuitively, it's actually better for performance (enums as dictionary keys actually get boxed 🤢). and if we're going to go with a flexible approach, lets maximize that instead of restricting them to predefined keys, that way users building their own tools for their own custom transport could extend. we can still provide predefined keys for the user in a constants class so that we can guarantee good data for our profiler.

Yes, By enum i meant defined string.

Not sure if this is the callback pattern you're referring to but want to comment on this snippet that Andrew posted
void Init(){
  ProfilerSystem.OnGetProfilerData += GetProfilerData;
}

List<ProfilerCounterData> GetProfilerData() {
   return data;
}

this seems like a problematic api design. return values on multicast delegates is basically nonsensical. (i think c# lets you do it, but only returns the result of one of the delegates). we should either correctly support multiple return values or limit it to only one registered callback.
that said, i'm also not really a big fan of this approach. from an api design perspective it's a very indirect way of providing profiler data. if we're looking for an opt-in approach, i'd recommend that we add an interface that the transport can optionally implement, and MLAPI will try-cast the transport to that interface to see if it can gather profiler data.

This was just a suggestion :D The primary suggestion was I think it should be opt in vs a requirement.
I would not be against a Interface and that may indeed allow for the most flexibility without breaking anything.

Given that the transports simply subscribe and provide the data to MLAPI as opt in. I see no reason for an interface. If the GetData() actually held logic id be more prone to go this way. Currently i don't see much of a use it will have except for adding type casting code. Callbacks seems better to me since we're talking about data and not logic.
Updated everything to the latest and greatest feedback

I think @becksebenius-unity concern around delegates in C# is a valid one; they are kind of trash especially the multi-cast ones. They are especially gross in IL2CPP :( where as the interface cost will be cheaper for those platforms.


We should provide a more configurable override for the log4j.properties in the broker

Changing the settings for the log4j properties currently requires packing up another tgz, stop, copy tgz to uri server, start in order to use. This could be further automated from the command line specifying this file. We should also have some of the options work from the command line that can filter down. We should share this also with the scheduler and make it easily modifiable.

Created PR - broker_log4j_config.
Please review and merge.


AWS Helm

📲 What
Adds helm chart configuration to support AWS-specific config
🤔 Why
To support deployment to AWS with a single helm chart
🛠 How
Simple helm chart logic
👀 Evidence
https://github.com/Ensono/stacks-dotnet/actions/runs/6085527285
🕵 How to test
Notes for QA
✅ Acceptance criteria Checklist

[ ] Code peer reviewed?
[ ] Documentation has been updated to reflect the changes?
[ ] Passing all automated tests, including a successful deployment?
[ ] Passing any exploratory testing?
[ ] Rebased/merged with latest changes from development and re-tested?
[ ] Meeting the Coding Standards?

No longer necessary


cmd/compile: Global Array Access Time significantly slower than slice

When I run the attached benchmark, I expected that accessing the array would be faster
in all scenarios. In Go 1.0, the speeds are equal. However, in Go 1.1 (tip), it seems
that array access time regressed significantly for global arrays (by about 20%).

Following a response from Russ and Rob (see
https://groups.google.com/d/msg/golang-dev/TI54OYWno68/J-fKuTFVG_wJ), I've verified that
array access speed is better when the array is local to the function or a field in a
local struct value. For global arrays, there's still a significant slowdown. Using a
pointer to the global array didn't seem to make a difference.

arrlen: 1024
BenchmarkArrayGlobal     2000000           860 ns/op
BenchmarkArrayGlobalPtr  2000000           872 ns/op
BenchmarkSliceGlobal     5000000           741 ns/op
BenchmarkArrayLocal  2000000           862 ns/op
BenchmarkSliceLocal  2000000           941 ns/op
BenchmarkArrayStructField    1000000          1090 ns/op
BenchmarkSliceStructField    1000000          1249 ns/op

arrlen: 2048
BenchmarkArrayGlobal     1000000          1742 ns/op
BenchmarkArrayGlobalPtr  1000000          1738 ns/op
BenchmarkSliceGlobal     1000000          1454 ns/op
BenchmarkArrayLocal  1000000          1734 ns/op
BenchmarkSliceLocal  1000000          1836 ns/op
BenchmarkArrayStructField    1000000          2160 ns/op
BenchmarkSliceStructField    1000000          2488 ns/op

Please run attached benchmark to reproduce.

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Linux 3.5.0-26-generic #42-Ubuntu SMP x86_64 GNU/Linux

Which version are you using?  (run 'go version')
go version devel +c246dbf446db Wed Mar 20 23:53:38 2013 -0400 linux/amd64
Attachments:

array_vs_slice_test.go (1788 bytes)

Just tried this with tip (near go1.8rc3). In all cases, array access is now faster, so calling it fixed.
BenchmarkArrayGlobal-8        	 5000000	       309 ns/op
BenchmarkArrayGlobalPtr-8     	 5000000	       311 ns/op
BenchmarkSliceGlobal-8        	 3000000	       467 ns/op
BenchmarkArrayLocal-8         	 5000000	       303 ns/op
BenchmarkSliceLocal-8         	 5000000	       305 ns/op
BenchmarkArrayStructField-8   	 5000000	       308 ns/op
BenchmarkSliceStructField-8   	 3000000	       474 ns/op


UWP Support?

Is Bond supported for UWP apps? If not, any plans to add support?

@lalo is looking into this. Bond.dll doesn't use any APIs that aren't part of UWP (Windows 10+), but Compact Binary deserialization is throwing an exception. I can't remember the exact exception right now, but it had something to do with converting from System.Int32 to Bond.BondDataType& when calling ReadFieldBegin.
@sapek might have run into this issue before when he was debugging some .NET Native stuff.

It looks like dotnet/corefx#3007.

Still getting the exception with Microsoft.NetCore.UniversalWindowsPlatform 5.2.2 (latest version to this day)

Is this a question? I just tried the bond blob core example using 5.2.2 and got the same error at the line
var dst = Deserialize.From(reader);
ArgumentException: Object of type 'System.Int32' cannot be converted to type 'Bond.BondDataType&'.
So it would appear the issue remains?

Not a question, I was updating the status with the latest version of NetCore. Sorry for the confusion.

When targeting Windows 10 Fall Creators Update (10.0; Build 16299), Bond now works. I tested with a C# XAML UWP application. None of the earlier target platforms that I tested worked.


Gas Mask does not properly hide snouts

Description

RMC Gas Mask's HideLayerComponent doesn't work. Other RMC masks (coif, sterile mask, rebreather) still properly hide snouts, but the gas mask doesn't.
Reproduction

Reproducible with any snouted species, but steps to reproduce for lizards:

Temporarily delete RMC-14/Resources/Textures/_RMC14/Objects/Clothing/Mask/gas.rsi/equipped-MASK-reptilian.png
Load up the game, make a lizard character, and put on a gas mask.
Snout clips through the mask.

Note that this doesn't happen if reproduced with the coif, or a sterile mask, or a rebreather; the default masks applying will smush the snout off of the lizard head, but the snout won't clip through. This is because the other masks still have functioning HideLayerComponents.
It is of course possible to work around this by making custom gas mask sprites for varying snout sizes, and this is preferable aesthetically anyway. But this is still a bug and should get fixed.
Screenshots

(A rodentia with a large bat snout clipping through the default human gas mask.)
Additional context

Mostly creating this issue as a reference point for a known issue in my next PR to add Rodentia. I have a solution to this, but it may break the gas mask's suit storage compatibility. If I can make a fix that doesn't break anything else, I'll follow-up with another PR to fix this.

Oh, this actually might be an upstream bug. I'm seeing the same issue on DeltaV now that I'm looking for it.

This happens because the HideLayerClothingComponent doesn't take in account a clothing item having more than one fitting slot.
Since the gas mask fits on the suit storage and mask slot, this happens.
The code checks if the slots on the HideLayerClothingComponent and ClothingComponent match, but instead of checking if a slot COULD be valid; it just checks if it's equal to the slots. (Suit Storage + Mask ~= Mask)
hopefully this explained it well

On further investigation, this is caused by the suitstorage slot being added to the gas mask, for storing gas masks on hazard vests. I'm not yet sure why these things are incompatible, however.
I think the problem might be at Content.Shared/Clothing/EntitySystems/ClothingSystem.cs, line 104? It's possible that I'm misunderstanding how SlotFlags works, as I'm not very knowledgeable about C#, but I think it's comparing clothing.Slots (in this case, a list of Mask and SuitStorage) against the Mask slot's SlotFlags. Which will always be false, and so always fail to hide layers?
I'll mess around with it further tomorrow to try and confirm.

This happens because the HideLayerClothingComponent doesn't take in account a clothing item having more than one fitting slot.
Since the gas mask fits on the suit storage and mask slot, this happens.
The code checks if the slots on the HideLayerClothingComponent and ClothingComponent match, but instead of checking if a slot COULD be valid; it just checks if it's equal to the slots. (Suit Storage + Mask ~= Mask)
hopefully this explained it well

God I really wish I'd refreshed this page and seen this response before typing in that comment just now. I just spent hours investigating to come to basically the same conclusion you did literally 18 hours ago lmao.

I guess technically this is and upstream issue then. I'll try to sort it out there rather than make the change here. I'll leave this issue open to track the state of it so that we can pull that upstream fix down when it's live.

I have opened an issue upstream for this, here


Doc: Set dev server to <IP_ADDRESS>

- Summary
When walking through the setup documentationn I was unable to access the dev
server on localhost:8080 on Mac OSX. I attempted to implement the
workarounds suggested at
https://github.com/webpack/webpack-dev-server/issues/183 to no avail.
This change allowed me to follow the output of the webpack dev server
directly and see all assets from the browser.
- Test plan
grant at McBeast in ~/work/netlify-cms on origin/master
$ npm start

<EMAIL_ADDRESS>start /Users/grant/work/netlify-cms
webpack-dev-server -d --config webpack.dev.js

Project is running at http://<IP_ADDRESS>:8080/
webpack output is served from http://<IP_ADDRESS>:8080/
Content not from webpack is served from example/
404s will fallback to /index.html
You are using @apply rule and custom property sets.
This feature won't be included in next the major release of postcss-cssnext.
This most likely won't get any more support from browser vendors as the spec is yet considered deprecated and alternative solutions are being discussed.
Read more about the reason here https://github.com/pascalduez/postcss-apply.
Hash: 0971a643d3190ae4b6d6
Version: webpack 3.6.0
Time: 14312ms
Asset     Size  Chunks                    Chunk Names
40b2ba67cfdebc631c5942867695a2e2.eot  83.4 kB          [emitted]
570eb83859dc23dd0eec423a49e147fe.woff2  44.3 kB          [emitted]
012cf6a10129e2275d79d6adac7f3b02.woff  57.6 kB          [emitted]
a37b0c01c0baf1888ca812cc0508f6e2.ttf   128 kB          [emitted]
e5147f7843186e46490bd896d6a85abf.woff2  41.3 kB          [emitted]
3360b1d4036d32df1e555e993b30946c.woff  50.4 kB          [emitted]
c8c19ba3328799e7bb03f3b47c40dba2.ttf  83.3 kB          [emitted]
db4e36de8364fc2444c5ed0443c04da4.svg   121 kB          [emitted]
cms.js  15.8 MB       0  [emitted]  [big]  cms
[0] ./node_modules/react/index.js 190 bytes {0} [built]
[378] (webpack)-dev-server/client/overlay.js 3.73 kB {0} [built]
[380] (webpack)/hot nonrecursive ^./log$ 170 bytes {0} [built]
[631] multi (webpack)-dev-server/client?http://<IP_ADDRESS>:8080 webpack/hot/dev-server react-hot-loader/patch webpack-dev-server/client?http://<IP_ADDRESS>:8080/ ./index 76 bytes {0} [built]
[632] (webpack)-dev-server/client?http://<IP_ADDRESS>:8080 7.23 kB {0} [built]
[675] (webpack)/hot/dev-server.js 1.61 kB {0} [built]
[676] (webpack)/hot/log-apply-result.js 1.31 kB {0} [built]
[677] ./node_modules/react-hot-loader/patch.js 41 bytes {0} [built]
[678] ./node_modules/react-hot-loader/lib/patch.js 209 bytes {0} [built]
[750] (webpack)-dev-server/client?http://<IP_ADDRESS>:8080/ 7.23 kB {0} [built]
[751] ./src/index.js 2.27 kB {0} [built]
[766] ./node_modules/react-hot-loader/index.js 41 bytes {0} [built]
[778] ./node_modules/normalize.css/normalize.css 960 bytes {0} [built]
[1592] ./src/index.css 1.16 kB {0} [built]
[1600] ./src/utils.css 1.16 kB {0} [built]
+ 1586 hidden modules
webpack: Compiled successfully.
- Description for the changelog
Set dev server to <IP_ADDRESS>

- Summary

- Test plan

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

Thanks @gcallaghan!
@talves I know this will be moot once we merge your PR, but for the moment, can you review from a cross-platform standpoint?

@gcallaghan can you try something for me?
Leave the setting as localhost and delete this line in the webpack.dev.js and let me know if it still give you the same issue.
publicPath: `http://${ HOST }:${ PORT }/`,

@talves I updated my OS X and checked out latest master and can now resolve localhost:8080 including the assets. Not sure if this was a 10.12 Sierra issue, but it is resolved for me now.

Glad to hear. The issue with going to <IP_ADDRESS> would have implications on other platforms. Documented. Going to <IP_ADDRESS> would be better, but some windows would gack on it. localhost is our lesser of all evils at this point. 👍


Permission Level?

What permission level in the asset's IAM is required to use this feature?

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

ID: 6bcb620a-9cdc-77c5-7396-a82954f90e44
Version Independent ID: 57bead5a-5022-2583-fd1e-dbb66e82c917
Content: Reset the password or Remote Desktop configuration on a Windows VM
Content Source: articles/virtual-machines/windows/reset-rdp.md
Service: virtual-machines-windows
GitHub Login: @danielsollondon
Microsoft Alias: danis

@Niterave I played around a bit in my subscription and it looks like you need to at least have Virtual Machine Contributor to use this feature.
I will close this out but if you have more questions or issues just reopen and we can continue :)


Add user-defined status names for Github

See https://github.com/paulMrG2/delightful/commit/82a6149ce31558ba0ed056b262e177db885019c7


Math isn't working inside rgba() function

I want to invert the opacity by subtracting some value from 1 when creating new color with the help of rgba() function. Unfortunately, this doesn't work as expected. However, it works if I define a separate opacity token with this math but not directly inside the rgba() function.

I have too a problem with rgba when I reference a color by:
rgba($colors.brand.default, 0.5)
I get a white color, brand.default is : $colors.blue.500
blue.500 is : hsl($colors.blue._hue, 100%, 50%)
and _hue is : 210

@electroheadfx you can solve this by using a hex color value for your blue.500. Worked for me at least.

@electroheadfx you can solve this by using a hex color value for your blue.500. Worked for me at least.

yes of course it works, just it doens't support color with utils like : hsl($colors.blue._hue, 100%, 50%), its useful because I dont need to convert in hex, just use the saturation.

Same issue using hsla:
"TKSC": {
    "color": {
      "cyan~teal": {
        "hue": {
          "value": 177,
          "type": "other"
        },
        "saturation": {
          "value": 44,
          "type": "other"
        },
        "lightness": {
          "value": 41,
          "type": "other"
        }
      }
},
"TKM": {
    "color": {
      "primary.300": {
        "value": "hsla($TKSC.color.cyan~teal.hue, $TKSC.color.cyan~teal.saturation, $TKSC.color.cyan~teal.lightness * 1.2439, 1)",
        "description": "Primary background color light",
        "type": "color"
      }
}

The Token doesn't work:

See screenshot

Also please note that the colors chips (palette) inside the plugin panel are not displaying the calculated colors. I will open another Issue for this soon.

@six7: FYI if you watch this Loom captured on July 22 you will notice that everything was functioning¹ then.
I Hope that this can help.
(1) Here's the snippet I was using, and doesn't work anymore

$colors.lightness._secondary-bg * 4.5 + 0.175 translates into "15 * 4.5 + 0.175" instead of 45.175 (‹ properly evaluated in the colors.lightness._secondary-AA node)

{
  "colors": {
    "lightness": {
      "_secondary-bg": {
        "value": "25",
        "description": "Lightness of the Secondary background color",
        "type": "color"
      },
      "_secondary-AA": {
        "value": "$colors.lightness._secondary-bg * 4.5 + 0.175",
        "description": "AA lightness of the Secondary text color",
        "type": "color"
      }
    },
    "color": {
      "secondary": {
        "value": "hsl(172,50,$colors.lightness._secondary-bg)",
        "description": "Secondary background color",
        "type": "color"
      }
    },
    "secondary-AA": {
      "value": "hsl(172,50,$colors.lightness._secondary-AA)",
      "description": "AA Color of text on Secondary",
      "type": "color"
    }
  }
}

Also I've noticed that sometimes removing the space character after the comma inside the hsl() function sometimes leads to a null eval.


Can CNN buffers be shared ?

I'm interested in if CNN is included in sequencer module, could its gradInput and output buffers be shared along clones ? (assume memory pre-allocation is enabled.)
For instance, nn.SpatialConvolution, nn.SpatialMaxPooling and their cudnn alternatives.

gradInput tensors can always be shared unless they are exposed outside the network but the code handles that for you.
output tensors can be shared if they are not used in the backward pass. You should take a look at the implementation of every new modules you introduce in the code and apply this rule:

If the content of input is used in updateGradInput or accGradParameters, add the module in the protectInput table.
If the content of self.output is used in updateGradInput or accGradParameters, add the module in the protectOutput table.

For example, see the modules that are already blacklisted in MemoryOptimizer.lua and how they use their input or output in the backward pass.
It forces you to know in details the modules you used but the optimization is efficient.

@guillaumekln Thank you so much!


httprb changes URL encoding with requests

My original encoded string in the URL is javois%CC%8C_et_al_data.xls but httprb changes %CC%8C by replacing the s with %C5 and adding %A1.  This makes matching and downloads fail, but changing the encoding doesn't happen with other programs or libraries like curl or HTTParty.
# CURL version
curl http://localhost:3000/javois%CC%8C_et_al_data.xls
# Started GET "/javois%CC%8C_et_al_data.xls" for ::1 at 2020-06-06 11:13:22 -0700

# HTTP.rb version 4.4.1 in console
require 'http'
HTTP.get('http://localhost:3000/javois%CC%8C_et_al_data.xls')
# Started GET "/javoi%C5%A1_et_al_data.xls" for ::1 at 2020-06-06 11:16:47 -0700

The differences in these strings.
require 'cgi'
a = CGI.unescape('javois%CC%8C_et_al_data.xls')
b = CGI.unescape('javoi%C5%A1_et_al_data.xls')

a == b
# => false

a.unpack('H*')
# => ["6a61766f6973cc8c5f65745f616c5f646174612e786c73"]
b.unpack('H*')
# => ["6a61766f69c5a15f65745f616c5f646174612e786c73"]

OK.  I'm going to close this one since I was able to fix it by digging through the HTTP rb code for a while to figure out the internals and options some.
Something like this will keep it from changing the path and bypasses the normalization in the path part of the URL.
It may not hurt to document it in the readme as an advanced option or something.
NORMALIZER = ->(uri) do
  uri = HTTP::URI.parse uri
  HTTP::URI.new(
    scheme: uri.normalized_scheme,
    authority: uri.normalized_authority,
    path: uri.path, # this is the part I changed, instead of normalizing the path
    query: uri.query,
    fragment: uri.normalized_fragment
  )
end

http = HTTP.use(normalize_uri: { normalizer: NORMALIZER }) # and rest of options
http.get(' . . . some url . . .')

@sfisher what was the resolution?

The resolution is to change the URL normalizing as in the code sample above.  My example was a foreign character that someone put in and there are two different ways in UTF-8 represent the same character.
One is s + combining caron (%CC%8C) and the other is small letter s with caron (%C5%A1) but they are different UTF-8 codes but end up displaying the same (but are not binary identical).  I think the first one basically is like 'backspace and put a caron symbol over the previous letter' and the 2nd is like type the s-with-caron symbol.
The NORMALIZER constant is more or less a copy/paste of the code I found in the http.rb gem but with 2 changes.  1) referenced HTTP:URI explicitly (since it was inside the class in the other code example) and 2) changed uri.normalized_path to uri.path so it doesn't change the input path.
Then to get it to work without normalizing you can say what normalizer you want to use (the default is to use the built-in one), but I'm setting it use(normalize_uri: { normalizer: NORMALIZER }).
Maybe some people will like normalization, but in our systems have the value in one database and it will be the same as in a separate internal system, so all that normalization does is make the request fail and give us a 404 instead of a 200 response because the values no longer match up after normalization.

Oh, indeed. We introduced swappable URI normalizer at some point, but I guess never added it to documentation: https://github.com/httprb/http/pull/533


[Win] Installer VS application fails if links on form can not be opened

In some cases (Win 7) links to Installation Manual and Tutorials can not open and  application crashes. Need to prevent this.

Need to add possibility to copy URL from link label by mouse right click in case if default browser can not run


#105 transact get single table

closes #105

Coverage increased (+0.7%) to 92.031% when pulling 2341719a348d9693c16aad1d12893e05fb0679cc on #105-transact-get-single-table into 9db04d4ed526791f73850a321e9fdf724efe3e40 on beta.

:tada: This PR is included in version 4.1.0-beta.8 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 5.0.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 5.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


TypeInitializationException

This tool works fine with original file. But when I try to dump agile protected file I get an Exception:

So I believe, I need to Invoke something else here in line 74:

Error solved. I had missing AgileDotNetRT.dll in folder.
Now it says methods are dumped. But all methods are empty. So It is the same as it was in protected file.

This tool updated 4 years ago. You need analyze and change what's need change.

Error solved. I had missing AgileDotNetRT.dll in folder. Now it says methods are dumped. But all methods are empty. So It is the same as it was in protected file.

Hi @1point7 any luck?


Fix build on Travis CI

The master branch currently fails to build on Travis due to package issues. This should fix that.

@robryk Could you please take a look?

Thanks.


Disabling on-disk cache

Although NUMBA_CACHE_DIR allows us to move the cache directory to another location, I think that for HPC systems we actually want to have a mechanism for disabling caching completely.  We sometimes run mpi4py applications with >100K processes, and it is much better to have all those processes independently spend a few seconds compiling things rather than trying to read them from disk.
Is there any hope of a "NUMBA_CACHE_DISABLE" switch to forcibly override any cache=True options globally?
Originally posted by @tskisner in https://github.com/numba/numba/issues/3470#issuecomment-530038481

To reiterate, I think I read somewhere that when Numba reaches v1.0, Numba will default to cache if the decorator doesn't specifically disabled it. So it would be important to have this env. var. option (or any sort of "global kill switch") to override this behavior before Numba reaching v1.0. Could we add this issue as part of the v1.0 milestone?

Likely we will do this sooner, but good to note the need before caching is enabled by default.

On the GPU side, I would view this feature request as more or less the opposite of that in #4389, in which we don't want any compiling to happen. It'd be good to have both features in 1.0 and let users decide the deployment strategy in a HPC system.

I think we'll want to do this as NUMBA_CACHE_OVERRIDE=always|never


Added GFM syntax highlighting for code blocks.  (Few minor typo fixes as

Added GFM syntax highlighting for code blocks.  (Few minor typo fixes as well.)

@danring @davisp .


Update model

Looked thru latest ShipStation api documentation and adjusted model to match all api endpoints
Tested bulk create of orders
Making this stable version because we have been using this package on production for many years now


create helper function to check if at least one packet commitment exists in a given channel

we need to check if at least one packet commitment exists before writing state for ChanUpgradeAck. the current method we have available, GetAllPacketCommitments, is inefficient as it will do the full iteration and give you all packet commitments when really you just need to check if there exists at least one.
Originally posted by @AdityaSripal in https://github.com/cosmos/ibc-go/pull/3787#discussion_r1226394345

I'll take a look at this at some point (though I'll punt it for a bit later since it isn't pressing).

I would suggest an API like:
func (k Keeper) hasInflightPackets(ctx sdk.Context, portID, channelID string) bool


Move the oversized image check to just before the Bin files are saved

I'd like to use this application to control the LCD via software and not firmware because this is the only program I have found that lets you display any image to the Ergodox via the serial port.
However because Function 0 is the only one that supports fullscreen that means that I can only have one full size image loaded at any given time.
By putting the image size check just before the bin files are saved as opposed to when the images are loaded into the program it would still prevent incorrect image formats in the BIN file but allow you to have multiple color and image presets ready.

There are a few other projects that let you change the screen via software, that I used as a base for this project. Can't find the links anymore, but one had to do with playing snake on the LCD.
What you are asking for would be bad practice as far as the intention of the program goes, but you can do those changes for your own use, of course, by changing the behavior of the other layers to be the same as the first layer. If you are handy with python just study the code and you should be able to make your own program to suit your needs quite easily.


Create "About us" Page

We need someone to create an html page in the pages folder that will content a little description about us. The design can be made and the content will be added gradually.
The Design
The design should include our logo or a brand nice image of a hub and text content
The content should include:
What is the name of the Software?
What is the main aim of the Software?
Who invented the Software?
How many contributors have improved the software?

@NtemKenyor  Hey, I like to contribute to this project, Would appreciate it if you assign me.

I have assigned the task to you. You may also want to check out this introductory video: https://www.youtube.com/watch?v=p2z3frymoiU

I also would like to contribute to it

Hey, please I would also like to contribute to this

@NtemKenyor  please review my pr

done.


[MM-23103] Add Reset Channel ID action

Summary

Adds Reset Current Channel ID action for when user visits system console.
Ticket Link

https://mattermost.atlassian.net/browse/MM-23103

@hahmadia can you explain what is it that we are trying to solve here? I could not really understand the ticket.
Also if you need to clear the channel selection is not enough to do
dispatch({type: ChannelTypes.SELECT_CHANNEL, data: ''});

@hahmadia can you explain what is it that we are trying to solve here? I could not really understand the ticket.
Also if you need to clear the channel selection is not enough to do
dispatch({type: ChannelTypes.SELECT_CHANNEL, data: ''});

@enahum
I could do that and it is what I had initially but it's a little confusing. The problem is the following:
You view a channel and then click go to System Console > Channels and select the last channel you viewed. You edit any of the settings and press Save , you will be re-directed to that channel after the save. This is due to the fact that https://github.com/mattermost/mattermost-webapp/blob/master/actions/websocket_actions.jsx#L451 gets triggered. So I fix the redirection by resetting the the current channel id so it doesn't get triggered.
The reason I created a new action is because in the web app PR ( https://github.com/mattermost/mattermost-webapp/pull/5019 ) , it was a little confusing to put actions.selectChannel('') and I thought it would be more clear to have something like actions.resetCurrentChannelId instead. However, if you think this is not appropriate, I'm more than happy to do what you suggested.

This seems risky either way.. what else gets impacted with this change. 0/5 on the action name.

Adding @hmhealey just in case he can think of potential side effects

Another question is why do we have a redirect in the WS action.

Another question is why do we have a redirect in the WS action.

@enahum
The change happened in this PR https://github.com/mattermost/mattermost-webapp/pull/3077 . Seems to be for channel renaming issues.

@hmhealey maybe the WS approach to fix the linked webapp PR was not the best solution? what about redirecting only if the channel name changed somewhere in the Channel view component ?

I'd lean towards using an existing redux action like @enahum suggested above when you go into the system console instead of creating a new action that does the same thing just without an argument. We may have other code looking for SELECT_CHANNEL actions (like some stuff I've been looking at recently), so I don't think we should have two ways of doing that. I like the idea of clearing the currentChannelId (and maybe the currentTeamId too?) when you leave the channel view though.
Regarding the previous PR, it does seem like there might be a better way to do that, but getting redirected by websocket events happens elsewhere as well (like when a team/channel is deleted or the user is removed from either of those), so I think just clearing the currentChannelId and currentTeamId when you're not in the channel view would be easier.

@hmhealey @enahum
To addressed Harrison's comment on my other PR about resetting the currentTeamId, I needed to update the selectTeam to align it with our selectChannel action. In order to avoid refactoring a lot of our code which is already passing a Team type, I decided to add a extra string type and check to see if the passed in parameter should use team or team.id as the teamId. Thanks!

I lost track of what this PR tries to do, at first it was about unselect the current channel, now is about the current team, and I only see two lines of code being changed.
@hahmadia can you please clarify?
Thanks my friend.

@enahum
Sure! So initially it was adding a new action to reset the currentChannelId but as you and Harrison mentioned, it would be better to use the current selectChannel('') to reset that which I did https://github.com/mattermost/mattermost-webapp/pull/5019 and Harrison suggested it wouldn't be a bad idea to also reset the currentTeamId as well but selectTeam function accepts a Team object however I wanted to make it so it can accept both a Team and string so I could pass in a empty TeamId string to reset the currentTeamId. This also aligns up with the way selectChannel function works which is accepting a channelId string.


Rasterific-0.5 can't compile its test suite

Citing from http://hydra.cryp.to/build/536970/nixlog/3/raw:
Preprocessing test suite 'test' for Rasterific-0.5...

exec-src/rastertest.hs:26:8:
    Could not find module ‘Arbitrary’
    Use -v to see a list of the files searched for.

exec-src/rastertest.hs:34:18:
    Could not find module ‘Sample’
    Use -v to see a list of the files searched for.

Thanks


I don't think the aux power works as written? How do I send power to a port?

        Resource("aux_vbus_en",        0, Pins("L2", dir="o"), Attrs(IO_TYPE="LVCMOS33")),
Has this been verified to work for the r1.4 as written? If yes, whats the code to power the aux port via m.d.comb?

aux_vbus_en has been tested. The purpose of aux_vbus_en when used alone is to pass VBUS power from AUX to TARGET A. If you want to pass power from some other port to AUX, you must enable both aux_vbus_en and either target_c_vbus_en or control_vbus_en.
For background on the power pass-through architecture, see: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/cynthion-hardware-design-update
One change since that post is that we turned off TARGET C pass-through when Cynthion is unpowered.
Does this answer your question?

This is perfect!

This is a great image just for reference. I know I'm goofy rambling in half these threads, someone will appreciate it one day I promise. I'm learning fpgas through this platform and amaranth.


Assassins Creed Origins

Trying to get Assassins Creed Origins working with DXVK on Windows 10 since DXVK has much better CPU management and Vulkan is much better than Directx. Tried copying 64-bit dxvk dll's to game folder. The game runs on DXVK dll's but lot of graphics issues and fps problems, menu graphics doesn't load properly either. Is DXVK not yet ready for Assassins Creed Origins?

Maybe if you tried running cracked version on Wine, you can get apitrace or anything useful out of the game to debug and fix issues?

You probably shouldn't discuss piracy on a public bug tracker.

You probably shouldn't discuss piracy on a public bug tracker.

Not trying to but due to DRM issues preventing debug and fix issues, unfortunately using crack might be a solution to debug and fix issues.

You probably shouldn't discuss piracy on a public bug tracker.

Clicked wrong button...

I have to agree with @Guy1524 here. Feel free to open an issue if you manage to get an apitrace, which is the only way for me to actually work with the game. Right now there's not much I can do.


Missing images when sharing from iOS photos library

Hi! I encountered an issue that happens randomly. Sometimes, when I share multiple images to my app, some files are not received. Still, if I select the images that are missing separately (or with different images) they are received correctly.
Has this happened to anyone and found a solution?

Same with me,
when I am sharing from whatsapp I am getting images but with same names,
so for example I share 6 images but from that 4 have same name, then I can only get 3 images.


ROX-8113: Fix email tests

Description
A detailed explanation of the changes in your PR.
Feel free to remove this section if it is overkill for your PR, and the title of your PR is sufficiently descriptive.
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

/test images push-images gke-qa-e2e-tests

/test images push-images gke-qa-e2e-tests

/retest


use service_order table for service migration

Fixed https://github.com/eclipse-xpanse/xpanse/issues/2057

LGTM

LGTM

LGTM

LGTM

LGTM

LGTM

LGTM


Screenshot on Android

Hi!
Any reason for preventing screenshot from the android app? I understand that you are promoting keybase team as a way to communicate with group of friends, family etc.
Which is good, but what chat app would prevent its user to screenshot his own chat ?
Thank you!

Go the menu on your Keybase app (looks like a little hamburger) and click 'Screen Protector'...
https://i.imgur.com/drBDKk6.jpg
Disable the 'Screen Protector' option...
https://i.imgur.com/Wd25uRE.jpg
Screenshots should now work without issue throughout the application.


integration-cli: readContainerFileWithExec for links tests

Shout out to @estesp for the idea. Some use cases of
readContainerFile can be replaced with docker exec $id cat $file.
This helper method can eliminate the assumption that
host/cli should be on the same machine, partially.
TestRunMutableNetworkFiles and TestRunResolvconfUpdater still
need to access the docker host filesystem as they modify
the file directly from there assuming cli and daemon are
on the same machine. They may keep usingreadContainerFile.
This fixes TestLinksUpdateOnRestart and TestLinksHostsFilesInject
for Windows CI.
Signed-off-by: Ahmet Alp Balkan<EMAIL_ADDRESS>Label: #windows
Cc: @estesp @duglin @unclejack @jfrazelle @tianon

https://jenkins.dockerproject.com/job/Windows-PRs/46/console
=== RUN TestLinksUpdateOnRestart
[PASSED]: link - ensure containers hosts files are updated on restart
=== RUN TestLinksHostsFilesInject
[PASSED]: link - ensure containers hosts files are updated with the link alias. :+1:

this is going to break lxc, can we move all the exec tests to a certain file that wont run on lxc, see the exec_test file for example

or we need a way to do this without exec

Or we may skip these altogether or move to "//+build daemon" as it's not really testing the CLI but daemon.

Or use POST /contaienrs/<id>/copy

@cpuguy83 erm, you're right... @jfrazelle how's that sound to you?

sgtm

yeah, seems like copy is best option (apart from dropping lxc support)

@jfrazelle @LK4D4 I pretty much implemented the docker cp support except it appears that we can't cp "/etc/hosts" from a container #9998, #10037. @tianon
How about we skip these 2 test cases with testRequires(t, ExecSupport) and keep the original "docker exec .. cat /file" implementation?
(I guess we can use test_no_exec go build tag to find out if execdriver==lxc and create 2 files test_vars_exec.go, test_vars_noexec.go and add supportsExec const for testRequires? @jfrazelle)

+1 for supportExec

@LK4D4 @cpuguy83 @jfrazelle I just took the fixes.

Made use of test_no_exec build tag to skip the tests in LXC case (102e061)
implemented readContainerFileWithExec (6bbb456).

yayyy thanks @ahmetalpbalkan LGTM

ping @LK4D4

LGTM

yaay, thanks. :joy:


Update tutorial with TensorFlow 2.0

Text Classification with TF Hub tutorial: https://github.com/tensorflow/hub/blob/master/docs/tutorials/text_classification_with_tf_hub.ipynb
With the release of TensorFlow 2.0, this version of the notebook won't compatible with tf 2.0.
Downloading data from http://ai.stanford.edu/~amaas/data/sentiment/aclImdb_v1.tar.gz
84131840/84125825 [==============================] - 7s 0us/step

---------------------------------------------------------------------------

AttributeError                            Traceback (most recent call last)

<ipython-input-11-bc6b7ca1da91> in <module>()
     34 logging.set_verbosity(logging.ERROR)
     35
---> 36 train_df, test_df = download_and_load_datasets()
     37 train_df.head()

2 frames

<ipython-input-11-bc6b7ca1da91> in load_directory_data(directory)
      4   data["sentiment"] = []
      5   for file_path in os.listdir(directory):
----> 6     with tf.gfile.GFile(os.path.join(directory, file_path), "r") as f:
      7       data["sentence"].append(f.read())
      8       data["sentiment"].append(re.match("\d+_(\d+)\.txt", file_path).group(1))

AttributeError: module 'tensorflow' has no attribute 'gfile'

@HackyRoot In 2.0, tf.gfile.* is replaced by tf.io.gfile.*.
If you want, you can submit a cherry-pick for this tutorial.
Thank you

Sorry @ gowthamkpr, I coudln't find it on the TensorFlow website hence I created this issue. Thank you!


Duel Starter Problem

i have notice even i play the Duel Starter with player VS AI its freezing and the AI is not thinking anymore also the Player 1 is also doing that too thanks

Similar problem for me.  Any effect activation freezes the game in a bizarre way.  Effects never resolve, so the game state is frozen whenever I or the NPC attempt to do so.  But I can still hear the BGM, I can open the menu (but clicking surrender does nothing), zoom in on card text, interact with the mate.  Upon switching to the tutorial instead of Duel Starter to see if anything runs, its the same issue.
I've tried deleting the mod folder and replacing everything, including deleting the card database to redownload it from the official (not modded) version of the game.  The https://github.com/pixeltris/YgoMaster/blob/master/Docs/FileLoadError.md page solutions worked when updating the game previously, but don't work for this problem.  I've had a lot of fun with 1.12 and earlier versions, and your mod provides just what I was looking for by letting me make decks for the AI to use (Tag Force Special was the last time I could easily do this).  Thanks for creating this mod and taking the time to fix bugs for free.

its also affects Solo Mode too but pixeltris is not release a small bug fix or a v1.13.5 (.5 for bug fix) but thanks for creating the mod and also fixing bugs :(

Thanks for the report. It's probably because of this animation blocking thing I added. I'll look at it soon https://github.com/pixeltris/YgoMaster/commit/f74c267792b4f2d169c297092b02ea2ac34544fd

Thanks.  It's working now.
On Thu, Aug 11, 2022 at 11:21 AM pixeltris @.***> wrote:

Closed #92 https://github.com/pixeltris/YgoMaster/issues/92 as
completed.
—
Reply to this email directly, view it on GitHub
https://github.com/pixeltris/YgoMaster/issues/92#event-7172635098, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/APMFPJZ5AQHAJ4N3BOE747TVYUK7FANCNFSM56GM7ZBQ
.
You are receiving this because you commented.Message ID:
@.***>


Add hidden field to autosuggest for uprn

Add hidden field to autosuggest, so RH can use autosuggest json blob for schools lookup and include uprn

Potentially needs to be part of component - is done elsewhere but not in this scenario. Was initially raised by Paul but no longer working on this. Still required but not an outstanding request.


Add error message for Storage Location Onboarding Page

Please describe the feature you'd like to see added.
Base on the feedback from mouxdesign and @GBKS in PR #397 add an error message if the storage location doesn't have enough space to store the necessary data.
Is your feature related to a problem, if so please describe it.
No response
Describe the solution you'd like

Solution Proposed by @GBKS

Describe any alternatives you've considered
No response
Please leave any additional context
No response

I'd go for the design on the left, where the reason is stated directly in the item.
Something to consider is whether that option should even be selectable in the first place. If the user lands on this page, and the default is disabled, we should just not auto-select any option.


Add integration tests

@scotthart you need to add labels to these  issues.  The tooling assumes they are bugs otherwise, and start pestering you and the rest of the team.


Is this Project Dead?

Yes and no. Vuido depends on libui and recently there's not much going on with it, so it's hard for this project to move much further. Proton Native, which is the equivalent of Vuido based on React, is currently migrating from libui to Qt; I would have to do the same with Vuido and I will when I have some time, but currently I'm trying to finish a big release of another project I'm working on.

For what it's worth, there is stuff going on in this tree for some months now: https://github.com/andlabs/libui/tree/remodel

guys what`s up?
Any news on this?

Yes and no. Vuido depends on libui and recently there's not much going on with it, so it's hard for this project to move much further. Proton Native, which is the equivalent of Vuido based on React, is currently migrating from libui to Qt; I would have to do the same with Vuido and I will when I have some time, but currently I'm trying to finish a big release of another project I'm working on.

I think it's actually pretty funny that people stall like this instead of just contributing to the other project... Well I don't like neither Qt nor React so I guess it's pure Gtk3 for now... Still, kinda sad to not even be able to contribute because such a chain reaction causes so many projects to stall (libui -> libui-nodejs -> vuido)...

Yes and no. Vuido depends on libui and recently there's not much going on with it, so it's hard for this project to move much further.

@mimecorg If still interested, please feel free to open any issues you have for upstream here. Thank you.

Looks like the project is really dead now!

There is now a next gen libui: https://github.com/libui-ng/libui-ng

vue-nodegui is probably a good alternative to this project.

@arafatamim nah, last commit 3 years ago


Offer helper to deserialize API response to an entity

We should offer a helper method to help developers deserialize API response to an entity.
While in most cases we handle deserialization in the SDK, there are some exceptions to it:

there's a new endpoint that's not yet in the SDK
developers are building a new middleware/handler where they work with raw requests and responses and need to parse the response body to an entity

While the first issue is exceptional, it's still blocking developers who need to wait for us to address the issue and release a new client.
Right now, deserializing API responses to entities require the following code:
var bodyBytes = System.Text.Encoding.UTF8.GetBytes(body);
using var ms = new MemoryStream(bodyBytes);
var parseNode = ParseNodeFactoryRegistry.DefaultInstance.GetRootParseNode("application/json", ms);
var operation = parseNode.GetObjectValue(ConnectionOperation.CreateFromDiscriminatorValue);

This code isn't intuitive and requires quite some Kiota knowledge. We should aim to make it as simple as:
var operation = JsonSerializer.Deserialize<ConnectionOperation>(body)>

Hi @waldekmastykarz ,
Thanks for suggesting this.
Assigning to @sebastienlevert to refine the developer experience here.
While a static method on the JsonSerializationWriter is easy, we need to think about a couple of things:

which serialization instance is the static method going to use? (make a new one? use the one in the registry?)
what are we supposed to do for collections and scalar properties? (expose multiple methods? use overloads with complex generic type constraints that are not going to be portable to other languages?)
how are we supposed to get the factory method for the type? (ask it to the end user? use reflection that's not going to be portable?)
what about the serialization scenario? (as been asked in the past)
what about the difference serialization formats?

Just capturing notes from our meeting now
An alternative could be to do binding instead of requesting the factory:
var fruit = new Fruit(); // user creates the instance
KiotaMagicMapper.Bind(fruit, "application/json", "{\"color\":\"red\",\"name\":\"apple\"}"); // standard deserialization code is being used
// would call ===>>> JsonParseNode.GetObjectValue(_ => instance); we don't need to ask for the factory since we already have the instance

This works well for objects, but starts breaking down for collections

What if we made it event easier? Each request builder is tied to an entity, right? What if we'd let developers pass either an entity or an object and if it's just an object (like what you get when you deserialize a JSON string), we create a new instance of the entity and bind the object to it? That way, developers don't need to learn any special concepts to use Kiota.

In most languages the serialization and deserialization information is tied to the object itself (class implements an interface).
We won't know what to do with the instance if it doesn't carry its serialization information.
That's because kiota leverages auto serialization to avoid relying on reflection. It's a bit less flexible but it's faster.

Right, but if we pass the entity type as part of the serialization then we could create a new instance of it and then overlay the regular object on top of it, right, say:
Kiota.Magic.Deserialize<Fruit>("application/json", "{{json string goes here}}")

and then inside Deserialize we create a new instance of Fruit because we've got a guard that it needs to be new()

and then inside Deserialize we create a new instance of Fruit because we've got a guard that it needs to be new()

This only works for dotnet, we've generally avoiding designing solutions that only work for a single language.

This is the most challenging (and most important) aspect of these designs. It needs to support existing (and even future) languages. This would not be a language-specific implementation.
I understand the concern and this might be something to be simplified on every language we support Graph (building another wrapper simplifying the experience). I still feel we should fix it upstream and make it as developer-friendly as possible before adapting the approach to Graph, for instance.
Also in the initial proposal from @baywet we are missing collection support. What would be missing to make this support scalar and collections?

This only works for dotnet, we've generally avoiding designing solutions that only work for a single language.

I understand that and appreciate that it's hard. Still, it shouldn't come at the cost of developer experience.

This is the most challenging (and most important) aspect of these designs. It needs to support existing (and even future) languages. This would not be a language-specific implementation.

The problem with this approach is settling for the lowest common denominator leading to a subpar experience for all developers, rather than making use of language-specific features that enrich developer experience. I wonder how many developers use several different languages and seek consistency across all of them vs. use one language and would like to fully benefit of its features.

My gut feeling tells me, that we should make the best use of language features and native patterns at the cost of inconsistency across languages. If we chose this route, then we'd need to investigate each language and its capabilities, which means more work and deviation but ideally a significantly better developer experience.

Part of the reason why we're not able to come up with a simple solution here is because we're not scoping/framing the problem well enough. I'm going to try to attempt that.
We want people to be able to easily (de)serialize models to/from a persistent storage. One of the keywords here is models ([collection of]? enums or classes/interfaces), which excludes [collections of]? primitives, for which they can use their favorite library to do so.
If we focus on object models for a second, the auto-serialization infrastructure does multiple things for us:

discriminated downcast support: e.g. deserializing to a User even though the expected type was Directory Object because of the OData Type property in the payload. This relies on the CreateFromDiscriminator method.
union/intersection types wrapper support: deserializing to the right member type. This relies on the CreateFromDiscriminator method.
deserializing the object type: relies on the getFieldDeserializers method (instance method in most languages, static function for TypeScript)
serializing the object type: relies on the serialize method (instance method in most languages, static function for TypeScript).
deserializing a enum member: relies on the parse static method.
serializing a enum member: relies on the serialize static method.

Now that we have a better understanding of what the infrastructure does for us today, let's add a couple of requirements:

we'd like to avoid reflection, due to the performance impacts and due to the reliability issues (no compile time validation, needed members might be trimmed, etc...)
do we need to support discriminated downcast? @sebastienlevert (I think it's a false issue because of the other requirements)
do we need to support union/intersection types wrappers? (same reasoning)

With all that in mind, here is my suggestion: binding is now going to work for TypeScript specifically.
// Deserializing an object
Kiota.Magic.Deserialize("application/json", "{{json string goes here}}", Fruit.CreateFromDiscriminatorValue);
// Deserializing a collection of object
Kiota.Magic.DeserializeCollection("application/json", "{{json string goes here}}", Fruit.CreateFromDiscriminatorValue);
// Deserializing an enum value
Kiota.Magic.DeserializeEnum("application/json", "{{json string goes here}}", FruitKind.Parse);
// Deserializing a collection of enum values
Kiota.Magic.DeserializeEnumCollection("application/json", "{{json string goes here}}", FruitKind.Parse);
//Serializing an object
Kiota.Magic.Serialize("application/json", streamReference, myFruit);
//Serializing an object collection
Kiota.Magic.SerializeCollection("application/json", streamReference, myFruits);
//Serializing a enum value
Kiota.Magic.SerializeEnum("application/json", streamReference, myFruitKind);
//Serializing a collection of enum values
Kiota.Magic.SerializeEnumValues("application/json", streamReference, myFruitKinds);

Note: I'm using different method names for serialize/deserialize as in some languages we'll need different method names (no overloads), but in dotnet, I believe we could sensibly have the same method name.

Thoughts?

This is a great investigation @baywet!
I think Kiota.Serialization.* should be part of our abstractions and would rely on the downstream serializers. So I would absolutely  see something like this:
// Deserializing an object
Kiota.Serialization.Deserialize("application/json", "{{json string goes here}}", Fruit.CreateFromDiscriminatorValue);
// Deserializing a collection of object
Kiota.Serialization.DeserializeCollection("application/json", "{{json string goes here}}", Fruit.CreateFromDiscriminatorValue);
// Deserializing an enum value
Kiota.Serialization.DeserializeEnum("application/json", "{{json string goes here}}", FruitKind.Parse);
// Deserializing a collection of enum values
Kiota.Serialization.DeserializeEnumCollection("application/json", "{{json string goes here}}", FruitKind.Parse);
//Serializing an object
Kiota.Serialization.Serialize("application/json", streamReference, myFruit);
//Serializing an object collection
Kiota.Serialization.SerializeCollection("application/json", streamReference, myFruits);
//Serializing a enum value
Kiota.Serialization.SerializeEnum("application/json", streamReference, myFruitKind);
//Serializing a collection of enum values
Kiota.Serialization.SerializeEnumValues("application/json", streamReference, myFruitKinds);

Also to confirm with your reasonning, where you put {{ json string goes here }} am I right to think that it should be {{ string of the body goes here }} in scenarios where this is not JSON? We're pushing json in all examples, but I feel this could be supported the exact same way for other serializers / deserializers.
To your questions:

do we need to support discriminated downcast? Yes as it relies on the discriminator anyways.
do we need to support union/intersection types wrappers? Yes as the type you'd pass is a union type anyways.

To the other formats: yes, this is why we ask for the mime type as well. This way we could rely on the infrastructure to parse or serialize to any format.
Great, I think we have a plan. I'd like @waldekmastykarz 's opinion on the experience here as well in case we missed anything.

Being able to serialize/deserialize using the Kiota infrastructure, at least from/to Json in a convenient way is truly desirable.
I'll try to have a look at the details of this proposal tomorrow.

I'd like us to simplify it further and avoid exposing Fruit.CreateFromDiscriminatorValue, Fruit.Parse etc. to client consumers. These are new concepts that developers likely aren't familiar with, that require them to understand the difference and when to use which and steepen the learning curve. Is there a way for us to infer those methods from the types they pass, so that we can use something like:
Kiota.Magic.Deserialize<Fruit>("application/json", "{{json string goes here}}")
which is closer to the standard serializations folks are already familiar with?

Looking at the proposal I think that it's still including a bunch of details that can be hidden for the user:

"application/json" having to pass it as a string look error prone as this is gonna be user, hand-written code. I think that directly exposing a specific API would be great e.g. Kiota.JsonSerialization...

Please note that I'd expect Json to be the only "required" serialization format, at least in this first interaction.

CreateFromDiscriminatorValue and Parse seems like implementation details and I would avoid asking the user to invoke them directly. What we can do is to have a Dictionary<Class, DeserializationFunction> generated and the final API can look something similar to:

Kiota.JsonSerialization.Deserialize(inputStream, Fruit.class)
Kiota.JsonSerialization.Serialize(myFruit)

This is the kind of API I would aim for, I'm sure that this proposal doesn't cover all the edge cases yet, but is the best I can put together on my phone :-) and I'm convinced that it captures the gist of it.
Overall more opinionated and less control for the user in favor of a minimal and convenient API.

Thanks for iterating on the proposal Vincent! Much appreciated!

the challenge with those proposals is that they'll require reflection.

I think this can be solved without reflection, but let's doublecheck:
The proposed signature,
Kiota.JSonSerialization.Deserialize("{{json string goes here}}", Fruit.GetType());

can be implemented as an overload similar to:
public T Deserialize(string jsonString, Type classType) {
   var mappings = new Dictionary<Type, Function<.., ...>> { { Fruit.GetType,  Fruit.CreateFromDiscriminatorValue } }
  Deserialize(jsnoSreing, mappings.TryGetValue(classType))
}

would you consider adding this as an "optional" feature, like the BackingStore?

Thanks for the suggestion.
The challenge with this approach is that it'll effectively make the models non trimmable (dotnet, typescript, etc...) as ALL models will be referenced in this method, as soon as this method is referenced by the client code. This can have serious impacts on the resulting "binary" size.
Plus GetType makes use of some level of reflection as well, though we could circumvent that by using the type name in the mapping to some extent.

Thanks for elaborating!
What do you think about making this entirely separate from the "main" generation, e.g. a difference CLI command kiota generate-serde-helpers ?

Let me address to two scenarios differently:

there's a new endpoint that's not yet in the SDK

If "the SDK" means Graph, then I believe it is safe to assume the developer has an understanding of the Graph response (by using Graph Explorer). They would likely know the Model type (or be creating one if it is new).
What they likely do not know is the SDK inner workings. Here is how I would approach it:

I can see there are methods to get a request information object. So I'm going to create one, passing in the new endpoint.  (Using C# since that is what I know.)
var endpoint = $"{graphClient.RequestAdapter.BaseUrl}/somenewthing/{thing1}";
var ri = new RequestInformation() { URI = new Uri(endpoint), HttpMethod=Method.GET };

The GraphServiceClient object that I have already knows how to authenticate and send the request. So I look at the definition of GraphServiceClient, and the only "thing" I see that might help is the RequestAdapter. The SendXXX methods of that class require a parseable factory. Huh?

I reviewed the docs for the Graph SDK  with no help.

Since I see Kiota in the namespace for this factory, I can look at its docs. The page on Request builders looks promising, but since this is the new endpoint scenario I have to build one myself. The BaseRequestBuilder is abstract so I can't use that. Now I need to go learn how to build one of those. Not likely to happen.

4a. I just realized I have a RequestInformation object, not a RequestBuilder. Never mind...

I reviewed the Kiota Serialization and Models pages, and I am a bit overwhelmed. I just want to send a request. Poking around, I see a JsonParseNodeFactory
var factory = new Microsoft.Kiota.Serialization.Json.JsonParseNodeFactory();
var t = await graphClient.RequestAdapter.SendAsync<SomeNewThing>(ri, factory);

This won't compile because: There is no implicit reference conversion from 'SomeNewThing' to 'Microsoft.Kiota.Abstractions.Serialization.IParsable'.

I now understand why this scenario was in the original post. But, even if you give me a way to deserialize the response, how do I send the request? I need an IParseable object to use the RequestAdapter.
The v4 SDK (again, .Net) had providers exposed off the GraphServiceClient, so I could just use them:
var hrm = new baseRequest(endpoint,graphClient).GetHttpRequestMessage();
await graphClient.AuthenticationProvider.AuthenticateRequestAsync(hrm);
var operationResponse = await graphClient.HttpProvider.SendAsync(hrm);

I'm struggling to see how I can avoid just making the HttpRequest myself (authenticating it "manually") and deserializing the response to a custom Model. But for devs who just use the ICredential class instead of understanding Entra token acquisition, they would be stuck. Either call for help or spend a lot of time figuring it out.
In summary, I believe this scenario needs to solve more than just serialization.

developers are building a new middleware/handler where they work with raw requests and responses and need to parse the response body to an entity

In this scenario, I would expect something similar to the way we deserialize everywhere else: JSON.parse() or JsonConvert.DeserializeObject(stream).
My preference would be something close to Andrea's suggestion: Kiota.JsonSerialization.Deserialize(inputStream, Fruit.class). I understand you need to figure out the reflection/trimming bits, but that signature is closer to what I would expect to find.

Thanks for setting the context here @pschaeflein
I don't think the "there's an endpoint that's not in the SDK yet" is a valid scenario here because (and yes, I didn't catch that in the initial message):

Kiota's value is to be able to refresh clients on the spot.
Microsoft Graph customers get a refresh weekly, which is as often as the service gets updated. (2 days lag)

As for making arbitrary requests, I'll reiterate: the RequestInformation/Request Adapter API surface was never meant to be used by humans, it only supports the generated code. People should be using the native client for those scenarios, augmented with the set of middleware handlers we provide. What's missing here is an optional middleware that'd take an access token provider to handle the authentication automatically for people. Maybe we can queue that separately @sebastienlevert .
With this, I think we should be able to scope this issue to "I have/want a JSON representation of a model, without having to send a request, how do I do that more easily than done today?" (e.g. persisting things to storage, etc...) Hence the proposals.
I think your feedback confirms the fact that consumers don't want to figure out the factory pattern if we can avoid them having to do so. Some might for performance reasons, so we should not lock them out, but most don't.
Lastly, to @andreaTP 's last comment, I think adding a separate command adds to the complexity and doesn't make things easier. If people are struggling to find the factory method, how are they going to know that they need to generate additional assets?

With this, I think we should be able to scope this issue to "I have/want a JSON representation of a model, without having to send a request, how do I do that more easily than done today?" (e.g. persisting things to storage, etc...) Hence the proposals.

I agree that this is the end goal of this effort, I have been there, loading Json representations from disk to feed the http calls and felt the gap.

how are they going to know that they need to generate additional assets?

Again here you are right, but, as anything in software, this is gonna be a tradeoff.
In this case we are talking about a convenience for developers, and, I believe that having to balance this requirement with code size is not going to fly...
Have we considered the effort of building it as an(almost?) independent, stand alone, library(even using reflection and stuffs)?

A separate library just for this functionality feels like a lot of ceremony, both for us as maintainers but also for the consumers from a discovery standpoint.

I don't think the "there's an endpoint that's not in the SDK yet" is a valid scenario here because (and yes, I didn't catch that in the initial message):

Kiota's value is to be able to refresh clients on the spot.
Microsoft Graph customers get a refresh weekly, which is as often as the service gets updated. (2 days lag)

Looking at it from our developers' point of view: I'm working on a project and came across something that's not in the SDK (we just found one the other day where creating external connection was described using an incorrect verb in API description). Now I'm blocked for 2 days (not to mention the time to create an issue in the repo to report the problem and have it triaged and sorted out by the right person which will take longer if the issue stems from a mistake in the API description that needs to be fixed first) with no way out. Our developers won't wait for two days and will look for other ways to get the job done, including not using our SDKs (that's always an option they have).
I fully agree that something missing in our SDKs is highly exceptional and we aim to always reflect what's on the API. That said, when it happens, and we offer developers no way to solve it, we risk losing them and never coming back. I'd rather have an escape catch that they can use in such cases, so that they can keep using our tooling.

@waldekmastykarz, I understand the pain here, and I think this is largely outside of this discussion.
As you're aware, we have a number of efforts to drive better metadata quality and close those gaps across the boards (SDKs, snippets, etc...): TypeSpec to produce better metadata to begin with (long term), XOD in the metadata repo (short term patches), funneling feedback  to service teams (arguably, we had mitigated success with this approach), raptor to catch miss alignments between snippets-metadata-sdks....
Please make sure you create a new issue in the metadata repository when you come across those gaps so we can address them one way or another.
But if we make the assumption that there'll always be metadata gaps in the case of Microsoft Graph (again, I believe this is mostly a Graph concern), sure, we need to enable arbitrary queries from the native client, while reusing most of the infrastructure we built up, and reusing models when available for the scenario (To Paul's point). This takes:

A way to get a native http client with our middleware infrastructure ✔
A way to authenticate the requests (possible today, but complex, maybe @sebastienlevert can drive an additional work item)
A way to (de)serialize generated models into/from a payload (what we're enabling here).

With those parts in place, I believe we'll enable most if not all scenarios we've talked about here.

You also need:
2.5. A (simpler) way to send the request thru the configured pipeline.
In the v4 .Net client, it is graphClient.HttpProvider.SendAsync(). The v5 equivalent is way more complex.

We have a huge gap in the documentation on the kiota side, that's for sure.
But effectively for dotnet getting a native client augmented with the middleware looks something like that
using var client = KiotaClientFactory.Create();
// we're probably missing a middleware for authentication as stated in 2
using var response = await client.GetAsync("url");
//... do something with the response

I started working on this over here
Here are a the methods for deserialization:

DeserializationHelpers.Deserialize() x 4 (content type, string/stream, factory?)
DeserializationHelpers.DeserializeCollection() x 4 (content type, string/stream, factory?)
JsonDeserializationHelpers.Deserialize() x 4 (string/stream, factory?)
JsonDeserializationHelpers.DeserializeCollection() x 4 (string/stream, factory?)

Also this is all in abstractions since all of them are just helper methods, and it'll make it so people can also use the Json shorthand with any implementation this way.
I don't think we actually need to do the enum as:

the enum values are usually part of a larger payload, and are not the entry point.
when enum are the entry point, they are just a text representation at the end, and people can use the Parse/ToString methods directly.
if demand shows up for that scenario, we can always add it later.

So here are a couple of questions for you fine folks:

What do you think about the naming of static classes?
What do you think about the naming of of the methods?
What do you think about not including enums as the entry point for now?

the challenge with not having the helpers (or something else) in the class name is the fact that we have namespace names with "Serialization" segments. This is going to create headaches for people when they try to use the class as the compiler won't know whether they are trying to fully qualify a class, or making a reference to the class we're building. We need to have a prefix, or a suffix to avoid these issues.
ok
cost is not super high, it's just they don't add value. (except maybe for the version with reflection)
ok

Why not using the same naming conventions from JsonSerializer in .NET? JsonSerializer.Deserialize(). This would not conflict, right?
I assume the biggest advantage is to use the same mechanism compared to a "totally" other way. Similar to handling collections right. Maybe we should know that it's either an object, a collection or an enum? What are the downsides of having a single approach (and set of methods) for all of these scenarios?

I would prefer "KiotaConvert.Deserialize", but as long as it is documented I could live with it.
These are fine
As long as the properties of Entities are set to the correct Enum value, that's fine.
One class. JsonConvert has both Serialize and Deserialize. I would expect it to match that.

(seb) Using the same name as known static classes from other libraries/the runtime is a bad idea. It'd require people to alias their usings or to fully qualify things when both are in scope. This would be a poor experience. (paul) yep, I'm happy with that name, or maybe KiotaSerializer to blend with what Seb suggested?
Seb, you messed up the numbering.
(paul) yes that's going to be the case as everything after the root type will rely on auto-serialization. (seb with the right number) overloads could work in dotnet, will not in a number of languages.
ok (but contradicts Seb's initial opinion)

I numbered them well, but them markedown decided that a list with only 1 and 3 was not going to make it!

I meant a "similar" approach, but definitely not reusing the .NET one. My bad. I'm happy with KiotaSerializer to mimic .NET.
Yes, I messed up.
Then, native seems to be reasonable.
If we use a single KiotaSerializer then I'm with Paul.

Thanks everyone for the great feedback.
I haven't had time to incorporate it just yet, but I worked on the serialization scenarios:

SerializationHelpers.SerializeAsStream x2 (contentType, single object/collection)
SerializationHelpers.SerializeAsString x2 (contentType, single object/collection)
JsonSerializationHelpers.SerializeAsStream x2 (single object/collection)
JsonSerializationHelpers.SerializeAsString x2 (single object/collection)

Granted that SerializationHelpers will become KiotaSerialization and JsonSerializationHelpers will become KiotaJsonSerialization, what do you think about the method names?
I had to add the AsStream and AsString since they have the same arguments. And I was able to make it work with the same name for collections and single objects (which arguably is not consistent with the deserialization from out last discussions)

Those are good.

if they're coming from a Kiota namespace, then we're unnecessarily repeating Kiota in the full name

Is that really a big deal? I can only speak to C# and Typescript, but I cannot remember the last time I compared the using/import statements with the code in the body of a method. In fact, I only look at using/import when I first use a namespace. Having a repeated name in the namespace is way better than having to figure out the alias syntax of using. (Which, in fact, I had to look up right now to know what the name of the thing was.) I often use the fully-qualified name in the method to avoid this situation.

if they're coming from the client namespace, then we're leaking client implementation details to client consumers (I doubt folks who use our clients care how we build them internally)

If I come across this scenario, we WANT to know the implementation details. I'm only here because the client does not do what I need.
Just my thoughts...

I doubt folks who use our clients care how we build them internally

This is where I think we need to leak some of it. A library that is built with Kiota needs to be configured and customized with Kiota concepts anyways. In this case, I feel KiotaSerialization is the right place to start.

Thanks everyone for the great input here! I think we have everything we need, I'll move on the replicating to other languages now.

For go we won't have the reflection methods as it's impossible due to the way things are compiled as far as I understand more information

I'm also not going to add the string overloads as this is a trivial operation in Go that most developers are familiars with (string to byte[] and vice vera)

Additionally, because Go (and TypeScript) has a notion of static functions (not attached to a class/struct), the naming I went with will be the following:

SerializeToJson
DeserializeFromJson

The alternative being to use the same name as the functions that require passing the content type, but being in a sub-package. This would work well for Go as you need to prefix symbols with their package import name (like json.Serialize(...)) but breaks down a little for TypeScript as if somebody wants to use both methods in the same scope, they'll have to declare aliases to avoid collisions.

I just submitted the PR for TypeScript. An additional note is that for both serialization and deserialization we need to as for the serializer and the deserializer function for the model. This is because interfaces get erased at runtime and there's no good way to get these methods by reflection.

closing since it's been implemented in 4 canonical languages and related issues have been created for other languages.

For anybody finding this issue while searching for a way to deserialize JSON to Kiota object model instance.
Waldek's approach did NOT work for me:
var bodyBytes = System.Text.Encoding.UTF8.GetBytes(body);
using var ms = new MemoryStream(bodyBytes);
var parseNode = ParseNodeFactoryRegistry.DefaultInstance.GetRootParseNode("application/json", ms);
var sitePage = parseNode.GetObjectValue(SitePage.CreateFromDiscriminatorValue);

It throws:
An exception of type 'System.InvalidOperationException' occurred in Microsoft.Kiota.Abstractions.dll but was not handled in user code: 'Content type application/json does not have a factory registered to be parsed'
Further googling lead me to this, which works:
var jsonParseNode = new JsonParseNode(JsonDocument.Parse(body).RootElement);
var sitePage = jsonParseNode.GetObjectValue<SitePage>(SitePage.CreateFromDiscriminatorValue);

Source was over here, at a similar issue: https://github.com/microsoftgraph/msgraph-sdk-dotnet/issues/1708#issuecomment-1467658543
Developers gonna develop. As long as I can google something and it works :stuck_out_tongue:

if you new up a client before calling ParseNodeFactoryRegistry.DefaultInstance.GetRootParseNode("application/json", ms) waldek's approach will work.
And now we have facilitator methods, so you can directly call KiotaJsonSerializer.Deserialize<SitePage>(body) instead of the four lines.

@baywet Ah! Was not sure if that arrived in C#, yet. Looks good.
But first-use experience for me also is this:
Exception has occurred: CLR/System.InvalidOperationException
An exception of type 'System.InvalidOperationException' occurred in Microsoft.Kiota.Abstractions.dll but was not handled in user code: 'Content type application/json does not have a factory registered to be parsed'
   at Microsoft.Kiota.Abstractions.Serialization.ParseNodeFactoryRegistry.GetRootParseNode(String contentType, Stream content)
   at Microsoft.Kiota.Abstractions.Serialization.KiotaSerializer.Deserialize[T](String contentType, Stream stream, ParsableFactory`1 parsableFactory)
   at Microsoft.Kiota.Abstractions.Serialization.KiotaSerializer.Deserialize[T](String contentType, String serializedRepresentation, ParsableFactory`1 parsableFactory)
   at Microsoft.Kiota.Abstractions.Serialization.KiotaSerializer.Deserialize[T](String contentType, String serializedRepresentation)
   at Microsoft.Kiota.Abstractions.Serialization.KiotaJsonSerializer.Deserialize[T](String serializedRepresentation)
   at WikiTraccs.Tests.ConversionTests.TestOptionalTransformations.JsonToSitePage(String body)

This is in unit tests, so there is no client yet.
Running this before makes it work:
_ = new GraphServiceClient(new Mock<IAuthenticationProvider>().Object, null);
No one liner anymore, but nevertheless nice, that KiotaJsonSerializer. Thanks for the heads-up.

I have the exact pb.
But what should happen if you have a custom Deserializer? How will that work with KiotaJsonSerializer?

Assuming this custom deserializer is for JSON as well.
You effectively need to register it in the application.
This is done by default by the generated client when it's instantiated today. (so you can just new up the client before calling the static methods)
Or you can call the dedicated registration method like in this example