Add infrastructure to Parley to facilitate text selection/editing

We want Parley to implement types and methods that Masonry and other editors will be able to use to create a text-editing widget, or to handle selection in non-editable text.
After some discussion we've settled on the following:

A TextMovement enum representing different possible changes to a text edit's selection and content. Possible variants might be eg MoveLeft, MoveToNextWord, SelectToNextParagraph, RemovePreviousWord, etc.
A function that maps a String, a cursor position(/span) and a TextMovement to a StringDiff and position(/span). That function essentially tells you "if you do that, here's how the text will change and where your cursor will be next".
Later down the road, once we want to implement spans, a function that maps a span and a StringDiff to an optional span.

Possible signatures:
enum TextMovement {
  MoveLeft,
  MoveRight,
  // ...
}

struct StringDiff {
  removed_span: usize..usize,
  new_position: usize,
  added_text: String,
}

fn apply_movement(string: &str, movement: TextMovement, byte_offset: usize) -> StringDiff;

fn map_span(span: usize..usize, diff: StringDiff) -> Option<usize..usize>;

We might use Parley's Cursor type instead of byte offsets in these interfaces.

We might use Parley's Cursor type instead of byte offsets in these interfaces.

Never mind. A quick look at parley suggests Cursor is more of an output type than a live marker.
Basically, you have one function that gives you a cursor from a (x, y) pair, one function that gives you a cursor from a offset: size_t, is_leading: bool pair, and then code in Masonry that uses the values returned to display stuff.
You're not supposed to feed it back in other parley functions.

Planned API:
pub enum WritingDirection {
    LeftToRight,
    RightToLeft,
}

pub enum ByteDirection {
    Upstream,
    Downstream,
}

pub enum Movement {
    Grapheme(ByteDirection),
    Word(ByteDirection),
    Line(ByteDirection),
    ParagraphStart,
    ParagraphEnd,
    LineUp,
    LineDown,
    PageUp,
    PageDown,
    DocumentStart,
    DocumentEnd,
}

impl<B> Layout<b> {
    fn get_direction(&self, index: usize, affinity: ByteDirection) -> WritingDirection;
}

impl WritingDirection {
    fn left() -> ByteDirection;
    fn right() -> ByteDirection;
}

impl<B> Layout<b> {
    fn apply_movement(&self, index: usize, affinity: ByteDirection, x_pos: f64, movement: Movement) -> (usize, ByteDirection);
}

On the Masonry side:
struct Selection {
    anchor_index: usize,
    anchor_affinity: ByteDirection,
    active_index: usize,
    active_affinity: ByteDirection,
    x_pos: f64,
}

impl Selection {
    fn move(&mut self, layout: &Layout, movement: Movement);
    fn select(&mut self, layout: &Layout, movement: Movement);
    fn is_caret(&self) -> bool;
}

enum TextAction {
    // Arrows, Home, End, etc
    Move(Movement),
    // Ctrl+A
    SelectAll,
    // Shit+Arrows, Shit+Home, Shit+End, etc
    Select(Movement),
    // Backspace, Delete, Ctrl+Backspace, Ctrl+Delete
    SelectAndDelete(Movement),
    // Regular input, paste, IME
    Splice(String),
}

fn convert(event: winit::KeyEvent) -> TextAction;

Will take a lot of inspiration from existing code, especially movement.rs in Masonry.

Re-reading this, this is the most beautiful API I've written in my freaking life.

Looks good. I don't see any reason why those selection and action types couldn't also live in parley though.

We might use Parley's Cursor type instead of byte offsets in these interfaces.

Never mind. A quick look at parley suggests Cursor is more of an output type than a live marker.
Basically, you have one function that gives you a cursor from a (x, y) pair, one function that gives you a cursor from a offset: size_t, is_leading: bool pair, and then code in Masonry that uses the values returned to display stuff.
You're not supposed to feed it back in other parley functions.

Feeding it back into the API was certainly the intended purpose. This is why CursorPath exists.. it gives you quick access to the internal data structures to handle things like movement and generating selection geometry.

If Cursor is desired for a new type, Cursor can be renamed to something like Hit. It's more intended for low level hit testing stuff.

In reality, the type we care about is selection, which I would implement as:
struct Selection {
    anchor: Cursor,
    focus: Cursor,
    h_pos: Option<f32>,
}

Every movement or edit action would take an input selection and action and then return a new selection (which may be collapsed).

Remind me what collapsed selections are?

I would guess that a collapsed cursor is a cursor where the anchor and focus are the same location - i.e. a caret cursor.

Yeah, what Daniel said. If I remember correctly, the web cursor API refers to that as “collapsed”

https://developer.mozilla.org/en-US/docs/Web/API/Selection/collapse

After some discussion with Chad, here is the second iteration of the API I'd propose:
pub enum LogicalDirection {
    Upstream,
    Downstream,
}

pub enum Movement {
    Backspace, // Backspace behaves somewhat differently than LeftArrow.
    Grapheme(LogicalDirection),
    Word(LogicalDirection),
    Line(LogicalDirection),
    ParagraphStart,
    ParagraphEnd,
    LineUp(usize),
    LineDown(usize),
    DocumentStart,
    DocumentEnd,
}

impl<B> Layout<b> {
    fn logical_left(&self, index: usize, affinity: LogicalDirection) -> LogicalDirection;
    fn logical_right(&self, index: usize, affinity: LogicalDirection) -> LogicalDirection;

    fn index_and_affinity_from_point(&self, x: f32, y: f32) -> (usize, LogicalDirection);
    fn cursor_from_index(index: usize, affinity: LogicalDirection);

    fn apply_movement(&self, index: usize, affinity: LogicalDirection, x_pos: f64, movement: Movement) -> (usize, ByteDirection);
}

And Masonry would take care of the rest for now.


Allow external usage of gradle-language-server

By adding the application plugin for Gradle, we can generate a bin script that will allow the usage of gradle-language-server outside of vscode
In particular, I have this working locally with neovim and https://github.com/neovim/nvim-lspconfig, which I intend to upstream support for

Apologies, forgot to use the non-deprecated property. Fixed

Hrm, I can't see what's causing the build to fail. Can anyone give me some more insight?

Hrm, I can't see what's causing the build to fail. Can anyone give me some more insight?

Never mind. It's an issue about first pr of a contributor in this repo... for this pr, I'll take a look.

@DonnieWest interesting, and I'm curious about the usage, now we just build the executable jar of gradle-language-server and use LSP implementation to launch the jar as the language server. That's why we don't apply application plugin in this project. Is there any reason you can't use this jar file directly?
BTW, I have a concern about the corresponding pr https://github.com/neovim/nvim-lspconfig/pull/1710, now we support groovy only, and for kotlin files, it's still in our plan.

@CsCherrYY thanks for the follow up!
My main concern is allowing the user to an executable to their $PATH, allowing third party clients (like nvim-lspconfig) to pick it up and work without much additional configuration. It seems to me that the executable jar solution requires the user to provide custom commands like java -jar to execute, which subverts the $PATH based solution.
The jar solution is not without precedent: eclipse.jdtls has command line instructions that are jar based. But servers like kotlin-language-server make this process much easier for non-VS Code users :)
Regarding the PR to nvim-lspconfig, thanks for the heads up. The other part of the reason that's in draft is because I needed to test against some build.gradle.kts files. Now I know that won't work and I'll amend the PR correspondingly

@DonnieWest Thanks for the clarification, I can get your idea. So, does this PR contain everything you need, or did you test it locally? The changes LGTM, the following steps would be just merging it?

@CsCherrYY Yes, I've tested this locally and it matches the roughly expected behavior from Kotlin Language Server
Thanks 😁


Model not initialized: Member "getTableName" cannot be called. "Model" needs to be added to a Sequelize instance

Versions

sequelize: 5.19.2
sequelize-typescript: 1.0.0
typescript: 3.6.3

I'm submitting a ...

[x] bug report
[ ] feature request
Hi, I have two models
@Table
export default class BillingData extends Model<BillingData> {

    @Column(DataType.STRING)
    Name?: string;

    @Column(DataType.STRING)
    Last?: string;

    @ForeignKey(() => User)
    @Column(DataType.INTEGER)
    UserId?: number;

    @BelongsTo(() => User)
    users?: User;
}

and
@Table
export default class User extends Model<User> {
    @Column(DataType.STRING)
    Hash?: string;

    @HasMany(() => BillingData)
    billingsData?: BillingData[];
}

And sequelize init
const sequelize = new Sequelize(
    Config.get('database.dsn'),
    {
        repositoryMode: true,
        models: [User, BillingData]
    },
);

export default sequelize;

Everything works great, but when I try use repository with include like this
    public getById(id: number): Promise<User> {
        return this.repository.find({where: {id}, include: [BillingData]});
    }

this throw error
Model not initialized: Member "getTableName" cannot be called. "BillingData" needs to be added to a Sequelize instance

But when I log the sequelize instance, models keys look like this
models: { User: User, BillingData: BillingData }

Can you tell me, how can I fix this problem?

Problem resolved :)
In repository, I change include keys to
 public getById(id: number): Promise<User> {
    return this.repository.find({where: {id}, include: [sequalizeInstance.models.BillingData]});
}

Hey @grzegorzCieslik95, yeah this is one way, another is documented here. Hope this helps! :)
So we can close this now, right?

Yes, thanks :)


Instant Idle Notify not triggering after fletching headless arrows

I was combining feathers and arrow shafts to make headless arrows and noticed that Instant Idle Notify isn't sending a notification once I am done fletching the set.

So the reason this probably happens is because instant idle notifier works by seeing the changes in your inventory and just intuits processing actions, they aren't defined specifically so it doesn't understand the concept that arrows are made in batches of 10. It looks for identical inventory changes equal intervals apart at least 3 times and will ping you when you can't do this anymore because you have no supplies left to do so. So I believe it would only ping you when you ran out of arrows/shafts completely.
I don't have a fix for this as it goes beyond the scope of the plugin. However, "Action Progress" and "Efficient Fletching" are both useful for this instead.


[TC-85] Should use "dest_ip" instead of "dest_domain" in "parent.config" and "cache.config" when ofqdn is ip

Should use "dest_ip" instead of "dest_domain" in "parent.config" and "cache.config" when ofqdn is ip.
Author: Jifeng Yang
JIRA Link: https://issues.apache.org/jira/browse/TC-85
Found Version: 2.1.0

I don't believe this will be included in 2.1, moving to 2.2.

@rob05c - do you think this is still relevant w/ atstccfg? how big of a deal is it if we use dest_domain instead of dest_ip? do you know?

Yeah, it's still relevant. I don't think it's a huge issue, because we always use dest_domain, and MSO will put IPs in there, and it seems to work.
It's still something we should fix, because ATS says it's wrong, so it could theoretically break in the future.
We'll probably change TC config gen to always use Strategies, once we have them in ATS 9/10.
But until then, I'd vote keep this issue open, just to not forget about it.

