"AddSystemsManager" method doesn't work with DI and .Net 6

Describe the bug
Hi there,
My issue is similar with the one below which found by another developer -
https://stackoverflow.com/questions/71324248/c-sharp-aws-parameter-store-configuration-not-loading-systemmanagerconfigurati/72710278
From the sample code, it created and loaded parameters successfully in "PopulateSampleDataForThisProject" method (this means there's no issue with my AWS account), "AddSystemsManager" method was also called successfully however when consuming those settings in "ValuesController", the setting values are always default values of each data type not the values from AWS parameter store.
Initially I thought it was issue of my code, however after checked out this code repo, the same issue happens for "Samples" project as well.
Is this related to .Net 6?
Expected Behavior
"AddSystemsManager" method should work with DI, setting values loaded from AWS Parameter Store should be available when cumsuming "IOptions Settings" in project.
Current Behavior
"AddSystemsManager" method loaded parameters from AWS successfully (I can see those values from builder's configuration providers), however when consuming "IOptions Settings" in project, the settings values are not the values from AWS Parameter Store, so it's sth. wrong with DI
Reproduction Steps

Using "Samples" project in this code repo
Run the project, the parameters defined "PopulateSampleDataForThisProject" method are created and loaded successfully
Open "ValuesController" in web browser, the setting values are just default value of each data type, not the values loaded from AWS Parameter Store

Possible Solution
No response
Additional Information/Context
No response
AWS .NET SDK and/or Package version used
Amazon.Extensions.Configuration.SystemsManager 3.0.0
Targeted .NET Platform
.Net 6
Operating System and version
Windows 10

OK, I found the reason now, the "Samples" project missed one line of code as below -
builder.Services.Configure<Settings>(builder.Configuration.GetSection($"common:settings"));
After added above line, it works as expected.

This is other thread where issue was pointed out and a fix was provided, making it visible for others to discuss which is better way of solving this.
https://github.com/aws/aws-dotnet-extensions-configuration/issues/109#issuecomment-1057714536

OK, I found the reason now, the "Samples" project missed one line of code as below - builder.Services.Configure<Settings>(builder.Configuration.GetSection($"common:settings")); After added above line, it works as expected.
I don't have permission to publish new feature branch in this code repo, otherwise would create a PR to fix this issue.

@zhlei616 Just to reconfirm, the sample application needs an update to fix the issue. Is this correct? You should be able to fork the repo and then create the PR.
Thanks,
Ashish

OK, I found the reason now, the "Samples" project missed one line of code as below - builder.Services.Configure<Settings>(builder.Configuration.GetSection($"common:settings")); After added above line, it works as expected.
I don't have permission to publish new feature branch in this code repo, otherwise would create a PR to fix this issue.

@zhlei616 Just to reconfirm, the sample application needs an update to fix the issue. Is this correct? You should be able to fork the repo and then create the PR.
Thanks, Ashish

@ashishdhingra , yes the "SystemManager" project itself is fine, the issue is in "Samples" project only.
I've created a PR for this - https://github.com/aws/aws-dotnet-extensions-configuration/pull/115

Issue has been fixed in https://github.com/aws/aws-dotnet-extensions-configuration/pull/115 which has been merged.


Add structured data markup on the PDP

For SEO purposes its best practice to add markup / rich product information for Google and other bots to index product attributes.  More information and markup examples here - https://developers.google.com/search/docs/data-types/product
And here are some tools to help
Use this to create structured data -  html- https://www.google.com/webmasters/markup-helper/u/0/?verticalId=4801&sourceId=103857157
Use this to test your structured data -
https://search.google.com/structured-data/testing-tool

Background
https://developers.google.com/search/docs/data-types/product
https://json-ld.org/
Work
Add JSON-LD script for Google's Product schema at the bottom of the PDP page component.

@aldeed For the "AggregateRating" (value and count) we would probably need to identify if the ratings and reviews plugin is installed and if so then these values should come from there.

@vwadher I think that it may need to be up to the plugin to add additional structured data such as rating information.

@vwadher @spencern @aldeed
Do we want to use OutOfStock of SoldOut for the product availability? https://schema.org/ItemAvailability
Or do we want to switch that up depending on if backorder is allowed or not?

@kieckhafer @spencern @aldeed I'd say this ought to replicate & be dependent on whatever the merchant setting is on the store.  Showing the availability of a product (especially one that is demand and is in stock) can help increase the click-through rate in addition to the conversion rate.

@kieckhafer The docs don't really say, but I'm guessing the assumption is that "OutOfStock" is temporary but "SoldOut" is permanent? If so, then yes I guess "Backordered" maps to "OutOfStock", else "SoldOut".
But, as @vwadher pointed out, labeling a backordered item as OutOfStock might result in the loss of a click-through because the person assumes that out of stock can't be ordered, even though they could order it. So maybe we should tag backordered ones with "InStock" even though that's not 100% true.

@aldeed I'd say "backorder" should map out to = https://schema.org/PreOrder

@vwadher @aldeed what about prices? Since this data is on the "Product" and not the "Variant" or "Option", we need to choose one of the prices to display as "the price".
I have it set right now to show the minimum / lowest variant / option price as the price. What do you think?

@kieckhafer I agree with your approach.


Closes #562 - Enable metrics to be written multiple times within a rule and scope

This change is

@JonasKunz @mariusoe So I pushed small update to fix the review comments I had (since Jonas is on the vacation).


Feature Suggestion: Sega CD Transfer Suite Integration

It would be awesome if RetroNAS could support direct Megadrive/32X sumping using a custom parallel cable and the Sega CD Transfer Suite. https://www.retrodev.com/transfer.html. This is all win32 code, and doesn't like to run on 64 bit versions of Windows. I'm not the original writer, just a user. I'd love to see this could be rewritten, or made working in Wine then integrated into the menu system.

I am a fan of Mike's tools, I have this adapter built and a modded console to use with it. I normally apply this to dump my own carts, I haven't yet used the transfer suite side of things, its been on my list of things to do, I can test at least test it.
Can you drop some some basic instructions here with the specific usage of transfer.exe with an example in this issue?
In regards to RetroNAS integration this would fall under on device management which we need to think about scope
In this space I'd have a note to investigate integrating ucon64 as a general purpose tool for many devices in the first instance but I need to see if i can get it to compile on arm first, then spec that out across platorms
I don't know how I feel about wine overhead for windows tools at this stage, something else to thing about

My apologies for any confusion. I too use the adapter and tools to dump my own carts. I have not actually utilized the transfer function.
Big thanks to mentioning ucon64 and considering it. I wasn't even aware this tool existed. Given it supports the Sega CD transfer suite, it may fulfill the intent of this feature request.
I'm running RetroNAS on x86. I'll do some experimenting.

ucon64 on rpi can't be compiled with parallel device support on an a missing libc header, arguably fair enough no parallel ports on the thing. I will have to muck around and see what I can do before this becomes a reality, ucon64 on rpi has has been a thing i've wanted for a while so am happy to give it a go.


ClipPath appears to be broken

Hello! I'm trying to use ClipPath to cut a circle in a rect in order to highlight what is underneath that circle. Issue #936 covers this and there is a handy answer that says this code should do it:
import React from 'react';
import { View } from 'react-native';
import Svg, { Defs, ClipPath, Circle, Rect } from 'react-native-svg';

export default class App extends React.Component {
  render() {
    return (
      <View
        style={{
          flex: 1,
          alignContent: 'center',
          justifyContent: 'center',
          backgroundColor: '#ecf0f1',
        }}
      >
        <Svg width="100%" height="100%" viewBox="0 0 100 100">
          <Defs>
            <ClipPath id="clip_out" clipRule="evenodd">
              <Rect width={100} height={100}/>
              <Circle cx={50} cy={50} r={25}/>
            </ClipPath>
          </Defs>
          <Rect width={100} height={100} fill="green" clipPath="url(#clip_out)" />
        </Svg>
      </View>
    );
  }
}

Unfortunately the circle does not get cut out. It seems that ClipRule may be failing, but I'm not sure. Here is a snack that shows the behavior.

It seems this has been broken on iOS since this commit which first came in v7.0.0: https://github.com/react-native-community/react-native-svg/commit/a1097b8
Handling of clipRule="evenodd" behaves more like clipRule="nonzero"
I remember having tested that this was working, not sure if something has changed in the ios api, I'm probably just remembering wrong and it's been broken all along. Will have to investigate a bit more.
Android seems to work since https://github.com/react-native-community/react-native-svg/commit/766926f
I've released patch version of the v6, v7 and v8 branches, such that they work with the latest react-native version. If you're in need of clipRule evenodd I recommend you use v6.5.3 or the v6 branch, or make a fix and open a pull request. Those two commits touch all the most essential parts relating to this issue, and how it was fixed on android.

Another workaround is to use a single Path in the ClipPath:
import React from 'react';
import { View } from 'react-native';
import Svg, { Defs, ClipPath, Path, Rect } from 'react-native-svg';

export default class App extends React.Component {
  render() {
    return (
      <View
        style={{
          flex: 1,
          alignContent: 'center',
          justifyContent: 'center',
          backgroundColor: '#ecf0f1',
        }}
      >
        <Svg width="100%" height="100%" viewBox="0 0 200 200">
          <Defs>
            <ClipPath id="clip">
              <Path
                d="M0 0 h200 v200 H-200 z
                 M 100, 100
                 m -75, 0
                 a 75,75 0 1,0 150,0
                 a 75,75 0 1,0 -150,0"
              />
            </ClipPath>
          </Defs>
          <Rect width={200} height={200} clipPath="url(#clip)" />
        </Svg>
      </View>
    );
  }
}

I think I've fixed this in the develop branch: https://github.com/react-native-community/react-native-svg/commit/5389209a64debc4b9242232b2fa51403e33aea35
Could you test it?
I'm not completely sure if this breaks something else. Would need more test cases in end-to-end tests.

Seems at least this example might not conform to the spec now: https://github.com/react-native-community/react-native-svg/issues/752
This probably requires making a few more examples and comparing to browsers, etc.
I guess ios will require similar logic as android, enabling to take the union of the paths.

Think I fixed it in a way which doesn't break the other case now. But I realized it's not fully spec conformant either. I've also added support for using the Use element inside ClipPath now. But the implementation of clipRule should probably be revised to only affect elements inside ClipPath. The behavior actually breaks the spec, and doesn't work in browsers. You would need to use a single path with clip-rule / fill-rule to do it in a web-compatible and spec conformant way:
import React from 'react';
import { View } from 'react-native';
import Svg, {
  Defs,
  ClipPath,
  Path,
  Rect,
  G,
  Text,
  Polygon,
  Use,
} from 'react-native-svg';

const SvgComponent = props => (
  <Svg width="100%" height="30%" viewBox="0 0 140 110" {...props}>
    <Defs>
      <Path
        id="prefix__a"
        d="M25 10a20 20 0 1 0 0 40 20 20 1 1 0 0-40m20 0a20 20 0 1 0 0 40 20 20 1 1 0 0-40"
      />
      <ClipPath id="prefix__b" clipRule="nonzero">
        <Use xlinkHref="#prefix__a" clipRule="nonzero" />
      </ClipPath>
      <ClipPath id="prefix__c" clipRule="evenodd">
        <Path
          id="prefix__a"
          y={50}
          d="M25 10a20 20 0 1 0 0 40 20 20 1 1 0 0-40m20 0a20 20 0 1 0 0 40 20 20 1 1 0 0-40"
        />
      </ClipPath>
      <ClipPath id="prefix__d" clipRule="evenodd">
        <Use xlinkHref="#prefix__a" clipRule="evenodd" y={50} />
      </ClipPath>
    </Defs>
    <Path clipPath="url(#prefix__b)" fill="#6495ed" d="M0 5h70v50H0z" />
    <Text x={15} y={54} fontSize={5} fill="#fff">
      {'non-zero clip-rule'}
    </Text>
    <Use xlinkHref="#prefix__a" x={70} stroke="#6495ed" />
    <Text x={86} y={54} fontSize={5} fill="#fff">
      {'non-zero fill-rule'}
    </Text>
    <G>
      <Path clipPath="url(#prefix__d)" fill="#daa520" d="M0 55h70v50H0z" />
      <Text x={14} y={105} fontSize={5} fill="#fff">
        {'even-odd clip-rule'}
      </Text>
    </G>
    <G>
      <Use
        fillRule="evenodd"
        xlinkHref="#prefix__a"
        x={70}
        y={50}
        stroke="#daa520"
      />
      <Text x={85} y={105} fontSize={5} fill="#fff">
        {'even-odd fill-rule'}
      </Text>
    </G>
  </Svg>
);

const SvgComponent2 = props => (
  <Svg height="90" width="100" viewBox="0 0 100 90">
    <Defs>
      <Path d="M50,0 21,90 98,35 2,35 79,90z" id="star" fill="white" />
      <ClipPath id="emptyStar" clipRule="evenodd">
        <Use href="#star" clipRule="evenodd" />
      </ClipPath>
      <ClipPath id="filledStar" clipRule="nonzero">
        <Use href="#star" clipRule="nonzero" />
      </ClipPath>
    </Defs>
    <Rect clipPath="url(#emptyStar)" width="50" height="90" fill="blue" />
    <Rect
      clipPath="url(#filledStar)"
      width="50"
      height="90"
      x="50"
      fill="red"
    />
  </Svg>
);

const SvgComponent3 = ({ clipRule = 'nonzero' }) => (
  <Svg width="50%" height="500">
    <Defs>
      <ClipPath id="windowClip" clipRule={clipRule}>
        <G>
          <Rect x={30} y={50} height={100} width={100} />
          <Text x={30} y={70} fontSize={40}>
            Hello world
          </Text>
          <Rect x={30} y={200} height={100} width={100} />
          <Rect x={100} y={250} height={100} width={100} />
          <Rect x={30} y={370} height={100} width={100} />
          <Polygon
            transform="translate(70,400)"
            points="0,0 0,100 100,120 120,0"
          />
        </G>
      </ClipPath>
    </Defs>
    <Rect height="100%" width="100%" fill="#0af" clipPath="url(#windowClip)" />
  </Svg>
);

export default class App extends React.Component {
  render() {
    return (
      <View
        style={{
          flex: 1,
          alignContent: 'center',
          justifyContent: 'center',
          backgroundColor: '#ecf0f1',
        }}
      >
        <SvgComponent />
        <SvgComponent2 />
        <View
          style={{
            flex: 1,
            flexDirection: 'row',
          }}
        >
          <SvgComponent3 />
          <SvgComponent3 clipRule="evenodd" />
        </View>
      </View>
    );
  }
}

Can you please test the latest commit in the develop branch: https://github.com/react-native-community/react-native-svg/tree/develop
e.g.
yarn add react-native-svg@react-native-community/react-native-svg#76b8b82

https://codesandbox.io/s/yvl8r2jl6z

I'm thinking of suggesting to add support for clip-rule on the clip-path element for svg 2.0 or later. This seems like a very useful thing, and much more efficient than using a mask.

Noticed a caching bug in android, fixed in latest commit of develop branch:

The latest commit on the dev branch (fde018b) is working beautifully! At least on iOS. I'll test on android in a bit but I imagine it will be good too. Thank you!!

Working on android as well!

I initially thought everything was going fine on android, but actually our app's performance has plummeted on android only. We've upgraded a lot of things recently, but after intensive debugging we were able to narrow it down to this library. Something is causing the app to freeze/die with no error messages. As we disabled more and more Svg components the app stayed alive longer, but after enough clicking around it would freeze/die again. I doubt it's a new issue with the development branch, but I will test it on master soon.
I'm sure you'll want a reproduction so after we confirm it's happening on master we'll see if we can figure out how to get a repro.

Oh, sorry to hear. Yeah a reproduction would certain make a huge difference in potential to fix it. I suspect it's related to handling of layout / bounds calculations and communicating this to android and react-native such that the gesture responder system would work correctly. There's probably some calls happening which aren't needed. If you make a good reproduction, it's probably possible to git bisect to find the commits causing the regression, and it'll likely be related to the gesture and bounds work. What version(s) did you use before?

Also, measuring where the time is spent using android studio might reveal where the time/memory is spent and what is causing it.

We spent a lot of time in the profiler and really haven't been able to track much down. The heap seemed to just be overwhelmed easily which would sometimes lead to crashes and sometimes lead to the app still technically being alive, but being completely unresponsive. The app would run much better with js debugging enabled because of chrome's better resources.
We did a big move with this library as well as many others. The heap seemed to be getting overwhelmed by graphics, so our prime suspects are our RN's Animated or this lib.
As a temporary fix we've just upped our heap size for android. We'll still be investigating and trying to make performance enhancements, but the app at least runs now.
Thank you for the quick fixes for clipRule!

We've figured out a bunch of things on our end for android and our world is no longer crumbling. We upgraded to your latest (9.4.0) in the process and clipPath is up and running again. Thank you for the quick fixes on this! I'm going to close :)

Ahh, actually it looks like it's again broken for android on 9.4.0. Same behavior as before, the circle isn't getting cut out. Works great on iOS though.

As you can see in the snack from the beginning of this thread (https://snack.expo.io/SywHux3uE), clipPath is working for android on v9.3.6 which is what expo uses, but it is broken for iOS on that version. The reverse is true for v9.4.0

Any ideas what might be going on?

At least it seems to work correctly in plain react-native with react-native-svg 9.4.0, are you sure you used the latest version / cleaned and rebuilt to native code and reset js cache?

ClipPath (with Rect) appears to be broken again, on iOS.

working fine on Android

"expo": "~41.0.1",
"react-native-svg": "12.1.0",
"react-native": "https://github.com/expo/react-native/archive/sdk-41.0.0.tar.gz",

ClipPath doesn't work on Android, but it works great on iOS.

Thanks @Loovery , your fix worked.

it is still broken but @Loovery fix still works!
version 15.2.0


New gruvbox-light theme

Description of change
I heard that flawz need some more themes #6. I tried something to implement a Vim Light Theme called gruvbox-light It's NOT EXACT SAME but it's looks like gruvbox-light.
How has this been tested?
It can only be tested with the eyes. Testing in daylight is recommended.
Color Palette of gruvbox-light

If we can agree on theme colors, I will add them too.

Codecov Report
Attention: Patch coverage is 0% with 27 lines in your changes missing coverage. Please review.

Project coverage is 7.84%. Comparing base (6698b7c) to head (4b9b394).

Files
Patch %
Lines

src/theme.rs
0.00%
27 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff            @@
##            main     #32      +/-   ##
========================================
- Coverage   8.14%   7.84%   -0.30%
========================================
  Files         13      13
  Lines        712     739      +27
========================================
  Hits          58      58
- Misses       654     681      +27

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

I changed the colors of the selected line so that it can be highlighted more easily.
Also updated README.md with theme preview. Other previews are 1000x600 but I couldn't take the screenshot at the same resolution.


asm.js

hi,
what do you think about compile some parts of squeakjs in asm.js. For example the canvas rendering code.
I don't konw if this ideas has been explored. What do you think about?

I thought about it but have not tried it yet. It would indeed be nice to use asm.js e.g. for working with bitmaps (BitBltPlugin). But SqueakJS is an object-oriented VM, meaning it represents Squeak objects with JavaScript objects. In asm.js you only get a single huge TypedArrary as your memory, and all functions have to operate on that chunk of memory (it basically models a C program's heap). We would somehow have to map between the real objects and that binary memory array, and I can't think of an efficient way to do it. But perhaps you have an idea for that?

I think only for function with heavy math that manipulate only number or typed array. And graphic canvas is much funcrion ceunch number.
----- Messaggio originale -----
Da: "Bert Freudenberg"<EMAIL_ADDRESS>Inviato: 24/06/2016 19:58
A: "bertfreudenberg/SqueakJS"<EMAIL_ADDRESS>Cc: "francesco agati"<EMAIL_ADDRESS>"Author"<EMAIL_ADDRESS>Oggetto: Re: [bertfreudenberg/SqueakJS] asm.js (#61)
I thought about it but have not tried it yet. It would indeed be nice to use asm.js e.g. for working with bitmaps (BitBltPlugin). But SqueakJS is an object-oriented VM, meaning it represents Squeak objects with JavaScript objects. In asm.js you only get a single huge TypedArrary as your memory, and all functions have to operate on that chunk of memory (it basically models a C program's heap). We would somehow have to map between the real objects and that binary memory array, and I can't think of an efficient way to do it. But perhaps you have an idea for that?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

You're very welcome to try :)

ok i try ;-)
2016-06-24 20:19 GMT+02:00 Bert Freudenberg<EMAIL_ADDRESS>
You're very welcome to try :)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bertfreudenberg/SqueakJS/issues/61#issuecomment-228421099,
or mute the thread
https://github.com/notifications/unsubscribe/AAKtpEx0oHwLRzguIrgxvdPRC-fVz3Qmks5qPB-xgaJpZM4I97WX
.

Closing for inactivity


Pipeline user_details not changing empty and protected user fields

If user entry have empty field such as email - getattr(user, name, None) give as u'' (tested on Django 1.7.8).
And expression current_value is None will always return False if user field is empty. So we never can change empty and protected user fields.

Fixed by #672


Remove "dataset" return_type option from kernel transformers

Closes #630.

Changes proposed in this pull request:

Remove "dataset" return_type option from kernel transformers.
I'm keeping KernelTransformer._infer_names(), just in case someone wants to generate image names and saves them in the Dataset.images dataframe for CorrelationDistributionDecoder, as shown in the test test_CorrelationDistributionDecoder_smoke().

It looks like python 3.6 is no longer available in ubuntu-latest.
@tsalo, @adelavega, @jdkent. Should we maintain supporting python 3.6?

I would have preferred to have a sunsetting timeline in place ahead of time, with deprecation warnings to users and the like for a few releases, but if we can't test on 3.6 then I think we should drop it. Probably worth jumping to 0.1.0 in that case though.

I think we can test 3.6 with ubuntu-20.04. What about adding the deprecation warnings for 0.0.13, and then dropping 3.6 for 0.1.0

That would be nice.

Python 3.6 is end-of-life already and 3.7 will be very soon (so I would add that to the deprecation cycle).
This is true for many tools also, so I think users on 3.6 will have to upgrade to get the latest versions of most of the related scientific software regardless.
But I'm not opposed to your plan if you want to go ahead with it!


Don't update the cut if it is worse than before

When using the initial_cut parameter (eg when reusing a cut found from
a previous search), we were updating the cut after a first valid
implementation is found.  Such an implementation would have a bound that
is less than the initial cut, but not necessarily (in fact, almost
never) an execution time lower than the initial cut -- thus we would in
fact make the cut worse by performing this update.
This patch instead changes it so that we only update the cut if it
improves it.
NB: An alternative fix for this issue would be to take the initial cut
into account in the monitor, but this means we would ignore
implementations that are not faster than the initial cut.  This would
limit the usefulness of the initial_cut parameter -- in particular, it
wouldn't be possible to use it to optimisticaly cut branches with an
aggressive cut for which we don't have an implementation.

bors r=andidr

bors retry

bors retry


OSU tests fail on IMPI due to warning msg

All OSU test  fails for alaska:ib-gcc9-impi-verbs and alaska:roce-gcc9-impi-verbs partitions.
The Intel MPI library emits the following to stdout, which is not handled by OMB output parser modules/omb.py:read_omb_out()

WARNING: release_mt library was used but no multi-ep feature was enabled. Please use release library instead.

Hacky workaround by rewriting the output files to delete this warning added in https://github.com/stackhpc/hpc-tests/commit/0fcbd4ed3d54d9ee4ef7499567de85ab2dd20da1


cp1252 encoding not detected in this case

VSCode Version: 1.11.0
OS Version: Windows 10 1607

Steps to Reproduce:
set "files.autoGuessEncoding": true in settings

Open file saved with encoding ANSI (1252)
VS Code show encoding as UTF8
Reopen with Encoding -> there is no hint which encoding was guessed or if it was tried to guess

@skest3qc can you attach the file here? If the file does not contain sufficient characters that lead to cp1252, it will not report any encoding and fallback to UTF-8.

test.txt

Create a utf8.txt with content "謋 鰊", then save with encoding GB18030, then reopen with encoding windows 1252....
the hex codes can be interpreted by more than one encoding...

I can reproduce. We are using https://github.com/aadsm/jschardet and I will create bug reports in their repository once we have collected some more data.

Actually the issue with https://github.com/Microsoft/vscode/issues/23997#issuecomment-292092984 is that we only use the first 512 bytes to detect the encoding from the file. Maybe we should increase this limit when files.autoGuessEncoding is enabled and specifically when using the encoding selector.

With this fix I am increasing the number of bytes that we send to jschardet for detection and it seems to fix the issue repoted.

I am not much agreeing with the fix status here. Their should not be any such limit. Other tools actually supporting lack of BOM does not seem to have it. That still cause file corruption from time to time with VsCode, meaning that indeed, we should not consider VsCode as a tool able to cope with files not having a BOM, banning editing of ASCII files with VsCode.
We have experienced corruption on this file. Just a release notes file but still, this cause VsCode to be unreliable for editing files without a BOM.
This release notes file is windows-1252 encoded with some characters specific to this encoding toward its end (#L3065).


API for randomized tests

I'd love to have a nice way to run tests that require randomization. A good use case would be to test a collection data type such as a hash set, where you want to compare algorithms.  Since handling collisions (and probability of collisions) is essential, it won't do to always use the same set of data and the same operation (e.g. insert the same value).
I think one good API would be like https://docs.rs/criterion/0.3.0/criterion/struct.Bencher.html#method.iter_batched but with a simpler API matching the other easybench functions.

Yes, I think this makes sense.  I'd take a PR which generalizes bench_env to something like
fn bench_gen_env<G, F, I, O>(gen_env: G, f: F) -> Stats where
    G: FnMut() -> I,
    F: Fn(&mut I) -> O,


SetMessageReaction not working

Hello, I'm testing your library, great work.
One thing that I'm having trouble with is SetMessageReaction, I get errors when using it.
I'm able to make it work by defining a custom MarshalJSON like so:
func (rt *ReactionType) MarshalJSON() ([]byte, error) {
	if rt.Type == ReactionTypeTypeEmoji {
		return json.Marshal(rt.ReactionTypeEmoji)
	}
	if rt.Type == ReactionTypeTypeCustomEmoji {
		return json.Marshal(rt.ReactionTypeCustomEmoji)
	}
	return nil, fmt.Errorf("unsupported ReactionType type")
}

This creates the reaction but returns one error:
error decode response result for method setMessageReaction, json: Unmarshal(non-pointer bool)

I'm not sure why.

Fixed in v1.1.2


Make external-types.md compile with gleam 0.3

I looked at the order of push and noticed it was wrong. Then, I wanted to play with the example and it didn't compile. This should compile and work now. Unsure if any other changes need to be made.
chiroptical@Barrys-MacBook-Air ~/p/g/test (main)> cat src/test.gleam
import gleam/io

pub type Queue(a)

@external(erlang, "queue", "new")
pub fn new() -> Queue(a)

@external(erlang, "queue", "len")
pub fn length(queue: Queue(a)) -> Int

@external(erlang, "queue", "in")
pub fn push(elem: a, queue: Queue(a)) -> Queue(a)

pub fn main() {
  let queue = new()
  io.debug(length(queue))
  let new_queue = push(0, queue)
  io.debug(length(new_queue))
}
chiroptical@Barrys-MacBook-Air ~/p/g/test (main)> gleam --version
gleam 0.30.0
chiroptical@Barrys-MacBook-Air ~/p/g/test (main)> gleam run
  Compiling gleam_stdlib
  Compiling gleeunit
  Compiling test
   Compiled in 0.01s
    Running test.main
0
1

Closes #256 (I think)


Blazor onpointerdown event gives error

Describe the bug
When onpointerdown event fires I get error.
To Reproduce
Steps to reproduce the behavior:

In Blazor 0.8.0 standalone app I dynamically create element, register pointer event;
builder.AddAttribute(k++, "onpointerdown", OnPointerDown);
public void OnPointerDown(UIPointerEventArgs e) {};
When I click on element I get this error:
System.ArgumentException: Object of type 'System.Int64' cannot be converted to type 'System.String'.

Expected behavior
It should invoke OnPointerDown method with proper UIPointerEventArgs.
Screenshots

Additional context
I guess it happens with all pointer events.

EventHandlers.cs is showing:
[EventHandler("pointerdown", typeof(UIPointerEventArgs))]
not onpointerdown
but if I do builder.AddAttribute(k++, "pointerdown", OnPointerDown); and click element nothing happens.
So another question - which is correct pointerdown or onpointerdown?

I found where is problem.
According to this PointerID is number.
"pointerEvent.pointerId - The pointer event's unique identifier number."
Here in EventForDotNet.ts we have also number.
interface UIPointerEventArgs extends UIMouseEventArgs {
  pointerId: number;
  width: number;
  height: number;
  pressure: number;
  tiltX: number;
  tiltY: number;
  pointerType: string;
  isPrimary: boolean;
}

But here we have string.
public class UIPointerEventArgs : UIMouseEventArgs
    {
        /// <summary>
        /// A unique identifier for the pointer causing the event.
        /// </summary>
        public string PointerId { get; set; }

So this is giving cast error - Object of type 'System.Int64' cannot be converted to type 'System.String'
If we change PointerID type to long issue will be addressed.
I will try now to make PR.

Thanks for finding and submitting a PR, @Lupusa87.
@javiercn, can you please review the referenced PR? Thanks!


Command to show services with updates available

On Docker 1.12 running navy updates actually downloads all of the images in the background.


App Crashing when volume change happens too quick

When you change native android volume too quickly, the one that's available when you slide the screen to adjust volume when playing media in vlc, mxplayer, etc this error would happen.
Error log
java.lang.RuntimeException: Error receiving broadcast Intent { act=android.media.VOLUME_CHANGED_ACTION flg=0x14000010 (has extras) } in io.alcatraz.audiohq.services.VolumeChangeObserver$VolumeReceiver@7e24ad7 	at android.app.LoadedApk$ReceiverDispatcher$Args.lambda$getRunnable$0$LoadedApk$ReceiverDispatcher$Args(LoadedApk.java:1590) 	at android.app.-$$Lambda$LoadedApk$ReceiverDispatcher$Args$_BumDX2UKsnxLVrE6UJsJZkotuA.run(Unknown Source:2) 	at android.os.Handler.handleCallback(Handler.java:938) 	at android.os.Handler.dispatchMessage(Handler.java:99) 	at android.os.Looper.loop(Looper.java:223) 	at android.app.ActivityThread.main(ActivityThread.java:7664) 	at java.lang.reflect.Method.invoke(Native Method) 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592) 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947) Caused by: java.lang.IllegalStateException: View android.widget.LinearLayout{1e1dede V.E...... ......ID 0,0-2160,149 #7f09005d app:id/audiohq_float_root} has already been added to the window manager. 	at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:381) 	at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:109) 	at io.alcatraz.audiohq.services.FloatPanelService.showFloatWindow_Impl(FloatPanelService.java:418) 	at io.alcatraz.audiohq.services.FloatPanelService.showFloatingWindow(FloatPanelService.java:409) 	at io.alcatraz.audiohq.services.FloatPanelService.showPanel(FloatPanelService.java:173) 	at io.alcatraz.audiohq.services.FloatPanelService$2.onVolumeChange(FloatPanelService.java:151) 	at io.alcatraz.audiohq.services.VolumeChangeObserver$VolumeReceiver.onReceive(FloatPanelService.java:656) 	at android.app.LoadedApk$ReceiverDispatcher$Args.lambda$getRunnable$0$LoadedApk$ReceiverDispatcher$Args(LoadedApk.java:1580) 	... 8 more
Step to reproduce.

Open app, confirm that it's running by changing current media volume.
Open vlc, plays any media, slide up and down on the right side of the screen to change volume.
App would crash and the audiohq overlay would dissapear too unless you manually reopen the app.

Pardon the rapid editing btw, idk which issue template to follow.

Seem's like there's a change it latest commit tree that resolved this issue, closing.


Updated ui for join/create room page

Updated ui for join/create room page: #8

Title : Updated ui for join/create room page
Issue No. : 8
Code Stack : .jsx
Close #8

Video/Screenshots (mandatory)

Ui screenshots after  the update

Mobile View

Tablet View

Desktop View

Checklist:

[X] I have mentioned the issue number in my Pull Request.
[X] I have commented my code, particularly in hard-to-understand areas
[x] I have gone through the  contributing.md file before contributing

Additional context (Mandatory )
I have updated the UI for join/create room page using tailwind css for styling. Now the forms render dynamically instead of appearing alongside as it was before.
Are you contributing under any Open-source programme?
Contributing under JWOC 2024

@mishra811  great job . But there are some issues in the landing page and in the room page.
Landing page: The start whiteboarding button and the github button in the top right is deformed.

Room page : The canvas outline was not visible.

I think it is due to any kind of conflict regarding classes in bootstrap and tailwind css. I saw u are using postcss which is great but do figure out the reason of the  issues pointed out and let me know.
You can refer to the doc  to avoid conflicts between classes  - https://stackoverflow.com/questions/62688037/can-use-both-tailwind-css-and-bootstrap-4-at-the-same-time

It will be great if the Color scheme of the Join room page matches with the Slateai logo. (red and blue)

Let me know if you are interested in issue#1 as the previous contributor on that issue has left it. As you are working with UI stuff it will be good if you can migrate the entire UI from bootstrap to tailwind. It was under hard category  so you will get more point for that issue.

Ok I will update the colors to match the logo and fix the other UI issues that you mentioned. I think migrating the whole UI to Tailwind css at once would be better rather than one page at a time. Sure you can assign me issue#1. But It will take some time as building UI is often time-consuming.

Ok I will update the colors to match the logo and fix the other UI issues that you mentioned. I think migrating the whole UI to Tailwind css at once would be better rather than one page at a time. Sure you can assign me issue#1. But It will take some time as building UI is often time-consuming.

Not an issue take your time. you just comment on the issue#1 I will assign you.

I have updated the UI for the create/join form page and fixed some UI issues that you mentioned above. Using tailwind has caused some new UI breakdowns throughout the app. I am thinking let's merge this issue for the join/create page if you like the new join/create page UI and I will fix the rest of the UI breakdowns under issue#1. Let me know what you think. Here are some of the screenshots of the new UI

HI, finally I have made all the changes in UI required and have migrated the client app from Bootstrap to Tailwind CSS. Please verify it and let me know if there's an issue.

So should I raise an issue to enhance the UI for the landing page ?

Apologies for the inconveniences caused.I was actually trying some UI changes in my local repo but I accidentally committed it and pushed it as well.
I will revert back the changes and fix everything but I was thinking should I raise an issue to enhance the UI for the landing page ? Since I have already made changes to landing page UI I can raise an instant PR for that as well.Let me know I don't have a problem in reverting the UI either. I am fine with both

Apologies for the inconveniences caused.I was actually trying some UI changes in my local repo but I accidentally committed it and pushed it as well. I will revert back the changes and fix everything but I was thinking should I raise an issue to enhance the UI for the landing page ? Since I have already made changes to landing page UI I can raise an instant PR for that as well.Let me know I don't have a problem in reverting the UI either. I am fine with both.

sure you can create an issue. but first try to resolve the issue#1 and then made one small changes to rest of the issues nd made a fresh pr to rest of the issues.

In the mobile view keep the leave room button at the top of its parent div and make it aquire the entire div-width space. and place the undo and redo buttons just after the color where the leave button was previously @mishra811

hello, I have reverted all the UI changes in the landing page and fixed the layout on the room page. Everything should be fixed now. Please verify it and let me know if there's something to change.

hello, I have reverted all the UI changes in the landing page and fixed the layout on the room page. Everything should be fixed now. Please verify it and let me know if there's something to change.

hey are you available for a google meet? I need to discuss something before merging.

sure let me know when you are available

Sure let's do it

Sure let's do it

https://meet.google.com/raz-osvs-qfa

@mishra811 bro this pr has too much conflicts. It can't be merged.

I have merged issue#1 on dev branch you pull the dev branch("git pull origin dev") and merge with your existing changes of join/create room page and make a fresh pr after resolving conflicts.

Sure I will do that

This PR has too much conflict and it's very confusing to solve this. I am thinking of jus creating a new PR and close this one to save some time. Let me know what you think

Should fix merge conflicts now

issue#8 has been sucessfully merged into dev.


add deprecation notice to README

Codecov Report

Merging #23 (a94fba8) into master (d092d81) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #23   +/-   ##
=======================================
  Coverage   89.69%   89.69%
=======================================
  Files           4        4
  Lines          97       97
  Branches       15       15
=======================================
  Hits           87       87
  Misses         10       10

Continue to review full report at Codecov.

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

Codecov Report

Merging #23 (a94fba8) into master (d092d81) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #23   +/-   ##
=======================================
  Coverage   89.69%   89.69%
=======================================
  Files           4        4
  Lines          97       97
  Branches       15       15
=======================================
  Hits           87       87
  Misses         10       10

Continue to review full report at Codecov.

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


E1\F1\F3 meeting participant limit ?

The article does not call out details about all the sku's e.g E1, F1, F3 etc. What is the meeting limit for these sku's 300 or 1000 ?

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

ID: 905e2c09-ef3e-07cc-0809-6ff171157c47
Version Independent ID: c0d33162-183d-fff8-32e9-a999f391ea51
Content: Limits and specifications for Microsoft Teams - Microsoft Teams
Content Source: Teams/limits-specifications-teams.md
Service: msteams
GitHub Login: @MicrosoftHeidi
Microsoft Alias: heidip

Hello @dipinn26592
All enterprise plans allow for up to 1,000 people and Office 365 E1, F1/F3 are enterprise plans
https://learn.microsoft.com/en-us/microsoftteams/overview-meetings-webinars-town-halls

Hi @get-itips , Can we please have this called out in the above article as well, thanks.


Improve code quality

Fix the warnings in codebeat.
https://codebeat.co/projects/github-com-yahoojapan-garm-master

plugin data out-of-date, won't fix


Separate element definition and parsing: Quote

Rename QuoteElement to QuoteParser
Extract general stuff into element class that is supposed to be re-used by other import / export modules.

+1

+1


window_hooks_integration_test.dart shouldn't fake being part of dart:ui

We do this currently so we can test internal implementations.  However, this is really brittle - it breaks when someone adds a new import aliased a certain way.  We also recently had a case where a unit test was added modeled after this one incorrectly, which ended up hiding the fact that its implementation wasn't quite working right.
We should figure out a way to either expose the relevant bits that are internal or make sure we can test the relevant bits through the public API.

This is making it more difficult to migrate the other tests to NNBD/remove annotations from dart:ui that shoul dno longer be necessary. I'm doing this.


💥 [DevOps] Authentik: Email confirmation link registeres in Authentik App

💥 DevOps

After clicking on confirmation link in the EMail of Authentik the user is asked to enter his credentials and is send to the Authentik App.
🤖 ToDo

[x] Change process so that the user is not loged in the Authentik App but in the frontend

@ulfgebhardt Added a policy so that the user is redirected to frontend


Remove email based login functionality

@aydjay @thailyn

I'm hesitant to simply gut all the non-sessionID functionality, since I think it can be repaired, given some more effort.  However, we can always look at the revision history and find the old code.
If you do keep it as-is, perhaps add a TODO to either fix username/password login or determine it is indeed impossible, and reference this PR?

Honestly I'm tempted to just remove it completely, since I think sessionid is the most widely used as the majority of 3rd party tools tend to use SessionID these days.
Alternatively if you'd like to take a stab at repairing the email functionality, I could reduce the changes in this PR to simply have the xaml changes as it's confusing to users having the email/password login when it doesn't work. That way the UI at least represents that you can only currently login with sessionID but it would be a small change to revert if email is working again.

I am interested in trying to try to repair it -- as that is how I logged in previously -- but it isn't that high a priority since SessionID does work.  But, yes, we are definitely overdue in updating the UI so users know only SessionID works right now.  Either way you want to make the change is fine to me, since we do have the revision history.

Alright, in that case I'm going to merge as is. I'll happily merged the functionality back in when you do take a stab at getting email to work again.


[BUG] antivirus blocking request on the localhost

Describe the bug
When attempting to run the project locally, I encounter the following error in the console log:
ShellGenerator.jsx:21
GET http://localhost:3000/src/components/Tools/ReverseShell/shellData.jsx net::ERR_ABORTED 499 (Request has been forbidden by antivirus)
To Reproduce
1 confirm that antivirus software is running
2 clone the project repository
3 run the project locally using "npm run dev "
4 open the browser and observe the error
Expected Behavior
I expect the project to run without errors.
Screenshot/ Video

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@kabir0x23 I also has the same problem,  is there a way to solve it? (besides turning off the anti-virus functionality)

i will look into it

i will look into it

here in that path/file, it contains malicious data templates, it's only templates not real malicious data, it's like dummy data,
that's why antivirus is alerting it.

Yes, but what are theese templates ? I know that kaspersky blocks request  from tags named as bank .

i have reproduced this bug i got the same error

does this have to do with some code needed for development ? if so i think this issue should not be considered as a bug .

@firassssss Yes, It is not a bug but it is something that we should handle in some way. It can scare other developers from contribute to our project.


Add Biostrings

This is a dependency for phangorn that's on Bioconductor. Without it, the build fails.

I did notice that the build fails with this error, and was going to send a query to r-sig-genetics. Is this coming from pegas? I couldn't see which is the package that has a dependency declaration for Biostrings.

I couldn't see which is the package that has a dependency declaration for Biostrings.

Never mind, just noticed in your commit message that it's phangorn. I guess Biostrings can't be resolved through CRAN, which is why this fails the build?

Never mind, just noticed in your commit message that it's phangorn. I guess Biostrings can't be resolved through CRAN, which is why this fails the build?

Bingo. It's a bit frustrating, but there appear to be two ways around it:

biocLite
http://stackoverflow.com/questions/14343817/cran-package-depends-on-bioconductor-package-installing-error/20479243#20479243


"Knock Out" will pickpocket bandits if player is stunned.

Type
Incorrect behavior
Operating System
None
OS Version
No response
Bug description
To reproduce:

Go to Pollnivneach and lure a bandit
Swap your left click to be pickpocket
Pickpocket until you get stunned
Attempt to knock out the bandit while stunned
You'll see in the chatbox that it attempts to pickpocket every tick (and print "You're stunned!" to chat) and then pickpocket when you're no longer stunned.

Screenshots or videos
https://github.com/runelite/runelite/assets/150997473/a4555048-a5bf-492a-84ae-7096f0471fdf
RuneLite version
Runelite version: <IP_ADDRESS>
Oldschool revision: Rev 220
Launcher version: 2.6.9
Logs
No response

Don't know why it didn't happen when I tried to reproduce with the official client but this is an OSRS bug, nevermind.


KiCad: enable caching 3D models on hydra; assorted cleanup

Description of changes
a whole bunch of tightly related changes:
· add a repack option to fetchZip (see #255657 for details on that) (not a separate PR as this is only used here)
· use that repack to compress the kicad.libraries.packages3d.src so it fits within hydra's output limit
· switch update.sh to use the fetchZip with repack in nixpkgs
· switch to using hash instead of sha256 and regenerate versions.nix with latest everything
· add some newer dependencies to kicad-unstable (fixes build for newer revs)
· disable qa_spice test on kicad-unstable as it's failing here (from an IRL interaction i think upstream is aware)
· add an exception to compressing the .step files for the 1 used directly by the footprints
· switch to using ninja, i think this took a few minutes off of my build time (recommended by upstream, also tried the mold linker, but didn't notice a difference, and it seems a fickle thing for cross-platform stuff)
· update substituteInPlace to use --replace-warn to get rid of its deprecation warning
· use doCheck, doInstallCheck was originally required to get the package's tests run in the right context, apparently no longer
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)

kicad-unstable may not acquire a good wayland area and have some sub-windows crash on startup, but once everything's started it seems good enough (vs being 4 months out of date)

24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

hmm, the zip compression used for packages3d is not reproducible (it fails nix-build --check)
switching to gzip seems ok and seems to be endorsed by the recommended practice around stpZ
unfortunately, this packages rc3 as kicad-unstable, which has already switched to the KICAD8 env vars, so a clean run (which has no previously cached library paths in ~/.config/kicad, ~/.local/share/kicad, or ~/.cache/kicad) won't be able to discover the libraries

i've split some of this up into separate branches
i think the priority atm is getting the updates in
the fetchZip change is fairly easily to use after all the other things here
the nix-prefetch change turns out to interfere with bootstrapping the versions.nix, but it doesn't really need to be bootstrapped
(i've got one with hash locally, don't recall how i actually managed to generate that, but it can be manually written if needed)
(issue there is that nix-prefetch invokes kicad.base.src which tries to load its hash from versions.nix which doesn't exist, shouldn't be necessary as nix-prefetch blanks hash in its usage anyway...)


Rename Past Warning to warning.

This includes changes to the
viewplayer area and to the search bar.
I included a gitignore line with nbproject (netbeans project folder)
(I dont have grunt setup on this computer, (was a search/replace instead, the delete still works ;))

This is what is suggested in #119

Thanks!

You are welcome :).
I am trying to help out where i can :)


Vars directory not included when linting a role

Issue Type

Feature request

Ansible and Ansible Lint details
ansible --version
  ansible <IP_ADDRESS>
ansible-lint --version
  ansible-lint 3.4.16

ansible installation method: OS package
ansible-lint installation method: pip

Desired Behaviour
When running ansible-lint on a particular role, I would expect it to also check the vars (and possibly defaults) directory for rule violations. At the moment this is not the case as the directories that are checked are set to tasks, handlers and meta.
Is there any specific reason why these directories are excluded?
The main reason I would like this feature is because we do certain lookups in variables, and these can not be checked at this time.

In case this is a desired feature, I have already created a pull request with the change: https://github.com/willthames/ansible-lint/pull/294

As mentioned in #294, please use ansible-review for this task


[jvm-packages] Fix early stopping bug

Addresses https://github.com/dmlc/xgboost/issues/6657

Codecov Report

Merging #6708 (ebc4290) into master (dc97b5f) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #6708   +/-   ##
=======================================
  Coverage   81.56%   81.56%
=======================================
  Files          13       13
  Lines        3760     3760
=======================================
  Hits         3067     3067
  Misses        693      693

Continue to review full report at Codecov.

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

so the only failing check is a Python/C++ code linter...which shouldn't be applicable here, yes? Is there any additional action that needs to be taken?

The linter can be ignored  I will fix it.
@CodingCat Please help to review the PR.

@wbo4958 Could you please help taking a look?

LGTM

could we change the checking instead? setting default would make it consistent with other params

@sammynammari , I didn't see your response, so I made another PR for this issue https://github.com/dmlc/xgboost/pull/6738.

closing this in favor of #6738.


Supporting schemas for Action request bodies

See some discussion on #65.
Hi, folks.  I know a solution to this topic is long-awaited.
Copying an example from the above thread (specifically, @xogeny's), here's a proposal for actions that have a request body with a typed schema of some sort.
I think I'd like to see Siren be explicit about whether the schema is inline or external.
Inline:
"actions": [
  {
    "name": "addNewProduct",
    "title": "Add a new product (lots of structured data required)",
    "method": "POST",
    "href": "http://api.x.io/products",
    "type": "application/json",
    "schema": {
       "value": {
         "$schema": "http://json-schema.org/draft-04/schema#",
         "title": "Product",
         "description": "A product from Acme's catalog",
         "type": "object"
        }
      }
    }
  ]

External:
"actions": [
  {
    "name": "addNewProduct",
    "title": "Add a new product (lots of structured data required)",
    "method": "POST",
    "href": "http://api.x.io/products",
    "type": "application/xml",
    "schema": {
       "src": "http://api.x.io/schemas/productSchema.xsd"
      }
    }
  ]

Of course, we need language stating that if a schema exists, fields should not be present.  And probably more, but we can work that out.  Happy to listen to any feedback.

Of course, I'm all for it.  But I'm confused on one point.  You talk about "inline" vs. "external".  But what isn't clear to me is whether you are talking about "Inline JSON Schema" vs. "External JSON Schema" or whether you are talking about "Inline JSON Schema" vs. "External non-JSON Schema".  At first, I thought it was the former (and I had actually prepared a response on that point), but in looking at your example now I suspect you actually meant the latter.  Could you clarify?

@xogeny
Sure.
Inline means the schema is in the message.  This could be an XSD as a string, but above, it's a JSON Schema object.
External means the schema lives at a different location specified by a URL.  This could be a link to a JSON Schema document, but above, it's a URL to an XML Schema Definition.
Frankly, I just didn't want to hand-type an XSD.  :)
You can think of it like an HTML <script> tag, which has similar flexibility.  I'd be open to changing src to href to match the rest of Siren.

OK, so you want to support any arbitrary schema.  So you expect the client to determine the format based on actually accessing the schema (i.e., looking at the supplied value)?  I ask because you didn't include a field to represent the specific content type associated with the schema, e.g., application/schema+json.

@xogeny Ah, yes.  I intended to include that, but it was a 3AM kinda thing, so it slipped by.  :)
A few changes below.  I changed src to href.  I added type.  I think the rules should state schema MUST contain either href or value (mutually exclusive), and type SHOULD be included.
Inline:
"actions": [
  {
    "name": "addNewProduct",
    "title": "Add a new product (lots of structured data required)",
    "method": "POST",
    "href": "http://api.x.io/products",
    "type": "application/json",
    "schema": {
       "type": "application/schema+json",
       "value": {
         "$schema": "http://json-schema.org/draft-04/schema#",
         "title": "Product",
         "description": "A product from Acme's catalog",
         "type": "object"
        }
      }
    }
  ]

External:
"actions": [
  {
    "name": "addNewProduct",
    "title": "Add a new product (lots of structured data required)",
    "method": "POST",
    "href": "http://api.x.io/products",
    "type": "application/xml",
    "schema": {
       "href": "http://api.x.io/schemas/productSchema.xsd",
       "type": "application/xml"
      }
    }
  ]

OK, several questions.
Are fields and schema mutually exclusive?  Or would you want the option to provide both in parallel? (giving the client the option?).
If you really want to allow both fields and schema, then that naturally begs the question, what if I want to provide multiple schemas (e.g., both XSD and JSON schema)?
I see at least two philosophical approaches here.  One could say "sure, let's make schema an array instead" and allow as many as the client wants.  I'm guessing that most people will feel like this would make handling of actions way too complicated.  I, for one, don't really need this complexity.
But if we only allow one schema per action and just tell the client "this is the schema I've got, sorry if you don't like it" then I still think we still have an issue.  Specifically, this issue of fields vs schema.  So in that case I'm wondering...can we actually combine them?
One thing that makes me a bit nervous in this who schema discussion is what is the meaning of type in the action.  It seems to me that we are overloading it.  As I saw it, what it used to mean was "this is the media type that my payload should have" (e.g., JSON, XML, URL encoded).  This is not the same thing as saying how you want to define the structure of your payload.  I could have a schema that is in JSON Schema but the action requires that I submit it as URL encoded.  So perhaps we want to actually have to fields, type (for what format the submitted payload should be in) and schemaType to let the client know how to parse our schema definition?
So assuming we resolve that issue, it seems to me that fields is overlapping with schema in so much as the fields still just represents a specific schemaType.  In other words, one could (I'm not necessarily proposing this), actually deprecate fields in favor of:
   "schemaType": "text/html",
   "schema": {
      "fields": [
        { "name": "orderNumber", "type": "hidden", "value": "42" },
        { "name": "productCode", "type": "text" },
        { "name": "quantity", "type": "number" }
      ]
    }

The reason for doing this is that otherwise, you end up (potentially) in a situation where you say "for simplicity's sake, you can only tell the client about one schema format...uh...unless you want to specify both fields and schema".  But making fields just another schema type could be seen as a unification of fields and schema so the semantics were more consistent.
Those are some thoughts.  I'm not trying to be difficult, I just want to point out some potential inconsistencies with the hope that we can resolve them in such a way that the resulting specification is cleaner.

The type keyword is already overloaded.  It's the equivalent of an HTML enctype in actions.  For links, it's a hint on the media type that will be returned when following the href.  I think, in context, it's not too difficult to figure out.  I opt for shorter names, and that comes at some expense.
Yes, I have been thinking of fields and schema as being mutually exclusive.  Fields are less strict and have richer semantics than any schema definition I've seen, though arguably, JSON Schema Validation gets close on the semantic aspect.
I'm hesitant to make schema an array and wonder if it would make sense to have a media type that lists schema options instead.  A Siren action could point to the multi-select schema media type, and the client could choose from there.  It's worth noting that currently, Siren actions only allow one type per action.
As always, I appreciate and welcome competing points of view.  I never dismiss it as "being difficult."  The subject, itself, is difficult, which is why analyzing various points of view is necessary.
Unifying fields and schema might have a certain tidiness, but as a breaking change, it comes at quite a high cost.  I'd be fine leaving them mutually exclusive.

Do you need to specify the media type of the schema? Could the client not
use content negotiation against the schema URL to request the schema in a
format the client understands?
On 30 May 2017 01:06, "Kevin Swiber"<EMAIL_ADDRESS>wrote:

The type keyword is already overloaded. It's the equivalent of an HTML
enctype in actions. For links, it's a hint on the media type that will be
returned when following the href. I think, in context, it's not too
difficult to figure out. I opt for shorter names, and that comes at some
expense.
Yes, I have been thinking of fields and schema as being mutually
exclusive. Fields are less strict and have richer semantics than any schema
definition I've seen, though arguably, JSON Schema Validation gets close on
the semantic aspect.
I'm hesitant to make schema an array and wonder if it would make sense to
have a media type that lists schema options instead. A Siren action could
point to the multi-select schema media type, and the client could choose
from there. It's worth noting that currently, Siren actions only allow one
type per action.
As always, I appreciate and welcome competing points of view. I never
dismiss it as "being difficult." The subject, itself, is difficult, which
is why analyzing various points of view is necessary.
Unifying fields and schema might have a certain tidiness, but as a
breaking change, it comes at quite a high cost. I'd be fine leaving them
mutually exclusive.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kevinswiber/siren/issues/84#issuecomment-304746228,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQ0-sWQOh_Jt7rx2Hzn1QdHD_CW4t8Rks5r-111gaJpZM4NonB9
.

@mcintyre321 Good point on content negotiation.  XML Schema Definitions don't have a specific media type (they use application/xml or text/xml), which is problematic but not a huge deal.  I mean, how many schema types do we really use for APIs anyway?  I think conneg is a good solution.
The schema type would be optional, for sure.

As far as breaking changes w.r.t. fields, another option could be to actually use fields to hold the schema.  If it is an array, treat it as an existing fields definition.  If it is a string, treat it as a link to the schema definition (using content negotiation as a guide).  If it is an object, treat it as an inline definition.  Backward compatible and covers all the variations discussed so far (except inline XSD...but honestly...that would be pretty revolting and this would encourage people to do The Right Thing and simply link to it).

@xogeny Can you type out an example?
I thought about this, but I'm not sure how to make it un-confusing.  Would it look something like this?
"fields": [
  { "type": "schema", "schemaType": "application/xml", "href": "https://..." }
]

Or:
"fields": [
  {
    "type": "schema",
    "value": {
       "$schema": "http://json-schema.org/draft-04/schema#",
       "title": "Product",
       "description": "A product from Acme's catalog",
       "type": "object"
      }
  }
]

Feels a little inside-out, IMHO.

Sure.
Current (HTML fields)
"actions": [
  {
    "name": "addNewProduct",
    "title": "Add a new product (lots of structured data required)",
    "method": "POST",
    "href": "http://api.x.io/products",
    "type": "application/xml",
    "fields": [
        { "name": "orderNumber", "type": "hidden", "value": "42" },
        { "name": "productCode", "type": "text" },
        { "name": "quantity", "type": "number" }
      ]
}

Inline
"actions": [
  {
    "name": "addNewProduct",
    "title": "Add a new product (lots of structured data required)",
    "method": "POST",
    "href": "http://api.x.io/products",
    "type": "application/xml",
    "fields": {
       "$schema": "http://json-schema.org/draft-04/schema#",
       "title": "Product",
       "description": "A product from Acme's catalog",
       "type": "object"
      }
}

External
"actions": [
  {
    "name": "addNewProduct",
    "title": "Add a new product (lots of structured data required)",
    "method": "POST",
    "href": "http://api.x.io/products",
    "type": "application/xml",
    "fields": "http://api.x.io/schemas/productSchema.xsd"
}

I ditched the type specifier for a couple of reasons.  First, I'm a bit uncomfortable about the subtle overloading of type (between payload content type and schema format).  But second, I'm not sure it is even necessary because if it is an array, you know the type.  If it is a string, you get the type by content negotiation.  If it is an object it could, in theory, be any kind of schema.  But the thing is, if it is inline it would have to be JSON.  If it is JSON, chances are almost certain it is JSON Schema.  You could have other types of inline formats besides JSON schema.  But in any case, one would hope that the shape of that schema is such that the client could infer exactly what it was.  Most clients wouldn't even go that far.  Instead, they would just check to see if it was a format they understood or not (no need to infer formats you don't even understand).  Honestly, your use of $schema pretty much does the job of that type anyway.
That is what I had in mind at least.  Backward compatible, compact and covers all cases discussed so far except inline XSD.  Again, just a thought.

Just to add some thoughts: Concerning external schemas I would in my current projects most likely go with using techniques that the schema format already provide i.e. the $ref key for JSON schema:
"actions": [
  {
    "name": "addNewProduct",
...
    "fields": {
       "$schema": "http://json-schema.org/draft-04/schema#",
       "$ref": "http://schemas.host.com/product.schema.json"
      }
}

I do not know it there are similar ways for other schema formats, which is why I think you still need other means of linking to external schemas in the Siren spec directly.

I would love to use an official solution to provide JsonSchemas via Siren.
Are there some further thougths on this topic? Great discussion so far.
I kind of like the schema  property a bit more. The name and meaning does not collide with fields and it is pretty explicit. About backward compatibility i'm not so sure.

I would love to resurrect this topic 🙂
We have requirements that are a bit more simple than @xogeny's and would love to get them into the standard. Namely, we only need to support application/json (and derivations) in conjunction with JSON Schemas.
After all those years, I believe that those requirements are best fulfilled by using a separate schema key on the action object, as @MathiasReichardt suggested.
My suggestion is as follows:

fields are left unchanged
add new key schema, that has to be a valid JSON schema object
fields and schema can be present at the same time. The implementer has to make sure that they are equivalent, if that's what he needs.
For me schema implies a type that is compatible to application/json (e.g. application/vnd.siren+json 😉 ), but that's probably best left to the implementer.

Examples:
{
  "actions": [
    {
      "name": "htmlStyleAction",
      "fields": [
        { "name": "field1", "type": "text" },
        {
          "name": "field2",
          "type": "checkbox",
          "value": [{ "name": "value1" }, { "name": "value2" }]
        }
      ]
    },
    {
      "name": "inlineSchemaAction",
      "schema": {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "$id": "https://schema-host/my.schema.json",
        "type": "object",
        "properties": { "field1": { "type": "string" } }
      }
    },
    {
      "name": "referencedSchemaAction",
      "schema": {
        "$schema": "http://json-schema.org/draft-04/schema#",
        "$ref": "https://github.com/kevinswiber/siren/blob/master/siren.schema.json"
      }
    },
    {
      "name": "mixedSchemaAction",
      "schema": {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "$id": "https://schema-host/my.schema.json",
        "type": "object",
        "properties": { "field1": { "type": "string" } }
      },
      "fields": [{ "name": "field1", "type": "text" }]
    }
  ]
}

@kevinswiber Are you interested in a PR for this?
In case you want to see real-world behavior first, I would love to hear your opinion first, since it will be some effort to get this implemented in my current project. It would be much easier to convince people of the implementation if you give your blessing ;)

@Kampfgnom Looks very nice to me.  The fact that you use a previously unused keyword everywhere and didn't change any existing ones means, if I understand your proposal correctly, that it can be implemented as a pure extension to existing Siren.
Note, I'm not implying it should remain that way.  I think we really do need a richer way of specifying the underlying data model.
As for XML, my concern previously was trying to avoid the current issue of effectively only supporting HTML forms.  Expanding it as you have outlined means that it then becomes HTML forms + JSON and that further extensions would be required for actions that POST, for example, XML data.  Personally, I never use XML and I build all the APIs I use myself.  So I'm fine with what you are proposing.  I'm just noting that it would require further "extensions" for users who wanted to support other formats (e.g., XML, protobuf, etc).

@xogeny I understand/share your concern about multiple schemas. On the other hand I requested application/vnd.siren+json in the first place, so it seems fair and reasonable that the API responds in the format (including schema) originally requested (+json).
@Kampfgnom  I like your layout, especially that inline and referenced schemas are possible (which is great for client side caching). This is what I need to feed schemas directly to form generators.
Another solution would be to tell the server about the desired schema format, i did tell him I want Siren, so why don't tell him I want json schemas :)
Sadly the media type is so static and it is not feasible to register new ones all the time application/vnd.siren+json+json-schema-d-07

@Kampfgnom IMHO 'standards' should come from (multiple) real world implementations and seeing what works and what doesn't, not from being 'blessed first' then implemented.
That said, if your use case has a need for a non-standard extension you should do it to fit your needs (and document the pros/cons for the community).  There are no standards police going to show up and yank your ability to use Siren ;)

Speaking of implementations, perhaps it is worth sharing something I've been working on because it may provide a means for exploring this topic but without necessarily changing Siren.
Obviously, I've been on the "richer schema for actions" band wagon for a while.  To me, schemas provide an important means for validating data as well as form generation.  So I'm all for it.  But one downside worth mentioning in this discussions is the degree of redundant information potentially presented by the Siren server.  While it is true that a schema can be represented as a reference (thus minimizing the number of characters required to convey the structure of an action payload/URL), it really is static information that need not be bundled with a response.
Not that it isn't just the fields.  Basically, all the fields associated with an action are typically static and the only "dynamic" aspect (the thing that might change from payload to payload) is whether a given action is "available" (whether that affordance is permitted by the current client).
But once you start thinking along these lines, there are a couple of other interesting things to note.  For example, there is no way to convey what to expect in the properties of a resource.  Similarly, there is no way to convey what relations you might find associated with a given resource and what resources those are likely to point to (and how many there might be).
Again, much of this is static.  In fact, many approaches like OpenAPI/Swagger have up front specifications for this "static" information.  But those formats do not necessarily lend themselves well to hypermedia APIs and tend to be more "CRUD" oriented with fixed resource URL patterns, etc.
After RestFest in Grand Rapids, I started playing around with the idea of writing up specifications for hypermedia (but in my case pretty Siren-centric) specifications for APIs.  The idea is that a siren response could come with a simple Link header or a rel="describedby" relation that points to a profile that describes the API.  But to be honest, I my main use case doesn't actually involve dynamically inspecting responses and then fetching profiles.  Instead, my idea is more about using an up front specification to specify the classes and relations involved and then generating a bunch of stuff.
At the moment, I've got a prototype that can generating TypeScript type definitions for properties of resources and action payloads automatically from the specification.  The definitions can be shared by both the client and server to ensure that the payloads being exchanged over the wire conform to a common "shape".
I'm also able to generate documentation that automatically generates a graph (both per resource and for the entire API) that shows the resources types, resource properties, actions, what relations exist between resources and the cardinality of those relations.
The next thing I'd like to add is to generate (per API) a client navigation library specific to that API.  This library would be generated from the specification, include static types for all navigation (checking payloads of all requests and types of responses) and it would allow navigation using the resources and relations named in the API, e.g.,
let orders = await api.findCustomer({ name: "ACME" }).follow("orders");
orders.sort((a, b) => a.orderData > b.orderDate);

This would all be Siren payloads behind the scene and, again, typings would ensure that everything here conforms to the expected data being passed into and back from the API.  I already have a library called siren-nav that allows navigation through a generic Siren API.  The code generation would simply build on this to provide something using specifically the resources, relations and actions that were part of the specification.
Part of the plan here is that during development, validation checks would be put in place during testing to ensure that payloads being passed around conformed to the schemas specified.  Furthermore, the profile already allows resources, relations and actions to be marked as deprecated allowing further checks if you want to have a strictly conforming interaction with the API (i.e., no deprecated calls).
Why am I mentioning all this in this thread?  Well in my use case, all this schema stuff is kept in the profile and the action responses are minimal (the information simply isn't needed if the client was constructed from the profile...it already knows all this).  The bottom line here is that this project of mine is currently in a private repository.  But if people are interested in this approach, let me know and I can make it public and we can perhaps move this discussion over there and all get out of @apsoto's hair. 😄

Swagger is in deed CRUDy. But I recently learned that links are introduced in v 3.0 which is good. Graphs and linked types/classes, delivered by the API seem a interesting approach. There is also a danger in becoming the new WSDL though :)
I did also work on a prototype for a type save client, which would fail early. I (hand wrote) some client side classes and pass it to a generic client. It looks something like this:
var hypermediaObjectRegister = CreateHypermediaObjectRegister();
var sirenClient = new SirenHttpHypermediaClient<EntryPointHco>(ApiEntryPoint, hypermediaObjectRegister);
var customersAll = await sirenClient
    .EnterAsync()
    .NavigateAsync(l => l.Customers)
    .NavigateAsync(l => l.All);

var customer = customersAll.Customers.First();
var actionResult = await customer
    .CustomerMove
    .ExecuteAsync(new NewAddress {Address =  "New Address"});
Assert.IsTrue(actionResult.Success);

Experimental Siren client
Would realy like to continue discussing about discoverable documentation/schemas and clients.

Just to add to the "existing implementations" part: Our current way of working involves hand writing a small wrapper client around a more general siren client, that only encodes relation- and action-names. The resulting code looks like this:
const buildings = await client
  .entryPoint(context)
  .generalManagement()
  .findBuildingsOfCompany({ customerNumber: '123'  })
  .items();

That being said, I acknowledge everything said about specifications and generation of clients. But I would like to come back to the "incremental improvements"-part 😉 At the same time I acknowledge @apsoto's comment about "multiple real-world implementations".
All in all I'm happy to see that our current approach is at least "not bad"™ . I will now incorporate it into a part of our solution and we'll see how that goes. Since I am working for a big'ish customer, I hope that we all can get some meaningful result from that 🙂

@Kampfgnom and @MathiasReichardt It isn't clear to me from your responses whether you are interested in looking at this profile specification stuff.  If so, I'll write something up about it and publish it.  Just let me know.  My email is associated with my GitHub ID, so just reach out to me there so we don't take up any more space in this thread about that.

@xogeny I have some questions. I have to say that I find very interesting what you are describing and the general discussion here, but I want to make sure that I have understood completely what you describe.

While it is true that a schema can be represented as a reference (thus minimizing the number of characters required to convey the structure of an action payload/URL), it really is static information that need not be bundled with a response.

I would say that metadata (hypermedia etc) is relatively much less volatile than the data. By having them through a reference link, you can add whatever caching headers you want through HTTP, so it doesn't always need to be bundled with a response. Most of the times, you just need to fetch it once.

But once you start thinking along these lines, there are a couple of other interesting things to note. For example, there is no way to convey what to expect in the properties of a resource. Similarly, there is no way to convey what relations you might find associated with a given resource and what resources those are likely to point to (and how many there might be).

If I understand you correctly, we don't have such spec as of now for associations etc, that doesn't mean that it's not possible through those "rich schemas". Personally I would love to have such specs ready but it's not easy and in my opinion ideally we opt for compsability, i.e. compose different specs together instead of creating a complex monolith that tries to solve everything at once. But that's another discussion..

Again, much of this is static. In fact, many approaches like OpenAPI/Swagger have up front specifications for this "static" information. But those formats do not necessarily lend themselves well to hypermedia APIs and tend to be more "CRUD" oriented with fixed resource URL patterns, etc.

I never liked Swagger/OpenAPI for that reason: their thinking is to create the specs offline and from that go and scaffold code and possibly documentation. If Swagger allowed me to expose the API specifications online, without any change I think it would be fine (maybe they can do that now? I haven't touched it for a while). If that was possible, then we could talk about patterns, efficiency and good design for exposing those metadata.

The idea is that a siren response could come with a simple Link header or a rel="describedby" relation that points to a profile that describes the API. But to be honest, I my main use case doesn't actually involve dynamically inspecting responses and then fetching profiles. Instead, my idea is more about using an up front specification to specify the classes and relations involved and then generating a bunch of stuff.

Curious: how is the describedBy structured? Does it describe the endpoint, the resource or the whole API?
Also, from what I understand, the difference in your implementation compared to conventional hypermedia-based API-agnostic clients is that you first fetch the metadata of the API (hypermedia, fields, types, associations etc) and then you do the API requests (after you build your client). Am I right ? If that's the case, given that the API design allows you to do such thing, I am pretty sure that's the best practice actually and not an edge case.
Again if I have understood you right, I don't feel that this is much different from Swagger, only that is done the right way. As I said before, unfortunately Swagger focused on scaffolding stuff rather than the self-discovery of API metadata/hypermedia through API introspection.

Why am I mentioning all this in this thread? Well in my use case, all this schema stuff is kept in the profile and the action responses are minimal (the information simply isn't needed if the client was constructed from the profile...it already knows all this).

I am wondering how you have structured all those metadata (I feel metadata is the right word here and not hypermedia as hypermedia is a subset of metadata and mostly refers to links and actions. Correct me if I am wrong). Would you like to share more information ? If I can do a high level overview: what you are describing isn't a meta-API for your API that you exploit to setup your client beforehand ? How is that different/similar to a generic API introspection (regardless the specs/profiles used)?
@kevinswiber I like the initiative here, but I would like to be able to negotiate for the schemas that I understand. And I don't mean XML vs JSON Schema, but also negotiate for which version of JSON Schema. However, I don't think that's Siren's responsibility and should left to HTTP. But I feel that this is gonna be super complex with proactive-negotiation (I have tried such discoveries with similar things but it's a chicken-n-egg problem in proactive negotiation..) and reactive negotiation would help a lot.  So I guess I don't help you much here but if you could find a way to support that it would be awesome :)

Is there any progress on this idea?

I just wanted to drop a note in here about this topic 4+ years on.  I contributed to this thread previously as @xogeny but as that company has since been acquired, I'm just commenting under my personal Github account.
I wanted to try and stay as conformant to Siren as I could.  I ended up handling this in effectively two ways.  The first was to establish a profile relation link to my resource that includes in it the collection of JSON schemas for each supported action.  Furthermore, I hope to further add JSON schemas for classes associated with the resource (the union of which would presumably count as a JSON schema for the properties themselves, at least the way I approach the API design). To summarize, the profile would ideally return something like this:
{
  ...
  schemas: {
    classes: {
      "className1": { /* JSON Schema for class named "className1" */ },
      ...
   },
   actions: {
     "actionName1": { /* JSON Schema for action named "actionName1" */ },
     ...
  }
}

The nice thing about what I've described so far is that it doesn't require changing the Siren specification.  Furthermore, I see the profile information as essentially static.  Because it is accessed independently of the resource itself (i.e., has its own URL), I can put very different cache-control headers on it (presumably ones that allow the browser to hang onto this information for extended periods of time in the case of mature APIs).  In practice, this means that most applications would generally only have to truly GET this information once.
But I also added a schema field to the action.  This gives a more direct indication that this particular action has a schema associated with it.  But to avoid including enormous blobs of schema for all clients, I instead rely on the $ref feature of JSON schema so it adds just a single line, e.g.,
"schema": { "$ref": "/profile/url/for/resource#/schemas/actions/add" }

Now, I don't actually expect to use the schema field myself.  The reason is mainly because I access my APIs via my siren-nav library.  That, in turn, leverages my siren-types library which defines an Action as:
export interface Action {
  name: string;
  class?: string[];
  method?: "GET" | "PUT" | "POST" | "DELETE" | "PATCH" | "HEAD" | "OPTIONS";
  href: string;
  title?: string;
  type?: string;
  fields?: Field[];
}

Note the absence of a schema field.  Again, I'm trying to stick with standard Siren here and I don't want to extend my siren-types library to include fields that are not part of the Siren spec.  A user could always do some kind of dynamic cast if they knew the field was there.  But I don't want to confuse users of that library into thinking that schema is part of Siren by referencing it here.
So, in practice what I will end up doing is that for APIs that support the special profile link that yields schemas, This means of accessing the schema can already be expressed in my siren-nav library quite easily as: nav.follow("profile").get().asJSON() and then simply extract the field schemas.actions["<action-name>"] from the JSON that is returned.
Now, all that being said, I do think it would be nice to have a standard field in the action itself.  It just seems like a nice way to extend the self describing nature of Siren a bit more.  Frankly, there are rarely applications where I can use the HTML-ish field descriptions that are standard in Siren and even in those cases where I do, using libraries like typebox I can really easily provide such schemas.  This is important in practice (especially in APIs) because it allows me to have a "single source of truth" about the data I'm working with can support:

Specification of static types for type checking of code
Validation of deserialized data (to ensure it conforms to the static type shape)
Ability to serialize the type itself (into JSON schema) and share it with clients (i.e., the schema field) to allow client side validation as well.

Anyway, I just wanted to share this with others.  It doesn't really negate what I think is still an open need for a schema field, but I wanted to point out how I chose to work within the constraints of existing Siren to arrive at a satisfactory (IMHO) solution.

I just wanted to drop a note in here about this topic 4+ years on.  I contributed to this thread previously as @xogeny but as that company has since been acquired, I'm just commenting under my personal Github account.
I wanted to try and stay as conformant to Siren as I could.  I ended up handling this in effectively two ways.  The first was to establish a profile relation link to my resource that includes in it the collection of JSON schemas for each supported action.  Furthermore, I hope to further add JSON schemas for classes associated with the resource (the union of which would presumably count as a JSON schema for the properties themselves, at least the way I approach the API design). To summarize, the profile would ideally return something like this:
{
  ...
  schemas: {
    classes: {
      "className1": { /* JSON Schema for class named "className1" */ },
      ...
   },
   actions: {
     "actionName1": { /* JSON Schema for action named "actionName1" */ },
     ...
  }
}

The nice thing about what I've described so far is that it doesn't require changing the Siren specification.  Furthermore, I see the profile information as essentially static.  Because it is accessed independently of the resource itself (i.e., has its own URL), I can put very different cache-control headers on it (presumably ones that allow the browser to hang onto this information for extended periods of time in the case of mature APIs).  In practice, this means that most applications would generally only have to truly GET this information once.
But I also added a schema field to the action.  This gives a more direct indication that this particular action has a schema associated with it.  But to avoid including enormous blobs of schema for all clients, I instead rely on the $ref feature of JSON schema so it adds just a single line, e.g.,
"schema": { "$ref": "/profile/url/for/resource#/schemas/actions/add" }

Now, I don't actually expect to use the schema field myself.  The reason is mainly because I access my APIs via my siren-nav library.  That, in turn, leverages my siren-types library which defines an Action as:
export interface Action {
  name: string;
  class?: string[];
  method?: "GET" | "PUT" | "POST" | "DELETE" | "PATCH" | "HEAD" | "OPTIONS";
  href: string;
  title?: string;
  type?: string;
  fields?: Field[];
}

Note the absence of a schema field.  Again, I'm trying to stick with standard Siren here and I don't want to extend my siren-types library to include fields that are not part of the Siren spec.  A user could always do some kind of dynamic cast if they knew the field was there.  But I don't want to confuse users of that library into thinking that schema is part of Siren by referencing it here.
So, in practice what I will end up doing is that for APIs that support the special profile link that yields schemas, This means of accessing the schema can already be expressed in my siren-nav library quite easily as: nav.follow("profile").get().asJSON() and then simply extract the field schemas.actions["<action-name>"] from the JSON that is returned.
Now, all that being said, I do think it would be nice to have a standard field in the action itself.  It just seems like a nice way to extend the self describing nature of Siren a bit more.  Frankly, there are rarely applications where I can use the HTML-ish field descriptions that are standard in Siren and even in those cases where I do, using libraries like typebox I can really easily provide such schemas.  This is important in practice (especially in APIs) because it allows me to have a "single source of truth" about the data I'm working with can support:

Specification of static types for type checking of code
Validation of deserialized data (to ensure it conforms to the static type shape)
Ability to serialize the type itself (into JSON schema) and share it with clients (i.e., the schema field) to allow client side validation as well.

Anyway, I just wanted to share this with others.  It doesn't really negate what I think is still an open need for a schema field, but I wanted to point out how I chose to work within the constraints of existing Siren to arrive at a satisfactory (IMHO) solution.


Custom [go to definition] Shortcuts

hello:
I have vscode-youcompleteme and vscode-gnu-global Plug，two plug-in [go to definition] is the same, It looks a bit confusing, So I want to customize the shortcuts vscode-youcompleteme [go to definition], What should I do?
thanks

I think goto is a language server api. Not a command shortcut.

[go to definition] how to separate out into another name or command?

Here's the code to find the definition, it only response with a location, and vscode will jump to.
https://github.com/richard1122/vscode-youcompleteme/blob/master/server/src/server.ts#L118
I'm not sure how to make extensions to jump to the file and location, but if you are willing to take some investigation, PR's are welcome.


Clear documentation for the functions?

The documentation is written on all functions in each interface. I changed project build options to emit comments in xml file along with the dll. Thinking of using doxygen or some other document html generator to include html documentation as well.

The things that I did to resolve this one are

Added detailed XML summaries to all methods and functions for each part of the service
Generated a full api reference documentation in chm standard format which can be found here https://github.com/sdesyllas/RiotApi.NET/tree/master/Documentation/Help
Added Sandcastle documentation project so that the full api reference will be updated for each change in the code


Move to Fedora

Since all the stuff we are deploying here is pretty bleeding-edge and almost everything is outdated for us in CentOS (like this #7) i propose swap underlying OS to Fedora (e.g. 22).

Then we even don't have to install additional repos and use something like this:
yum -y install --enablerepo=updates-testing kubernetes

No objection on what the underlying OS. Too bad the parity between OS distros are still such that it is not just a simple configurable when provisioning the hosts.
I would have to acquire or build a Fedora image for my Openstack environment has there is not one currently available.

Another choice can be Fedora Atomic. Thoughts?

28 июля 2015 г., в 19:24, Kenny Jones<EMAIL_ADDRESS>написал(а):
No objection on what the underlying OS. Too bad the parity between OS distros are still such that it is not just a simple configurable when provisioning the hosts.
I would have to acquire or build a Fedora image for my Openstack environment has there is not one currently available.
—
Reply to this email directly or view it on GitHub.

Considering Atomic is built specifically for use with containers and kubernetes, it should work quite well.

Both are used by mainstream k8's. Does one of them allow you to use more of their automation?

I suppose we can port some parts from there.

2 авг. 2015 г., в 04:23, Peter Lamar<EMAIL_ADDRESS>написал(а):
Both are used by mainstream k8's. Does one of them allow you to use more of their automation?
—
Reply to this email directly or view it on GitHub.

Since all needed components are available in stable CentOS channel this issue can be closed


Support Spree 4.5 (with compatibility)

Based off JuanseGimenez's PR. Please refer to that link for details.

I think this issue will be fix on prevoius PR https://github.com/spree-contrib/spree_multi_vendor/pull/216

@nciemniak this one too :)

Hi @JoseMPena could you please describe a bit more what's the scope of changes in your PR (compared vs the @JuanseGimenez PR that you mentioned)?

@JoseMPena thanks. I'm looking through the code, but I can't find any usages of current_spree_vendor or set_vendor_id in the V2 endpoints. Is it needed there?


TextField always expands on enter keyDown, even if new content won't require it

Description
I have a controlled multiLine TextField, like this:
h TextField,
  multiLine     : yes # It's alway a text area underneath...
  rows          : 1   # ...but let it look like a text input
  value         : @state.value

I want to prevent newline characters inside (I just need line wrapping if the text is long), so in my onChange callback I do:
onChange: (event, input) =>
  @setState value: input.replace /\n/g, ""

That way when user changes the content of the field, it will be stripped of any newline characters.
This works as expected, except for a strange "glitch": when user presses Enter key, the field's height expands unnecessarily. Next (any) key press make it contract to correct height again. It looks weird.
I have found a workaround for that, but still want to report it, as IMO it's a minor UX issue in your otherwise awesome components library.
Here is my workaround:
onKeyDown: (event) =>
  # This is a workaround
  if (event.key is "Enter")
    do event.preventDefault

Link to minimally-working code that reproduces the issue
In fact you can reproduce the issue with even simpler (although not very practical) setup:
http://www.webpackbin.com/41E9uMy8z
Versions

Material-UI: 0.16.6
React: 15.4.2
Browser: Google Chrome 55.0.2883.95 (64-bit)

I understand your issue, but I don't think it's currently a use case we can accommodate. An enter key is valid input, and the textfield responds accordingly. SInce you've found a workaround, lets park it here.