Copied from #7021 :

it seems to work.

It doesn't work, that statement is wrong. I think we just didn't realize it before, because it falls back to the default, and we didn't used to have complex custom parents until recently.
This issue didn't capture the complete issue with the bug. This issue said we should do it, it doesn't say why. The reason and bug is that dest_domain=ip is silently ignored by ATS as if the entire line doesn't exist.


transforms.json missing file extensions, unable to train in NeRFStudio

In the README.md guide it states that the transforms.json file can be used with Instant NGP and NeRFStudio, but using it directly with ns-train in NeRFStudio produces the following error:
FileNotFoundError: [Errno 2] No such file or directory: '<path_to_output_dir>/output_rendering/rendering_0000'

It seems that the paths in transforms.json are missing their extensions. save_image returns the filename without the extension. The only place in the source that uses this return value is save_seen_trajectory_renderings. Perhaps it can be modified to return the filename with extension?

Pull request: https://github.com/lukasHoel/text2room/pull/8


Make attribute and annotation handling more consistent between NixIO and NixIOFr

Describe the bug
Depending on the IO used to load a nix file the loaded neo objects have different attribute values and annotations. This is confusing for the user and leads to inconsistencies.
To Reproduce
One example demonstrating the descrepancies is the file_origin attributes, as can be demonstrated via
from neo import Block, Segment, AnalogSignal
import quantities as pq

asig = AnalogSignal([1,2,3]*pq.V, sampling_rate=1*pq.Hz, file_origin='mydir/anasig_data.txt', array_annotations={'file_origin': ['mydir/single_channel_data.txt']})
bl = Block(file_origin='mydir/block_data.txt')
bl.segments.append(Segment(file_origin='mydir/segment_data.txt'))
bl.segments[0].analogsignals.append(asig)

from neo import NixIO
nio = NixIO('test.nix', 'ow')
nio.write_block(bl)

# reading attributes via NixIO
bl2 = nio.read_block()
print('Attributes read by NixIO')
print(bl2.file_origin)
print(bl2.segments[0].file_origin)
print(bl2.segments[0].analogsignals[0].file_origin)
print(bl2.segments[0].analogsignals[0].array_annotations)
nio.close()

# reading attributes via NixIOfr
from neo.io import NixIOFr
nio = NixIOFr('test.nix')
bl2 = nio.read_block()
print('Attributes read by NixIOFr')
print(bl2.file_origin)
print(bl2.segments[0].file_origin)
print(bl2.segments[0].analogsignals[0].file_origin)
print(bl2.segments[0].analogsignals[0].array_annotations)

This returns
None
None
None
{'file_origin': array(['mydir/single_channel_data.txt'], dtype='<U29')}
Attributes read by NixIOFr
test.nix
test.nix
test.nix
{'channel_names': array([''], dtype='<U1'), 'channel_ids': array(['0'], dtype='<U1')}

Expected behaviour
Both IOs should yield neo objects with the same attributes and values
Environment:

OS:  Linux
Python version: 3.9.5
Neo version: 0.12.0.dev0

This is issue is related to https://github.com/NeuralEnsemble/python-neo/issues/903


Linkart crash on start

Mod Name
Linkart
Mod Homepage
https://www.curseforge.com/minecraft/mc-mods/linkart-updated
Minecraft version
1.20.1
Describe the bug
It crashes on startup no matter if a its a clean install or with other mods
Steps to reproduce
1.Install all dependencies
2.Press Play Minecraft
3.Crash
Logs
just says Error 1
Additional context
No response

Mixin crash https://gist.github.com/melontini/2ba1d6c5010f9abd747e054f9fffdf6c


Add getData Hooks

Call hooks within getData to allow data to be added prior to sheet rendering. It would allow modules to easily do stuff like this without needing to edit the html:

I feel like this would be much better handled by the core software as a counterpart to the existing renderApplication hooks. A preRenderApplication set of hooks that provides access to the already prepared data. I've filed an issue on core about that: https://github.com/foundryvtt/foundryvtt/issues/10397

Coming with core in Application V2, so this will probably be implemented whenever we go V12-only and switch over to that.


Issue Using Keyboard Macros

I use iCUE software to create keyboard macros related to working to LaTeX in atom and have had an issue with a macro (using the prnt screen key) that produces the following:
\begin{itemize}
\item
\end{itemize}
The macro works fine in every programming, however in atom the output of the macro changes at random. Here is a gif that shows the issue (you can see it works the first two times but not the next two):

How is this macro interfacing with Atom?

How is this macro interfacing with Atom?

You can see how it is interfacing with atom in the above gif. The macro is based off of a third party software called iCUE.

You can see how it is interfacing with atom in the above gif.

No, I can't. Is is just pasting text?

The macro doesn't paste text, it works by pressing and releasing the keys on my keyboard. Here is a gif of the macros does.

Thanks!

The macro doesn't paste text, it works by pressing and releasing the keys on my keyboard.

After the macro stops working correctly, if you just type out the key sequence of the macro yourself does the behavior reproduce?
Also I see that Delays checkbox in your screenshot - is that a setting for delay between keypresses?  If you add a small delay does that help?

Hi Rsese,
Thanks for your response.
Typing out the key sequence works fine without the behaviour/error of the macro reproducing.
I added the delays since by increasing the delays between the keys the macro is less likely to fail. However, at 10ms failure is still quite common. I imagine this indicates that this means the issue is a result of the processing power of my computer and atoms high processing demands.


Support Flutter Locale Files (.arb)

JsonIOStrategy can be used. Just add .arb as alternative file type.

Hi @marhali Thanks for the plugin.
It doesn't seem to work correctly for flutter. It shows the description string, not the correct translation string. For example, if you load this localization from flutter gallery, it doesn't work correctly.

Hello the file could be read successfully. However, the plugin does not distinguish between metadata and real data. Maybe it is not the best solution for Flutter. Try a look at https://plugins.jetbrains.com/plugin/13666-flutter-intl


Lemonbar doesn't always show the input we feed it

Because of a bug in lemonbar, feeding new input to lemonbar in quick succession doesn't work, which can lead to lemonbar showing a previous state rather than the newest.
Example: Assume succade is configured with two blocks, both static, one that produces output ever so slightly faster than the other. This will cause succade to feed lemonbar two times in quick succession, the first time only containing the faster block, the second time containing both blocks. However, lemonbar will show only the first block, as it completely ignored the second input, as it came in too fast.
We can't really fix this in succade, so there are two options here:

fork lemonbar, fix it, send a PR (however, there are many unanswered issued and unmerged PRs already, not sure if the maintainer is still active on the project)
find some kind of workaround in succade that can optionally be activated via command line switch (for example, a minimum time between feeds)

See https://github.com/shdown/bar/commit/eb0e9e79b9a35c3093f6e2e90d9fbd175a2305ef

@shdown thanks for making me aware. Did you turn that into a PR for lemonbar?

Yes, but it went nowhere: https://github.com/LemonBoy/bar/pull/198

Looks like it was merged now!


Data properties doesn't trigger rerender on change in IE 10

Version
2.2.6
Reproduction link
https://codepen.io/steinmiller/pen/ZKBQzb
Steps to reproduce
Run in IE 10. I only tried the internet explorer emulator with ie10 agent and winXP ie10 browser.
What is expected?
The textarea rerenders wiith updated textareaContent value, that was set in mounted.
What is actually happening?
value is stored correctly as the console logs it, but no rerender happen, although textareaContent is reactive

works on all other browsers.

It does work in IE10 if you change "mounted" to "created". I don't know if that is feasible, but it is a possible workaround. I also noticed that the flicker of red seems less apparent.

Works as a workaround. Thanks a lot!

Tested with latest version (2.4) in IE10 and it works as expected... closing.


what's the difference betweeen istio-http/1.1 and http/1.1?

If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via emailing
<EMAIL_ADDRESS>where the issue will be triaged appropriately.
Title: One line description
Description:

Describe the issue.
what's the difference betweeen istio-http/1.1 and http/1.1?
[optional Relevant Links:]
Any extra documentation required to understand the issue.

It's used in ALPN for this filter https://github.com/istio/api/blob/master/envoy/config/filter/http/alpn/v2alpha1/config.proto. I don't recall the original purpose of inventing a new ALPN, @howardjohn might know.

The reason for the istio- ones is to distinguish between Istio mTLS and application TLS


Add some great recomendations about crypto

Some great resources about dos and don'ts regarding cryptography for developers:

:page_facing_up: Cryptographic Right Answers
:page_facing_up: An Open Letter to Developers Everywhere (About Cryptography)

There is also Laurens Van Houtven's Crypto 101, which is both a talk and a book:

:movie_camera: Crypto 101
:book:  Crypto 101

But since I have watched only the talk, i decided not to include in this PR.

This is indeed a great addition! 💪


build: Use bazel-remote for Bazel remote caching

This should be more efficient as it uses gRPC over HTTP/2. It has the additional benefit that it does not depend on Google Cloud credentials, so it can be used in cases where different credentials are already in use (e.g. applying K8s configs).

Closing in favor of #1840


Update templated GitHub Actions to perform signing of the final policy using Sigstore

The GitHub actions provided by this repository should be extended to implement the signing of the wasm policy binary artifact.
Acceptance criteria

The wasm binary is signed using Sigstore, via the cosign cli
The signature is performed using keyless signing

I've removed myself from the bug to work in bug that I found in the kubewarden-controller

No worries, my plan is to find how - generally speaking - we have to change our GH action to perform signature. Once this is clear we can propagate that change everywhere.
For example, I noticed I needed to update kwctl to allow a more secure signature process. See https://github.com/kubewarden/kwctl/pull/106


[BUG] DataLakeFileSystemClient.GetDeletedPaths() not return all values in responds body

Library name and version
Azure.Storage.Files.DataLake 12.14.0
Describe the bug
By run DataLakeFileSystemClient.GetDeletedPaths(), The returned type PathDeletedItem is very simple, only contains properties Path/DeletionId/DeletedOn/RemainingRetentionDays.
But the responds from server contains much more information (e.g. Content-Length), following is one of the item returned in the responds body.
</Blob><Blob><Name>dir1/dir2/dir4/file</Name><DeletionId>133340361492907131</DeletionId><Deleted>true</Deleted><Properties><Creation-Time>Mon, 17 Jul 2023 02:55:38 GMT</Creation-Time><Last-Modified>Mon, 17 Jul 2023 02:55:38 GMT</Last-Modified><Expiry-Time>Tue, 18 Jul 2023 02:55:49 GMT</Expiry-Time><Etag>0x8DB86714D0AD089</Etag><ResourceType>file</ResourceType><Content-Length>1024</Content-Length><Content-Type>application/octet-stream</Content-Type><Content-Encoding /><Content-Language /><Content-CRC64 /><Content-MD5>kdOBlavCN6IxTt2D3rMAmA==</Content-MD5><Cache-Control /><Content-Disposition /><BlobType>BlockBlob</BlobType><AccessTier>Hot</AccessTier><AccessTierInferred>true</AccessTierInferred><ServerEncrypted>true</ServerEncrypted><DeletedTime>Mon, 17 Jul 2023 02:55:49 GMT</DeletedTime><RemainingRetentionDays>0</RemainingRetentionDays></Properties><OrMetadata /></Blob>

Some Powershell customer try to calculate the deleted ADLSGen2 items occupied space. But current .net SDK seems not support it.
Expected behavior
SDK should show the properties returned from server when call DataLakeFileSystemClient.GetDeletedPaths().
Actual behavior
SDK doesn't show the properties returned from server when call DataLakeFileSystemClient.GetDeletedPaths().
Reproduction Steps

Run DataLakeFileSystemClient.GetDeletedPaths()
In network trace, in the responds body , each returned items has many properties
In SDK returned object, only Path/DeletionId/DeletedOn/RemainingRetentionDays be returned.

Environment
dotnet --info
.NET SDK:
Version:   7.0.306
Commit:    f500069cb7
Runtime Environment:
OS Name:     Windows
OS Version:  10.0.19045
OS Platform: Windows
RID:         win10-x64
Base Path:   C:\Program Files\dotnet\sdk\7.0.306\
Host:
Version:      7.0.9
Architecture: x64
Commit:       8e9a17b221
.NET SDKs installed:
3.1.426 [C:\Program Files\dotnet\sdk]
6.0.120 [C:\Program Files\dotnet\sdk]
6.0.315 [C:\Program Files\dotnet\sdk]
7.0.203 [C:\Program Files\dotnet\sdk]
7.0.306 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Other architectures found:
x86   [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]
Environment variables:
Not set
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download

Yeah we can look into making sure it parses out all that information that we're missing in the PathDeletedItem. Looks like we may have to make some updates to the generated code here as well.


simple proxy example

Hyper has client and server http support and can probably be used to write an HTTP proxy. @fmonjalet claims to have already written one. In Node.JS it's very simple to write such a proxy in a few lines.
Here is my attempt at doing this with Hyper. The return type from fn call is wrong and I've no idea how to fix it. Such a simple proxy would be an useful addition to examples/.
//#![deny(warnings)]
extern crate futures;
extern crate hyper;
extern crate tokio_core;

use futures::Future;
use futures::future::FutureResult;
use hyper::{client, server, Client, Url};

#[derive(Clone, Copy)]
struct Proxy;

fn server_request_to_client_request(req: &server::Request) -> client::Request {
    // todo: handle parse error
    let url = Url::parse(&format!("{}", req.uri())).unwrap();
    let mut client_req = client::Request::new(req.method().clone(), url);
    client_req.set_version(req.version().clone());
    *client_req.headers_mut() = *req.headers();
    client_req
}

impl server::Service for Proxy {
    type Request = server::Request;
    type Response = server::Response;
    type Error = hyper::Error;
    type Future = FutureResult<server::Response, hyper::Error>;

    fn call(&self, req: server::Request) -> Self::Future {
        let mut core = tokio_core::reactor::Core::new().unwrap();
        let handle = core.handle();
        let client = Client::new(&handle);
        let mut client_req = server_request_to_client_request(&req);
        client_req.set_body(req.body());

        client.request(client_req)
            .and_then(|res| {
                let mut resp: server::Response = server::Response::new();
                resp = resp.with_headers(res.headers().clone());
                resp.set_status(res.status().clone());
                resp.set_body(res.body());
                futures::future::ok(resp)
            })
    }
}

fn main() {
    let addr = "<IP_ADDRESS>:1337".parse().unwrap();

    let server = server::Http::new().bind(&addr, || Ok(Proxy)).unwrap();
    println!("Listening on http://{} with 1 thread.",
             server.local_addr().unwrap());
    server.run().unwrap();
}

The proxy can be tested with
http_proxy=http://localhost:1337 wget http://w3.org

This version compiles with master but does not return any data.
The closure in and_then() is never called.
extern crate futures;
extern crate hyper;
extern crate tokio_core;

use futures::Future;
use hyper::{client, server, Client, Url};

struct Proxy;

fn server_request_to_client_request(req: &server::Request) -> client::Request {
    // todo: handle parse error
    let url = Url::parse(&format!("{}", req.uri())).unwrap();
    let mut client_req = client::Request::new(req.method().clone(), url);
    client_req.set_version(req.version().clone());
    *client_req.headers_mut() = req.headers().clone();
    client_req
}

impl server::Service for Proxy {
    type Request = server::Request;
    type Response = server::Response;
    type Error = hyper::Error;
    type Future = Box<Future<Item = Self::Response, Error = ::hyper::Error>>;

    fn call(&self, req: server::Request) -> Self::Future {
        let core = tokio_core::reactor::Core::new().unwrap();
        let handle = core.handle().clone();
        let client = Client::new(&handle);
        let mut client_req = server_request_to_client_request(&req);
        println!("got request {}", req.uri());
        client_req.set_body(req.body());

        Box::new(client.request(client_req)
            .and_then(|res| {
                println!("got response {}", res.headers());
                let mut resp: server::Response = server::Response::new();
                resp = resp.with_headers(res.headers().clone());
                resp.set_status(res.status().clone());
                resp.set_body(res.body());
                futures::future::ok(resp)
            }))
    }
}

fn main() {
    let addr = "<IP_ADDRESS>:1337".parse().unwrap();
    let server = server::Http::new().bind(&addr, || Ok(Proxy {})).unwrap();
    println!("Listening on http://{} with 1 thread.",
             server.local_addr().unwrap());
    server.run().unwrap();
}

Here is a version that uses a tokio Core per Service. This does not print error but hangs. The reason is probably that it mixes multiple event loops. The code hangs on one loop while another has data.
//#![deny(warnings)]
extern crate futures;
extern crate hyper;
extern crate tokio_core;

use futures::Future;
use hyper::{client, server, Client, Url};

struct Proxy {
    core: tokio_core::reactor::Core,
}

fn server_request_to_client_request(req: &server::Request) -> client::Request {
    // todo: handle parse error
    let url = Url::parse(&format!("{}", req.uri())).unwrap();
    let mut client_req = client::Request::new(req.method().clone(), url);
    client_req.set_version(req.version().clone());
    *client_req.headers_mut() = req.headers().clone();
    client_req
}

impl server::Service for Proxy {
    type Request = server::Request;
    type Response = server::Response;
    type Error = hyper::Error;
    type Future = Box<Future<Item = Self::Response, Error = ::hyper::Error>>;

    fn call(&self, req: server::Request) -> Self::Future {
        let client = Client::new(&self.core.handle());
        let mut client_req = server_request_to_client_request(&req);
        println!("got request {}", req.uri());
        client_req.set_body(req.body());

        Box::new(client.request(client_req)
            .map_err(|e| {
                println!("oops, an error {:?}", e);
                e
            })
            .and_then(|res| {
                println!("got response {}", res.headers());
                let mut resp: server::Response = server::Response::new();
                resp = resp.with_headers(res.headers().clone());
                resp.set_status(res.status().clone());
                resp.set_body(res.body());
                futures::future::ok(resp)
            }))
    }
}

fn main() {
    let addr = "<IP_ADDRESS>:1337".parse().unwrap();
    let server = server::Http::new()
        .bind(&addr, || {
            let core = tokio_core::reactor::Core::new().unwrap();
            Ok(Proxy { core: core })
        })
        .unwrap();

    println!("Listening on http://{} with 1 thread.",
             server.local_addr().unwrap());
    server.run().unwrap();
}

I would be very much interested in such example code. Found another, apparently also not working approach https://gist.github.com/infinityb/600c22ae549cecf43244 (maybe I'm using wrong version of the libraries)

I wrote a simple proxy server with single event loop.
https://gist.github.com/meganehouser/d5e1b47eb2873797ebdc440b0ed482df
I referred to weldr.

Please feel free to submit a PR with such example code! If you need help doing this let me know.

https://github.com/jbg/prox/blob/master/src/main.rs

I'm currently writing a simple proxy with possibility of custom middlewares.
Since I'm a new rustacean, do not expect the code to be the most opti.
https://github.com/terry90/rs-simple-proxy

Seems like this can be closed now with examples/http_proxy.rs existing, right?


make default tab core in index.json

make default tab core in index.json

@gokaiorg
it's not update images PR.
We currently have the "all" tab by default and would like to change this to "core".

@changmyeong It is no longer possible to modify this file. The only configurations you can change are those located in the settings of your space.

@gokaiorg
How do I change the default tab to "core" ?
I didn't find any changes to the default tabs in the space settings.

@gokaiorg Oh, Sorry. I found it.


[✨] Expose InputHTMLAttributes to the outside

Is your feature request related to a problem?
In jsx-runtime.d.ts there is a type called InputHTMLAttributes.
When building Input Components with Modular Forms (see https://modularforms.dev/qwik/guides/input-components), you currently have to redefine many of these props manually because that type can't be imported (note the TextInputProps type in the linked guide).
It would be awesome if this redundancy could be removed.
Describe the solution you'd like
I would love if I could import this type into my own project.
Describe alternatives you've considered
N/A
Additional context
No response

You can do QwikIntrinsicElements[‘input’] to get all input attributes. Does it work for your case?

Thanks @ffMathy for the suggestion and thanks @ahnpnl for the answer, I think you are correct and this should solve this
Closing for now, feel free to re-open if this doesn't solve your issue


Add "--ignore-submodules" to the git-status query

I have a few submodules in my .vimrc directory that make my git-status query quite slow so I aliased them to include --ignore-submodules.
The nerdtree-git-plugin queries the git directory without the ignore parameter, which makes my NERDTree extremely unresponsive. Doing this to line 76 fixed it for me:
let l:statusesStr = system('cd ' . l:root . ' && git -c color.status=false status -s --ignore-submodules')

Is this safe to include into the repo? :) The plugin only uses git-status to query the information about the current directory anyways, doesn't it?

Thanks :)

Have fun!


Unable to see the data on the Stacked Columns chart when the data is too small.

My versions:
"apexcharts": "^3.6.8",
"vue-apexcharts": "^1.3.4",
When the differences between the datas on stacked columns charts are too big, you can`t see the numbers on the smaller columns, like this:
https://prnt.sc/p1x342
There is any quick solution to this, like putting the number above the column instead inside when its too small to fit?
My chartOptions:
chartOptions: {
chart: {
stacked: true,
toolbar: {
show: false
},
zoom: {
enabled: false
}
},
responsive: [
{
breakpoint: 480,
options: {
legend: {
position: 'bottom',
offsetX: -10,
offsetY: 0
}
}
}],
plotOptions: {
bar: {
horizontal: false
}
},
xaxis: {
type: 'category',
categories: [],
labels: {
style: {
colors: 'black'
}
}
},
legend: {
position: 'right',
offsetY: 40
},
fill: {
opacity: 3
}
}

plotOptions: {
  bar: {
     dataLabels: {
        hideOverflowingLabels: false
     }
  }
}

Hello!
Sorry, but the same occurs to me:

There's any way to fix it? I've already tried to put hideOverflowingLabels to false and it didn't work out as I expected.

is it solve?

Any update or any solution for above issue, we are also facing similar issue.  I've already tried to put hideOverflowingLabels to false and it didn't work out as I expected.

Any update or any solution for above issue, we are also facing similar issue. I've already tried to put hideOverflowingLabels to false and it didn't work out as I expected.

I've tried use logarithmic scale on chart, but dont work also, check my issue: https://github.com/apexcharts/apexcharts.js/issues/3456
I changed my chart library to ECharts (works wonderfully)


Some minor changes/fixes to ux backend

Move content of services/types package to the services package
Move onboading_tokens content into its own sub-package
Separate onboarding_tokens message handlers to distinct
functions based on the message method
Fix onboarding_tokens invalid content type
Removed unused env variable
Added changes oauth proxy config to work UI integration smoothly

@rchikatw let's now have multiple commits for fixes to the merged PR. it'll be helpful to get this part of #2345
/hold

/unhold
@agarwal-mudit @iamniting

@nb-ohad has raised a PR w/ minor fixes around recently merged (only to main and custom branch atm) HTTP API feature #2345
there were a couple of review comments and Ohad didn't respond after that. So not to block this further, Ritesh raised this current PR w/ Ohad's PR content and another minor change of removing unused env variable
can this PR be merged if you are fine w/ the changes?

@umangachapagain would you be able to comment on this https://github.com/red-hat-storage/ocs-operator/pull/2352#issuecomment-1869506493?

/hold

/retest ocs-operator-bundle-e2e-aws

/test ocs-operator-bundle-e2e-aws

@bipuladh as per the suggested changes in the OCS-operator to make the OAuth proxy work has been done. Can you please review

/test verify

/test all

Closing this PR as this is not required because changes with oauth config-related HTTPS is not working as expected


[QUESTION] Alpha channel in jpeg files

Hi,
I am trying to open .blp files for a project I'm currently working on. This file type has multiple formats, one of which contains embedded jpg data.
The problem I have is that this jpg data can have an alpha channel, but when I load the byte array using SkiaSharp, this information is lost.  I tried using different SKColorSpaces and setting SKImageInfo.AlphaType, but nothing seems to work.
Am I missing something, or is this simply not supported at the moment? If it's not supported, I'd love to see this feature added.
In case you need it, I have some test files here: https://github.com/Drake53/War3Net/tree/master/tests/War3Net.Drawing.Blp.Tests/TestData
The file "VillageFallStonePath" is the one with an alpha channel. The .blp file is the original, the .jpg I created by writing the byte array directly to a file, and the correct .png file I saved using a tool called BlpLab.
Related/additional reading:
https://www.hiveworkshop.com/threads/the-evil-that-is-blp.269997/
https://www.hiveworkshop.com/threads/blp-specifications-wc3.279306/

Not gonna lie, that transparent jpeg threw me a bit. I didn't know that was even a thing.
This is a discussion for the native skia team: https://groups.google.com/g/skia-discuss


Conditional formatting is lost after reading and writing

If I use workbook.xlsx.readFile to read in an Excel file that has conditional formatting rules, and then write the data back out with writeFile, the conditional formatting is not present in the newly written file.

I have the same problem.
After reading and writing the excel file, all the conditional formatting rules inside the excel file are cleared.

Same thing happens to me , Any updates on this issue?

@plynchnlm   Can you provide test code and versions used? I used the master branch to verify andAfter reading and writing the excel file, Did not clear conditional formatting rules in the excel file.

am also facing the same issue.  here is error whcih gets displayed while opening the XLSX file in windows. and supricingly it shows good in Mac.
`

-

error166440_01.xml

Errors were detected in file 'C:\Users\lenovo\Downloads\worklog123.xlsx'

-

Excel completed file level validation and repair. Some parts of this workbook may have been repaired or discarded.

-

Removed Part: /xl/styles.xml part with XML error. (Styles) Load error. Line 2, column 0.

-

Repaired Records: Cell information from /xl/worksheets/sheet1.xml part`

cond_format.xlsx
The attached test file shows the problem when the following is run on Windows:
node -e "const Excel = require('exceljs'); var workbook = new Excel.Workbook(); var data = workbook.xlsx.readFile('./cond_format.xlsx').then(()=>workbook.xlsx.writeFile('./test.xlsx').then(()=>console.log('Finished writing')))"

node version: v10.17.0
exceljs version: 3.3.1

@plynchnlm Thank you very much for providing relevant test code and files. In my verification, this problem does exist in version 3.3.1, but versions 3.5.0 and above work well, so it is recommended that you use the latest version 3.8.1.
@gangadharingithub Can you provide test code and versions used? This is very helpful for us to solve the problem.

cond_format.xlsx
@Alanscut Hi,you can test this file.
An error occurs when opening the file
node -e "const Excel = require('exceljs'); var workbook = new Excel.Workbook(); var data = workbook.xlsx.readFile('./cond_format.xlsx').then(()=>workbook.xlsx.writeFile('./test.xlsx').then(()=>console.log('Finished writing')))"
node version: v12.16.1
exceljs version: 3.8.1

I tried my test file I posted earlier with version 3.8.2, and it is working now.  Thank you!  (node version v10.17.0, Windows 10).


adding the paths options

I wanted to have the option to specify a paths array. If the asset is not in one of the paths specified, then I don't want to have it removed (despite it's size). Let me know if this works for you. I appreciate your feedback.

This is a great addition, thanks for contributing!

Thank you @AnujRNair! When you get a chance, can you publish an updated version to NPM. I'm currently using this plugin for one of my projects.

I just did! https://github.com/AnujRNair/webpack-extraneous-file-cleanup-plugin/releases/tag/v1.0.4

Awesome. Thank you so much for the quick response!


Add a configurable exclude directory option for linting

@milesmatthias Will you have a chance to try that?

@milesmatthias Will you have a chance to try that?

I most likely won't have a chance to try that, so if you'd like to give that task to someone else, I'd suggest that.


JsonPatchDocument validity overrides prior parameter(s) invalid ModelState

Is this a Bug or Feature request?:
Bug
Steps to reproduce (preferably a link to a GitHub repo with a repro project):
https://github.com/wentzt/ModelStateOrderRepro
Description of the problem:
When using a Guid route param and a JsonPatchDocument body in a PATCH action, if the Guid is invalid but the JsonPatchDocument is valid, the ModelState will be valid while having an error for the id.
// PATCH test/unexpected/notaguid will be valid if json patch document is valid. ex. []
// PATCH test/unexpected/notaguid will be invalid if json patch document is also invalid. ex. {}
// This is unexpected behavior
[HttpPatch("unexpected/{id}")]
public IActionResult PatchUnexpected(Guid id, [FromBody] JsonPatchDocument<SimpleObj> doc)
{
    return new OkObjectResult(new { ModelState.IsValid, ModelState.ErrorCount });
}

If the order of the parameters is switched, it behaves as expected. The ModelState will be invalid if the Guid is invalid, regardless of the JsonPatchDocument validity.
// PATCH test/expected/notaguid will be invalid regardless of json patch document validity.
// This is the expected behavior, but parameter order shouldn't matter.
[HttpPatch("expected/{id}")]
public IActionResult PatchExpected([FromBody] JsonPatchDocument<SimpleObj> doc, Guid id)
{
    return new OkObjectResult(new { ModelState.IsValid, ModelState.ErrorCount });
}

This appears to be specific to JsonPatchDocument, as using another complex type works as expected.
// PATCH test/expected2/notaguid will be invalid regardless of body validity.
[HttpPatch("expected2/{id}")]
public IActionResult PatchExpected2(Guid id, [FromBody] SimpleObj simpleObj)
{
    return new OkObjectResult(new { ModelState.IsValid, ModelState.ErrorCount });
}

This worked as expected in 1.1. I was upgrading to 2.1 when I discovered this change. I also tried with and without the 2.1 compatibility mode and various combinations of [FromRoute], [FromBody] [BindProperty], [Required], and [ApiController] without a change in behavior.
Version of Microsoft.AspNetCore.Mvc or Microsoft.AspNetCore.App or Microsoft.AspNetCore.All:
2.1.0 & 2.1.1
Thanks!

Taking this one because #8062 PR will address this bug (as well as #7992).

f2608c2ff4


Make the menu items work with common browser commands

Users often open pages in new tabs "for later". Our docs make it super hard for them, because you can't cmd/ctrl click a collapsible link in the menu. You also can't easily copy the link, because the right click menu treats it as a text and not a link.

The non-collapsible menu items can be right clicked, but cannot be ctrl/cmd clicked.

This seems to be fixed already.


Library & advanced performances

The longer is the library list, the more performances are poor, just by selecting a track for exemple. (With like, 5000 tracks).
See what we can do.
https://facebook.github.io/react/docs/advanced-performance.html

in ArtistsList.react.js
return(

            { playing }

            { track.title }

            { utils.parseDuration(track.duration) }

            { track.artist[0] }

            { track.album }

            { track.genre.join(', ') }

);

this is taking way too much time.

Woa.
The piece of code up there was running between 80 and 120ms for 1600 tracks.
After setting NODE_ENV to production, the same code runs in 25ms.


Add version: LuaLS.lua-language-server version 3.6.21

Pull request has been created with Komac v1.9.1 :rocket:
Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/116088&drop=dogfoodAlpha

@wingetbot waivers Add Validation-Executable-Error


Annotation not working if ticks converted to date

Annotation is not drawing for the below code. Can someone please suggest what is wrong in the below code?
Below is the fiddle:
https://jsfiddle.net/oz51504g/2/
How to plot date field in annotation?
I want to plot a horizontal line in 45 degree angle from the starting point. How can i achieve it?
Thanks in advance.

You generally need to specify the desired scaleID for the annotation. You can see it working here: https://jsfiddle.net/oz51504g/3/

@compwright . Thanks a lot. It was that simple :D worked Great.


Added Using Network Policy post

Adds "Using Network Policy in concert with Istio" blog post.

I signed it!

I (for real) signed it!

@andraxylia all of us have reviewed this, except you. If you are okay with this, we can merge.

/okay-to-test

Hi all,
I'm wondering how critical it is to address the latest set of comments.  The Google Doc for this post has been looked at by @geeknoid, @smawson, @louiscryan, Daniel Berg, @matchstick, and @rshriram before setting up this PR.  Is that enough eyes on it, or do we want to go through another round of changes and review?

The changes that Andra proposes seem small enough that you should just fix them, they also echo similar sentiments I had when reading it and clarify that the purpose is really defense in depth, and not operating at different layers.

/approve no issue

@spikecurtis please reuse existing images for bookinfo (assuming that there are no changes). Once done, let me know and I will merge them.

https://github.com/istio/istio.github.io/tree/master/_docs/samples/img/bookinfo

@rshriram I originally just linked to those images, but I decided against it because I don't think we want to couple the blog too strongly with the Istio docs.  I can easily imagine us rewriting/reorganizing the docs and breaking the blog post.
Up to you, but that was my thinking.

Ah don't worry about that. @ldemailly added link checkers to check for broken links, for this very same purpose. It runs as part of presubmits (although I don't know why it is not running now). Broken links is a much more serious problem and we make it a point to keep it in tact.
If you feel strongly about it, can you just copy the two SVG files from that path in bookinfo and put them into the img folder, with a blog- prefix for the filename? no PNGs, just SVGs.

@spikecurtis please send a PR to update the main index in blog.

@rshriram I'm not sure what you are asking.  Sorry!  Haven't used jekyll before...


Sending DELETE request with non existed ID deletes ALL relation tuples on ORY Cloud

Preflight checklist

[X] I could not find a solution in the existing issues, docs, nor discussions.
[X] I agree to follow this project's Code of Conduct.
[X] I have read and am following this repository's Contribution Guidelines.
[X] This issue affects my Ory Network project.
[ ] I have joined the Ory Community Slack.
[ ] I am signed up to the Ory Security Patch Newsletter.

Describe the bug
Sending the following REST request to our ORY cloud project deletes all relation tuples we have.
      const url = new URL(`${ctx.env.ORI_API_URL}/admin/relation-tuples`);
      const response = await fetch(url, {
        method: "DELETE",
        headers: {
          Authorization: `Bearer ${ctx.env.ORI_API_TOKEN}`,
        },
        body: JSON.stringify({
          namespace: "Project",
          object: "NonExistedProjectUUID",
          relation: "editors",
          subject_set: {
            namespace: "Token",
            object: "FixturesTokenUUID",
            relation: "",
          },
        }),
      });

Reproducing the bug
Create a project on ORY cloud
Set Permissions Namespaces & Rules
import { Namespace, SubjectSet, Context } from "@ory/keto-namespace-types"

class User implements Namespace { }

class Token implements Namespace { }

class Email implements Namespace {
  related: {
    owner: User[]
  }
}

class Project implements Namespace {
  related: {
    owner: User[]
    editors: (Token | User | SubjectSet<Email, "owner">)[]
    viewers: (Token | User | SubjectSet<Email, "owner">)[]
  }

  permits = {
    view: (ctx: Context): boolean =>
      this.related.viewers.includes(ctx.subject) ||
      this.related.editors.includes(ctx.subject) ||
      this.related.owner.includes(ctx.subject),

    edit: (ctx: Context): boolean =>
      this.related.editors.includes(ctx.subject) ||
      this.related.owner.includes(ctx.subject),

    own: (ctx: Context): boolean => this.related.owner.includes(ctx.subject),
  }
}

Initial data fill via keto relation-tuple create init.json
[
  {
    "namespace": "Project",
    "object": "AliceProjectUUID",
    "relation": "owner",
    "subject_set": {
      "namespace": "User",
      "object": "AliceUUID"
    }
  },
  {
    "namespace": "Email",
    "object"<EMAIL_ADDRESS>    "relation": "owner",
    "subject_set": {
      "namespace": "User",
      "object": "BobUUID"
    }
  },
  {
    "namespace": "Project",
    "object": "AliceProjectUUID",
    "relation": "viewers",
    "subject_set": {
      "namespace": "Email",
      "object"<EMAIL_ADDRESS>      "relation": "owner"
    }
  },
  {
    "namespace": "Project",
    "object": "AliceProjectUUID",
    "relation": "viewers",
    "subject_set": {
      "namespace": "Token",
      "object": "LinkRandomSequence"
    }
  }
]

Then execute js or rest
      const url = new URL(`${ctx.env.ORI_API_URL}/admin/relation-tuples`);
      const response = await fetch(url, {
        method: "DELETE",
        headers: {
          Authorization: `Bearer ${ctx.env.ORI_API_TOKEN}`,
        },
        body: JSON.stringify({
          namespace: "Project",
          object: "NonExistedProjectUUID",
          relation: "editors",
          subject_set: {
            namespace: "Token",
            object: "FixturesTokenUUID",
            relation: "",
          },
        }),
      });

Check your tuples, they are empty.
Relevant log output
No logs

Relevant configuration
see above

Version
ory cloud
On which operating system are you observing this issue?
Ory Network
In which environment are you deploying?
Ory Network
Additional Context
No response

Hey @istarkov
That is not good! I moved the issue to the ory/network repo, since its most likely affecting only Ory Network projects.
fyi @zepatrik

Thank you for the report, I have elevated this to @hperl

Hi @istarkov, I confirmed this behavior in Keto. The issue is that DELETE (https://www.ory.sh/docs/keto/reference/rest-api#tag/write/operation/deleteRelationTuples) takes the relation query as a query parameter, not as a JSON body.
If you only supply a JSON body (which the API does not care about) and empty query parameters, the API will interpret this as an empty query which everything matches against. This deletes every tuple, as observed by you.
I'd recommend using our SDK, CLI or at least our OpenAPI spec to prevent these kind of issues.
I'm still unsure of what we can do in the API to prevent this, given that an empty query parameter is already well-defined as "delete everything"; adding a "force"/"confirmation" parameter would break backwards-compatibility; add additionally parsing the body would make it difficult to resolve cases where query and body disagree.
As it is right now, the DELETE endpoint is symmetrical to GET, which means that you can already check which tuples will be deleted by passing the same request to GET. In your case, you would have gotten all tuples.

Ooups query params, I see.
Thank you.
sdk uses Axios which is not working on Cloudflare and similar environments.
openapi generator needs java and adding it into any npm package even as a dev dependency is like a disaster in the js world, and finally, it generates non-valid ts (with errors) fetch code (which fails on 204 responses etc...) and finally has like 20x more code than we need.
Thank you, will use openAPI-generated code to check mine in the future.

I think that's a good idea!

I agree, reopening because this should be fixed. Deleting all tuples should only be possible if explicitly asked by the user, it should not happen like this accidentally!

Sure, we can return a BadRequest if a body was given where none was expected. @aeneasr, the API would then still delete all tuples if both body and query is empty. Is that OK? As I mentioned, asking for confirmation would break the current API contract.
(checking if the body is empty would also break the API contract, but in a much less severe way, i.e., all SDKs would continue working)

Unless it's explicit, no API should delete all data ever. It should be absolutely impossible to delete all data by accident.

Is this fixed @zepatrik @hperl ?

Yes, this is fixed. Namespace is now mandatory, and spelling of the query params is checked.


URL for for installing Microsoft Visual C++ Build Tools 2015 no longer exists.

The URL http://landinghub.visualstudio.com/visual-cpp-build-tools no longer points to anything useful.

Dup of #1363 already fixed pending release in #1428


Vertex shaders color broken ?

Godot version:
3.1.1
OS/device including version:
Windows 10
Issue description:
If you assign COLOR  inside Vertex shader it is just ignored.
Steps to reproduce:

create emty scene
Create direct light , camera
create meshinstance assign New spheremesh
New shader material

shader_type spatial;

void vertex()
{
	vec4 iamred = vec4(1.0,0.0,0.0,1.0);
	COLOR = iamred;
}

void fragment()
{
	// do nothing
}

Press Play. You see sphere which quite far from red. Even more it colored with default colors which it get from nowhere.

Minimal reproduction project:

I think the default fragment function doesn't use  vertex colors.
In the fragment() function you can probably do:
void fragment(){
    ALBEDO = COLOR.rgb;
}

Yes but in this case i forced to use fragment shader. And COLOR only used just as a transport for ALBEDO from vertex shader.

This is not a bug. As explained above. You have to assign ALBEDO in the fragment shader. COLOR and ALBEDO do different things. COLOR is used only for passing vertex colors to the fragment shader.
For more information on shaders, please see the docs.  http://docs.godotengine.org/en/latest/tutorials/shading/index.html


Documentation enhancement: Specifying detailed shape requirements for pretrained models

📚 Documentation
In the documentation of PyTorch Model Zoo, it is suggested that:

H and W are expected to be at least 224.

Technically, for H/W < 224 it is also workable, but there might be some lower bound.
For example, the AlexNet model is able to consume a tensor of [3, 200, 200] but not applicable for that of [3, 62, 62].
Similar cases also apply to vgg* and densenet*. Therefore, I am wondering if it is necessary to specify the undefined behaviours of models in the documentation to help users better leverage the models. Thanks.

This information could be useful for those who want to train from scratch or do transfer learning on models with smaller input size. This is because from one point on, the architecture will break if you try to feed it too little data.
When it comes to pretrained models, though it is technically true that some models will work with lower sizes, their accuracies can deteriorate fast. How much worse will depend on the type of model, the architecture etc but here is a recent analysis done by @prabhat00155 for SSD: #3819 (comment)
I still think it might be useful to record the minimum size that the architecture can receive but I would put a clear warning that the pre-trained weights more likely will break if you move very far away from the expected size.

Totally agreed.
I have tested all vision models from on the model zoo and would like to contribute to better documentation by recording the minimum input size of some models (i.e., alexnet, vgg_, densenet). If it sounds good to you, where do you think we should place it?

behind the class signature of models with a minimal input shape
add another paragraph to describe the shape things (including the accuracy tradeoff you commented).

I also know that some models may have very tricky input requirements (e.g., the MaskRCNN model from ONNX model zoo requires the input shape divisible by 32). (But I didn't find such cases in PyTorch Model Zoo b.c. it will try to resize the inputs using GeneralizedRCNNTransform).
The rationale of this issue is that I am building some tools to automatically detect the shape requirements of dynamic-shape models. This would help for many applications. For example, approximation-based computing in video analytics (a classic paper can be found here) where we adaptively change the input resolution (e.g., 720P -> 480P) to tradeoff accuracy and speed (this is also more dynamic compared with other techniques like model compression and quantization). To achieve this, we need to know the input requirements before ahead.

@ganler Thanks for the clarifications and for offering to help. :)
Sounds good. Improving our documentation is always a worth-while thing to do. Let's do some investigation first to ensure you won't start doing the PR and stumble upon blockers. I propose to focus first on the classification models which are easier and commonly reused in other tasks.
I think a good first step is to confirm that all classification models in TorchVision can handle variable input size. It is possible that some old-style models that don't use global pooling at the end and have FC layers require fixed input size. @fmassa would you happen to know this or we need to check?
Concerning adding the info of minimum size to the Class, this can be a bit problematic for two reasons:

As far as I understand not all model classes are exposed on the docs (@NicolasHug is looking into it), so this info might remain hidden.
Some model classes such as MobileNet receive a configuration object in the constructor so the minimum permitted size depends on this configuration and thus is not fixed on the class.

Typically the model building methods such as alexnet(), vgg16() etc have a fixed config used and thus I think it can be safely added there. Another option is to record this on the models.srt page, but I think the model builder is preferable.

Hi @datumbox ,

a good first step is to confirm that all classification models in TorchVision can handle variable input size.

All classification models take variable input shapes. Please check this colab link: https://colab.research.google.com/drive/1T3_M55A75-b2FHaOWs8wYrmlM8gd3lgp?usp=sharing

Concerning adding the info of minimum size to ....

First I checked all the minimum viable shapes in the colab link.
And I have classified those model creator functions' base model class to see if their shape requirement may vary and why.
Always fixed:

Alexnet: Fixed configuration.
VGG: There are many configurations, but all of them are enumerated by some model creators (e.g., vgg11, vgg16).
https://github.com/pytorch/vision/blob/541e0f135b91e10b0b884ffc9952591a51c8aed6/torchvision/models/vgg.py#L86
SqueezeNet: Fixed configuration for v1.0 and v1.1 individually.
MNASNet: Global Avg Pooling. Previous conv2d layers were added with enough padding to make sure all HW are viable.

Possibly fixed-configuration models (checking)

[ ] GoogLeNet: Fixed configuration.
[ ] Inception v3 (aux_logits: bool, transform_input: bool)
[ ] ShuffleNet v2 (stages_out_channels: List[int])
[ ] DenseNet has block_config to configure how many layers in each pooling block
https://github.com/pytorch/vision/blob/19ad0bbc5e26504a501b9be3f0345381d6ba1efc/torchvision/models/densenet.py#L245
But from my experiment, all densenets' minimum input is (1, 3, 29, 29);
[ ] ResNet: similar as above but the minimum input is (1, 3, 1, 1)
[ ] ResNeXt: same as above
[ ] Wide ResNet: same as above

Non-fixed:

MobileNetV2
https://github.com/pytorch/vision/blob/master/torchvision/models/mobilenetv2.py#L108
MobileNet v3: same as above

BTW, maybe we can also add a function to search the minimum shape using binary search.

Thanks a lot for the detailed analysis.
I agree it's worth adding the dimension info in all models that have a minimum dim size > 1.
Let's avoid differentiating between fixed and non-fixed sizes on the Class level and add this info directly on the model building methods (for example torchvision.models.googlenet()).
Could you send a PR that adds this info to the aforementioned classification models?
For example we can update this:
https://github.com/pytorch/vision/blob/541e0f135b91e10b0b884ffc9952591a51c8aed6/torchvision/models/googlenet.py#L26-L30
with something like this:
def googlenet(pretrained: bool = False, progress: bool = True, **kwargs: Any) -> "GoogLeNet":
    r"""GoogLeNet (Inception v1) model architecture from
    `"Going Deeper with Convolutions" <http://arxiv.org/abs/1409.4842>`_.
    The required minimum input size of the model is 15x15.

    Args:
    """

Just bumping this discussion to say it would be great to have this, let me know if I can be of any help!

@logankilpatrick I believe #3944 already adds this information where necessary. Our documentation describes the training size of all models and for those that have a minimum required image size imposed by the architecture, we have a note on their docstrings. Does this cover it?


New / Upgrade desktop computer with framegrabber card

@ralopezastro this is the one you wanted to do, right?

Yes, I will take this one on


Specify consul address in registry arg in snap

Fixes #75

This will also need to be forward-ported to master as well

recheck


Grammar for lumpy

Hi ashn,
Is there any plan to create a grammar struct of the lumpy language? Like you did for sunder with the GRAMMAR file?

Strange it seems to issue this issue twice, sorry for that. I will close this issue


Added Habeeb B. Oyesile to the names list.

Added HBO to the names list.
Related issue

What changes does this PR do?
Screenshots (If any)
Questions

Thanks for the suggestion.
The adjustment has been made.

add your name as per alphabetical order

This has been done. Thanks.

Thank you 😊
I wish to contribute better as I continue my open source journey.


READY: Fix millisecond handling

Fixes #430 (CLIENTS-749).
Adding milliseconds tests.
Add microsecond integration tests

FWIW - I'm seeing what buildbot was seeing, too:
  py278: commands succeeded
  py27: commands succeeded
ERROR:   py33: commands failed
ERROR:   py34: commands failed
  py35: commands succeeded
make: *** [test_normal] Error 1

You already pointed out that Python 3.[34] seems to be a bit challenging.

@javajolt - 3.4.4 works correctly.

:+1: looks good, tests pass with TS 1.1 and py3.5.1

So what are we going to do with Python 3.3.x?

:+1: 65fa199

@borshop merge


Types are not generated correctly for nullable enums

I have these two nullable fields:

When I generate types, I get this result:

As you can see, the fields are not nullable.
I even upgraded to the latest orval version. No result. Am I doing something wrong?

Can you try with orval@alpha

@anymaniax Looks like alpha is working:


[proposal] using < > instead of () for type parameters

Recently after reading some issues using the syntax v3, I found it's painful to see so may parens.
for example, here is a very simple type, it would be even worse for complex types
(int, Js.nullable(int)) => int

it would be much nicer to write it as
(int, Js.nullable <int>) => int

the same applies to type definitions:
type list <'a> =
  | Nil
  | Cons of ('a * list <'a>)

The root cause is () used in too many places, I have to count the parens for complex types.
I guess it is okay to use <>  in types, in expressions there may be conflicts with comparisons, in type level, should be good?

Is the space between Js.nullable and <int> intentional? It seems weird to have them detached like that.
Also, this needs to be considered along with the tuple syntax, which suffers from the same problem. This type has three sets of parentheses with different meanings:
((int, Js.nullable(int))) => int

Is the space between Js.nullable and  intentional? It seems weird to have them detached like that.

Not  intentional.

Also, this needs to be considered along with the tuple syntax,

Yes, I have the same feelings, and proposed to use [ ] for tuples, but did not make it

In general I like the idea of reducing the amount of parens used as there is a lot of them in the new syntax. But also similarly to what @glennsl is saying I think that we need to do something about tuples first, because it has been a way bigger issue for me so far.

I really dislike this idea. For one, higher kinded types are functions,
so the similarity in syntax is warranted. For two, coming from C++ and
Rust, <> in the syntax for type arguments and parameters just does not
feel very good - tooling doesn't really support it, and it makes for either
infinite-lookahead or weird syntax oddities (::<..> in Rust).
On Nov 24, 2017 05:09, "SllyQ"<EMAIL_ADDRESS>wrote:

In general I like the idea of reducing the amount of parens used as there
is a lot of them in the new syntax. But also similarly to what @glennsl
https://github.com/glennsl is saying I think that we need to do
something about tuples first, because it has been a way bigger issue for me
so far.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/reason/issues/1661#issuecomment-346825010,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADUV7eFlq1SY-Kp-f-fK_t_V4wnY6C5Oks5s5r-egaJpZM4QpwWK
.

I can’t think of any technical challenges with <> for types. The conflicts in expressions wouldnt come from inequality operator because we already remap this to !=
Any conflicts in expression real estate would come from JSX if anything.
I do think it’s a fair point about there being many parents in lambda types - making it difficult to see where the lambda arguments end.

I had considered the idea of using <> to represent the type of React components (or any element constructed via jsx) so that we can print the type of nested React elements and have their types appears similar to the jsx that was used to construct them.

@ubsan  ocaml does not have hkt, so your analogy does not apply. Also it is really bad to explain hkt to new users on day one

@bobzhang agh, meant type constructor. This is what very little sleep means -.-

@bobzhang also, I very much disagree with the idea that type constructors, or HKT, are confusing. All they are is functions over types.

I'm mildly against '<>', but I wouldn't be very sad. I'm just not offended by many parens :D and I can appreciate the similarities to Flow, Rust, Swift, Java.... pretty much all of the more popular typed languages.

@jaredly pretty much sums up my take on it, unless there's some insurmountable conflict I'm not seeing.

/me is wondering why so many parenthesis at all as int * int Js.nullable -> int (or even int, Js.nullable int -> int) seems far more readable...  o.O

/me is wondering why so many parenthesis at all as int * int Js.nullable -> int (or even int, Js.nullable int -> int) seems far more readable... o.O

I do not think that int * int Js.nullable is more readable than Js.nullable<int, int> to most programmers.

There’s no symmetry since OCaml does not have hkt. I created this issue not because of taste, but due to the fact that I have to count parens to read a not so complex type

Sorry but my comment about symmetry is not in reference to hkt - it's simply in reference to the tokens themselves. I do agree that the variety of <> makes some paren counting easier, and I'm conflicted because it currently presents a token asymmetry in one area of the syntax that's already kind of hard to remember the rules for.

val fold_right2 : ( 'a * 'b -> 'c -> 'c) -> 'a list -> 'b list -> 'c -> 'c

in reason
val fold_right2 : (((('a *'b),  'c ) => 'c ), list ('a), list ('b), 'c) => 'c

in reason with <
val fold_right2 : (  ((('a *'b), 'c) => 'c), list <'a>, list <'b>, 'c) => 'c

in reason with <  for generics and [ for tuple
val fold_right2 : ( ( ['a,'b], 'c) =>'c,  list <'a>, list <'b>, 'c) => 'c

The latest still looks less readable, but it is a reasonable trade off

@bobzhang
let fold_right2: ((('a, 'b), 'c) => 'c, list('a), list('b), 'c) => 'c;

imo, with proper formatting, this becomes far more readable. With a separate syntax for tuples:
let fold_right2: ((['a, 'b], 'c) => 'c, list('a), list('b), 'c) => 'c;

this is quite readable! (for such a complicated type)

Bob, I believe the second example converted to Reason via:
> echo " val fold_right2 : ( 'a * 'b -> 'c -> 'c) -> 'a list -> 'b list -> 'c -> 'c" | refmt --interface=true --parse ml --print re

Should be:
let fold_right2: ((('a, 'b), 'c) => 'c, list('a), list('b), 'c) => 'c;

The first argument to fold_right2 doesn't need extra parens. (I think @ubsan points out the same thing). So, it's not quite as bad.
I don't mind the <'a> syntax either:
let fold_right2: ((('a, 'b), 'c) => 'c, list<'a>, list<'b>, 'c) => 'c;

But I actually don't think it helps in this specific case too much.  I think it would help in some other cases, although tuple arguments are not super common.
I think in your example the tuples being represented as [ ] had the much bigger impact.
I wish it weren't the case that so many people think of [x, y, z] as being arbitrarily long sequences of things because in that case [ ] for tuples would clean up a lot of stuff. As it stands, people "just get" what [x, y] means in their code today. One challenge if anyone is up for it: determine if it's possible/feasible to create a Hetergeneous List data structure can function as tuples of statically known length with different types at each slot, as well as supporting appending to the head/concating etc so it can function as a homogeneous list if necessary. It's a really long shot, but in that case you kind of get the best of both worlds, and if it's possible it would be worth spending considerable effort/changes to make it happen. (Please get ahold of me if you think this is feasible before going down the rabbit hole on this one).

One other thing that would reduce the number of parens (whether or not we use <> or anything else for tuples even) is to print single identifier token arguments/types without their parens. This is valid ES6, and encouraged by JS pretty printers as well.
Instead of:
type t = ((int) => int, string);

We should print:
type t = (int => int, string);

FWIW, the new data structures introduced in BuckleScript will have types like
('key, 'value, 'id) map which is exactly the same as c++ map <key, value, less<key>>
The expressivity of OCaml parametric types are in the same level of c++ generics(maybe less), there is no type application in OCaml, parameterized types are mostly generics conceptually

Yeah, I agree that OCaml types aren't actually type application, but it does help to get people to think about it in terms of applying functions just so they know the syntax is the same as function application. But in that case, the only aim was familiarity, and <> should also bring that same kind of familiarity. I'm not opposed. It could also be a smooth upgrade too because there is probably space in the syntactic real estate for both (we could parse as () and print as <>). However, the one thing I think this could give up is the following:
We could have something like this:
let myTypeaheads = [<Typeahead />, <Typeahead />];
type typeaheadList = list(Typeahead.element);
// With the sugar:
type typeaheadList = list(<Typeahead />);

even then we still might be able to achieve both simultaneously, it's just a bit ugly and there's probably tricky parsing conflicts.
type typeaheadList = list<<Typeahead />>;
/*  Compare to: */
type typeaheadList = list(<Typeahead />);

I found out first-class module types need to be wrapped in parentheses too. So just to take the extreme example one step further, here's a type expression with four groups of nested parentheses all with different meanings:
((int, list((module X)))) => int

Here is @glennsl's example with <> for type parameters.
((int, list<(module X)>)) => int

It breaks it up a bit.
I think we can also stop requiring parens for first class modules regardless of if we use <> for type parameters:
((int, list(module X))) => int

Which is about as clean.
Then combining the two is probably the cleanest looking of all:
((int, list<module X>)) => int

Can someone address my most meaningful argument against <>?
Specifically, what I perceive to be an inconsistency here?
type myType<'t> =
  | Variant('t);
let x : myType<int> = Variant(0);
let x : myType<(int, int)> = Variant((0, 0));

Can people speak to how big of an inconsistency they perceive this to be? @glennsl, @jaredly, @bobzhang ?

I don't perceive it as an inconsistency at all. I think they should look different because they are different. You could also just as well have let x : myType<(int, int)> = VariantB("foo");.
I am slightly bothered by seeing parentheses nested inside angle brackets, however: <( ... )>. Not entirely sure why. Perhaps because it looks like a slightly chubby but very stern guy 🤷♂
Good to hear parentheses might not be needed for first-class modules. That's one less to worry about at least.

". Perhaps because it looks like a slightly chubby but very stern guy" 😆
Okay, well it's good to hear at least one other person doesn't perceive an inconsistency.

You know, supposedly Lisp people say that eventually the abundance of parenthesis don't bother them and their brains adapt. 🤷♂

They've also invented quite a bit of tooling to help deal with them, such as rainbow highlighting and paredit.

Using parens here gives the user one piece of syntax to remember. One of the early selling points of Reason's syntax was making type parameters look like function parameters in Reason - is that worth giving up?

I really don't think so - thinking of type application as function application is a really nice idea, and is how one should think of type application in languages with stronger type systems, like C++ or Haskell. Maybe Reason doesn't have that powerful of a type system, but it's still a nice idea.
I just really, really dislike <> being used as type parameter lists. If people really wanted to change them, I'd rather we just changed them to [], to be similar to scala/python. <> just feel wrong as type parameter/argument list bounds, despite having used them for years in C++ and Rust.

I agree with @hcarty one of the nice things and one of my favorite things about reason. Adding more syntax to differentiate type parameters isn't something I'm excited about.

I do admit that the parens get kind of overwhelming. Perhaps we can start by first eliminating all the obvious superfluous parens. That could at least get us partially there.
simple identifier lambda arguments:
/* Before */
List.map((itm) => item + 1, myList);
/* After */
List.map(itm => item + 1, myList);

first class modules:
/* Before */
type t = ((int, list((module X)))) => int;
/* After */
type t = ((int, list(module X))) => int;

Can anyone think of any other obvious improvements had by merely removing parens where they are not necessary at print time?

switch:
/* Before */
switch (f(x)) { ... }

/* After */
switch f(x) { ... }

if:
/* Before */
if (isWhack(x)) { ... }

/* After */
if isWhack(x) { ... }

(the same also applies for try)
record destructuring single lambda argument: (probably ambiguous in one way or another)
/* Before */
({ x, y }) => ...

/* After */
{ x, y } => ...

lambda type annotation (I also find this more intuitive)
/* Before */
(x: arg) => ...
x: ret => ...

/* After */
x: arg => ...
(x): ret => ...

I find tuples to be the worst offender by far, however, since I often use tuples with lambda functions and get abominations like List.filter(((x, y)) => ...), or even with ReasonReact <Foo> ...(((error, marks)) => ...) </Foo>. Unfortunately I know of no good solutions.

I think for Reason React, we can do:
{((error, marks)) => ...}

Which helps a bit. I don't know if it's preserved at print time.

thinking of type application as function application is a really nice idea

It is simply wrong to make such assumption, OCaml does not have it, let's not pretend OCaml have it. Actually it is more confusing. Take Hashtbl.t ('a,'b) for example,  would it be equivalent to Hashtbl.t ('a) ('b)? No!
This does not mean OCaml's type system is not expressive, OCaml has more advanced stuff compared with hkt, e.g, modules and we have a very nice encoding in the stdlib.
In my opinion, parens should be only used in two cases:

function/ function application

explicit group to resolve precedence issues, it is a buggy design if extra parens changes semantics.

I think list < module X> should parse without conflict

@bobzhang So you'd prefer that variant constructors used <> as well? They don't curry either. Given
type foo =
  | Mk_foo(int, int);

Mk_foo(0)(1) is also not valid. I don't think "not currying" is a valid argument against parentheses for type application - if anything, it's unexpected that function application with parentheses does curry.

@ubsan You example is also a good example of abusing parens, Mk_foo is not a function, let's not pretend it is a function.
type foo =
  | Mk_foo of  int , int

@bobzhang not every different semantic needs to have different syntax. Even if they might not be exactly the same, giving up the similitude of function application, variant construction, and type application syntax is a mistake, and, imo, a poor syntax decision.

not every different semantic needs to have different syntax

I agree with you. The thing is the two use cases of paren (listed above) is already pervasive, we should not use it in other places any more, the code is too hard to read otherwise

I still disagree that it's hard to read. In fact, I think it's substantially easier to read than <>

I think readability is a better argument than having syntax consistently hint towards semantics. Even the original OCaml used infix commas (w parens) to represent tuples as well as multiple arguments to variant constructors.
Here is a list of possible improvements we can make to reduce the number of parens. I'll list what I personally perceived to be the highest impact first. Order here has nothing to do with difficulty of design/implementation, only what I perceive to be the impact in reducing parens.

Remove clearly unnecessary parens. Things like
List.map((x) => ((y) => 0, 0), lst)
could be printed as
List.map(x => (y => 0, 0), lst)
Which is much cleaner. It's also a totally non-invasive change, merely done at print time.
Find another way to represent tuples that doesn't burn developers who liked the list syntax [x, y]. One suggestion, is to find a different separator for [ ] would distinguish tuples from lists. For example, [x . y] could represent tuples, while [x] still represents the list with one item, and [x, y] still represents a list with two items - this would represent no conflicts because there's no such thing as a tuple with exactly one item. If we can do some user studies that show this would work for people who don't yet use Reason as well as people that do, then this could be a nice way to clean up syntax. Please feel free to suggest other alternatives.
Consider <> for type parameters.

I propose that we go down this list, and at each stage reevaluate how important this is. We might find 80% of peoples' issues are solved just by the first improvement. Maybe we decide to go all the way to the end. The cool thing is that I believe all of the proposals in that list are non-breaking changes.

I've been considering semicolon as the separator, and think it'd be an improvement even if parentheses are kept, since it'd significantly help with (visually) distinguishing tuples from argument lists (or list literals if using []) while still being a natural (and therefore in itself more readable) item separator.
/* (a, b) */
type t = (int, option((int, int))) => int;
let f = ((a, b), x) => ...
let xs = [(a, b), (c, d)];

/* (a; b) */
type t = (int, option((int; int))) => int;
let f = ((a; b), x) => ...
let xs = [(a; b), (c; d)];

/* [a; b] */
type t = (int, option([int; int])) => int;
let f = ([a; b], x) => ...
let xs = [[a; b], [c; d]];

I wish it weren't the case, but I've never seen so much rage induced from a single ascii character than what I see in response to the ; character. It's also especially challenging for us because some have concluded that "Reason has more semicolons used for more purposes than OCaml" - which isn't the case either, and I'd hate to give more ammunition to that argument. Did you not like the . separator?

Hmm, I've not really noticed that rage, just a few people complaining about the semicolon as line/expresssion/statement terminator. I know some are volently opposed to semicolons in that role outside of just Reason, but I've not seen anyone complain about the character itself in other roles. I do see the problem with overloading of course, but that's also the problem we're trying to solve with regards to comma and parentheses, which IMO are much worse since those overloads intersect a lot more.
I don't particularly like the idea of . as separator perhaps, mostly because it reads more as a terminator than a separator. Or to a lesser degree as a "path" separator if used without whitespace. In terms of readabiility it would be a bit like replacing all the commas in a sentence with periods.
Compared to semicolon the overloading also seems more easily confused with other meanings:
/* record access */
let (x.y) = (a.b.c . d.e.f);

/* local open */
let x = Json.(Decode.int(a) . Decode.string(b));

/* universally quantified type variables */
let f : a b . (a . b) => a;

I really like the direction @jordwalke proposed. As for the new tuple syntax I dislike the . because it's very similar to , and I think this will hurt the readability (along with other arguments @glennsl listed). As for ; it just feels wrong for some reason, and I see how a lot of other people could feel like that too. Also I think most programmers are used to semicolon being terminator and not a separator, so that argument applies to ; too. To sum up I personally prefer ; over . as I think I could get used to the semicolon, but I agree that it might hurt adoptability.
/* [a ^ b] */
type t = (int, option([int ^ int])) => int;
let f = ([a ^ b], x) => ...
let xs = [[a ^ b], [c ^ d]];

The only conflict I am aware of is the current ref syntax. However I and a bunch of other people dislike the ^ for ref syntax so it might be worth changing that one to something else to allow room for this tuple syntac. I feel that it could work out quite nicely. (I'm personaly using myRef := 1 and myRef.contents for refs in my code currently, even though I used both versions of sugar in Reason 2). Overall my favorite option so far
/* <a, b> */
type t = (int, option(<int, int>)) => int;
let f = (<a, b>, x) => ...
let xs = [<a, b>, <c, d>];

This would conflict with the proposed type parameter syntax, but I still find it much nicer than (a; b) and (a . b)

I don't know why I like it so much better than <> for type parameters, but I quite like <> for tuples.

Just my 2cents but I believe that using <> for generics would be an improvement for Reason. This is the most popular syntax for it: Flow, TypeScript, Hack, C++, Java, C#, Dart, Kotlin, Swift... are all using <> for generics.
I believe that ocaml/reason generics behave much the same way as all those others from a type system point of view so it would make sense to use the same syntax.

Two more cases that print too many parens, thereby increasing paren fatigue.

https://github.com/facebook/reason/issues/1707
https://github.com/facebook/reason/issues/1711

Another thing that causes too many parens with a JS like syntax, is the fact that unit is also (). Normally that doesn't cause paren-fatigue, but one case I noticed it often does is in the final "unit" arg to a series of named arguments:
 style=(ReactDOMRe.Style.make(~color="#444444", ~fontSize="68px", ()))

Instead of changing the syntax for unit, I think we can actually change the syntax to automatically provide the final unit arg to any named argument series if there is no final non-named arg, and then allow a syntax to opt out of it.
This sounds heavy handed, but I actually think it could be a good idea in general because:

The missing final unit arg is a big surprise to new developers.
We still provide a way to express the old behavior - nothing is lost.
I believe that all labeled arg functions even without optionals should be providing some final non-named argument: Justification: so that you can later add optional labeled arguments, without having to add a final unit argument, and then update all the call sites. If you always include a final non-named argument for functions that have named args, you can add optional args without having to update any callers.
It helps reduce paren fatigue.

Omitting the final unit argument might become a major cause of confusion when used with functions (intuitively) returning 0-ary callbacks, e.g., does this just return a callback or does it also call it? That's a rather important distinction.
reduce(() => Increment(id))

Printing of immediately applied 0-ary callbacks also ought to be improved to better reflect intention. Not sure if doing the same with unit termination arguments is an improvement, but these use cases need to be considered together.
reduce(() => Increment(id), ())
style=(ReactDOMRe.Style.make(~color="#444444", ~fontSize="68px", ()))

/* vs */

reduce(() => Increment(id))()
style=(ReactDOMRe.Style.make(~color="#444444", ~fontSize="68px")())

Omitting the final unit argument might become a major cause of confusion when used with functions (intuitively) returning 0-ary callbacks, e.g., does this just return a callback or does it also call it? That's a rather important distinction.
reduce(() => Increment(id))

My proposal was to only provide a different syntax (that hides - not omits) the final unit arg in the case where there are named arguments already in place before it, and no other arguments after it.

Printing of immediately applied 0-ary callbacks also ought to be improved to better reflect intention. Not sure if doing the same with unit termination arguments is an improvement, but these use cases need to be considered together.

My justification for the named args syntax change was not truly motivated by reducing parens, but by making named args more intuitive with fewer foot-guns. It did have the benefit of reducing parens which is why I mentioned it in this issue.
The immediately invoked unit function might be another one worth special casing in my opinion. I don't think that the same thing we do for named args would apply in the case of immediately invoked unit functions, because the motivations were different. My motivations for named args improvements were to make the syntax more intuitive by default, and the motivation for immediately invoked unit functions is to preserve intention:
I think we could detect and print immediately invoked unit function as:
reduce(() => Increment(id))()

(Have you seen a lot of these immediately invoked unit args in practice? I admit I haven't).

My proposal was to only provide a different syntax (that hides - not omits) the final unit arg in the case where there are named arguments already in place before it, and no other arguments after it.
That could still easily (though perhaps not very likely) intersect with immediately invoked unit funcitons, for example:

reduce(~f=() => Increment(id))

Have you seen a lot of these immediately invoked unit args in practice? I admit I haven't.
It's a pretty frequent pattern with ReasonReact reducers, which the example was meant to allude to.

I understand and agree with your motivation for hiding the unit termination argument. I'm just worried that it might not be possible to properly distinguish it from other meanings of a final unit argument and thereby lead to confusion.

We could make a separate issue to discuss the proposal but you do bring up a good point. I believe the concern is addressed by something I didn’t mention yet : that the transformation also occurs at the definition of any function with named args. That symmetry seems to help solve the problem in your specific example.

Just saw this issue and would like to add my 2 cents. I'm a beginner trying to make sense of the reason-react binding. I think one of the biggest issue with reading the code is the parens. Half of the time I don't know whether I'm reading a parameterized type or function. I am slowly getting used to it. But I think for beginners, making a distinction between types and values would make code clearer. In addition, as @bobzhang alluded to (and from my reading), Ocaml doesn't have HKT and more fundamentally, Ocaml has very different semantics for these 2 worlds. So perhaps reason's syntax should "embrace" this fact and make them more separate rather than trying to unify something that are just different.


AutomationElement.Findall() not working

Hello,
I'm using FlaUI to perform end to end testing. Now I have an issue where I have like multiple automation elements with the same ID. I want to find those. I have the following lime of code:
var condition = new ConditionFactory(_automation.PropertyLibrary); var list = windowElement.FindAll(global::FlaUI.Core.Definitions.TreeScope.Parent, condition.ByAutomationId(id));
WindowElement is here a tab but I think this is no problem. The element is normally in that tab. When I run it, the array is always empty. I also played with the Treescope values but no results.
In FlaUIInspect tool I can see the requested element. But the code gives me back another value. If I understand the code of the tested application, than there is an object which has a view connected to it. But I have two objects of the same type in the application active so also two views. Only the view of the selected object is visible in FlaUIInspect. Using FindFirstDescendant() works fine but that gives me the wrong element.
So who can help me with this issue?

I found that FindAllDescendants() also works. So this issue can be closed.


Pururin has been seized. Please pull from extension repo

Source name
Pururin
Source language
English
Source link
pururin.io
Other details
verified here https://www.reddit.com/r/animepiracy/comments/1g17n39/pururin_is_now_gone/ and https://boards.4chan.org/h/thread/8251046/pururin-is-seized
Acknowledgements

[X] I have updated all installed extensions.
[X] I have opened WebView and checked that the source website is down.
[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a meaningful title with the source name.
[X] I will fill out all of the requested information in this form.

Add a :+1: reaction to issues you find important.

It seems to be working fine on my end. Try switching networks, use a VPN, or maybe adjust your user-agent if needed.

OK that is a new domain now let's hope that is not a honeypot and is really them.  As their is many images of Pururin.io has been seized with the actual seizure domain name servers.
Here is from a month ago.
Domain: pururin.to
Created on: Fri Apr 30 20:39:50 2021
Last edited on: Thu Oct 10 09:06:17 2024
Expires on: Sun Jun 29 15:16:52 2025
Primary host add: None
Primary host name: ns1.seizedservers.com
Secondary host add: None
Secondary host name: ns2.seizedservers.com
Than a day later we have this...
Expires On: 2025-01-16
Updated On: 2024-10-11
Status:
clientTransferProhibited
Name Servers:
ns1.abelons.com
ns2.abelons.com
ns3.abelons.com
for now I think I will avoid this site until confirmation comes down.  the seizedservers.com are government seized servers domain name servers.  Pretty strange it changes to new domain servers day later.

The new domain was taken from their discord, it should be legit.

Closing as answered/not an issue


Update SDK to v13

It's that time again where the SDK had a version bump from v12 to v13. The main reason for the increase was the possible breaking changes due to adding support for reading/updating extensions in the SDK (came with directus release v10.7.0). Therewith I don't think this module needs any changes, as but haven't tested it yet.
Apart from that, these are the changes that could have an impact on the module:

Type-Fixes
New Asset functions (probably unimportant, as the module doesn't includes a full function-map either)

Whole changelog
Do you want me to open a PR, or will you check / test it yourself? :)
Thanks as always!

Thanks for keeping this module in sync with the latest SDK updates, really appreciated :)
If you can open a PR, that would be very helpful 🙏


Issues panel

Hi,
Would it be possible to add "Issues" panel/box, in a similar way that we have "Jobs," etc.  Nothing special, just dump there the current issues like failed plots, collisions, "Waiting on Temp" folder, etc. Just add time stamp when it happened.  That's it.
By the way, on those failed plots, maybe it would be good to add the cause (e.g., whether it was a user action or an unknown event).
I would not spend much time on polishing it, as the intention is to get some help, and potentially fix those issues, so the goal is that we will not see any issues there at some point.
Thank you, Jacek

I really like this idea. The logging definitely needs much improvement and it would be good an event log page/panel.


Working from branches on this repo creates confusion

We should prioritize closing branches ASAP or working only from forks to open PRs on this repo. Our instructions require folks copy all branches with the template (to get gh-pages) and then they end up with these GitHub notifications. Julia's branch was stale from an old PR, so I went ahead and deleted it. The @brian-rose branch tied to #174 has been around for a while and is in open discussion. I might recommend moving that branch to your fork or us pushing forward to resolve that issue more quickly. I'll tie this issue to that PR, but we should make an effort to avoid this in the future as well.

@dcamron good point, I think these branches get created when I do a quick "one-off" edit on GitHub but I see that it creates confusion.
I'm not sure how to move an existing branch to my personal fork and preserve the discussion on the open PR. I'll look it up.


Ensure Container-Optimized OS (cos) is used for Kubernetes Engine Clusters Node image

Possible check to target the following resource

[ ] google_container_node_pool

closing, tracking in spreadsheet


TypeError: 'NoneType' object is not subscriptable

Hi, I keep getting an error "TypeError: 'NoneType' object is not subscriptable" when I try to run face embed distance on the nightly version of ComfyUI. The stable version works fine, but I wanted to know if you could do something to help me fix this error. BTW: I need it to work on nightly because of WD14 tagger. It stopped working on my stable version. (doesn't like my CUDA for some reason)
Loading 1 new model.txt
the log in txt file

it seems to be a problem with the overlay, if you disable it, it should work. You can check the actual values from the console. not ideal but it's something to unlock your workflow

thanks. It works... No distance or value, but it's fine.


Update index.md

Added text "The left and right subtree each must also be a binary search tree."

[x] I have read freeCodeCamp's contribution guidelines.
[ ] My pull request has a descriptive title (not a vague title like Update index.md)
[ ] My pull request targets the master branch of freeCodeCamp.
[ ] None of my changes are plagiarized from another source without proper attribution.
[ ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Hi,
Thanks for this pull request (PR).
Unfortunately, we are closing this PR, because we do not believe it adds a significant improvement.
Feel free to submit another PR though.
Thank you