Fantasy Land proposal process for ECMAScript

I'm proposing the fantasy-land community contributes more actively in the ECMAScript language design process.  There's been some discussion on gitter, and we have at least 1 proposal idea.
I think it would be good to get a sense of what the process is, so if anyone has any suggestions please say so!
@davidchambers suggested @michaelficarra as a potential ally.  I'd like to get @mindeavor's input as well with his experience proposing https://github.com/mindeavor/es-pipeline-operator
A candidate for our first proposal is https://github.com/fantasyland/function-prototype-map suggested by @puffnfresh

One administrative thing worth sorting out.  Where should proposals be discussed.  Should we have a separate repo on fantasy-land to namespace these discussions?  Interested in your thoughts on that @rpominov as you seemed hesitant in gitter.

Where should proposals be discussed? Should we have a separate repo on fantasy-land to namespace these discussions?

Yes please.

Maybe we should crete some placeholder repo like https://github.com/jsforum/jsforum for all general discussions that are not related to any particular repository? Something like fantasyland/forum.

But meanwhile and before I forgot I'd like to mention here another language feature, that potentially could make into a good proposal.
A special syntax for partial application of a function:
foo#(a, b) // desugars roughly to foo.bind(null, a, b)

Using this and pipe operator we could write code like this:
[1, 2]
 |> List.map#(x => x + 1)
 |> List.chain#(x => [x, x]) // [2, 2, 3, 3]

That a smart enough compiler could desugar to:
List.chain(x => [x, x], List.map(x => x + 1, [1, 2]))

@rpominov Adding # as syntax will be a rough and uphill battle. It's hard convincing to add papp to Function.prototype.
[1, 2]
  |> List.map.papp(x => x + 1)
  |> List.chain.papp(x => [x, x]) // [2, 2, 3, 3]

@JAForbes Re experience: You need a TC39 champion to be interested in your proposal to move it forward at all. Take note that they're all heavily biased towards OOP, so FP features, even a simple one as the pipeline operator, will likely be seen as "bloat" or "unnecessary" (unlike classes and their bundle of supporting features, apparently).

@rpominov u can write some plugin for babel. For example https://www.sitepoint.com/understanding-asts-building-babel-plugin/

btw we can do so something like this using es6 template literals:
_([10, 11]))`
  |> ${a => [a + 1]}
  >>= (
    |> ${a => a * 2}
    |> ${a => [a, a - 1]}
  )
` // [22, 21, 24, 23]

Adding # as syntax will be a rough and uphill battle. It's hard enough convincing to add papp to Function.prototype.

Sad to hear that. Function.prototype.papp proposal looks great, btw!

Take note that they're all heavily biased towards OOP, so FP features, even a simple one

This is also very sad, although I've suspected this. Seems like general attitude haven't changed that much since https://github.com/promises-aplus/promises-spec/issues/94 .
Very curious about @michaelficarra's perspective, hopefully it's not so bad.

@rpominov @safareli As you remember bilby http://bilby.brianmckenna.org/#do-operator-overloading

@mindeavor thanks for the info!  That's very helpful.

I'm going to say a few blunt harsh truths I think we need to internalise if we are going to have any success.
We are walking into a world where OO is king, Haskell is a symbol for the programming elite, and profit matters.
We need to acknowledge some hard truths, Javascript's history is political, born out of a corporate war, designed in 10 days as a result.  Large corporate entities vie for control of the web and they all have their own particular slant.  "Anyone can be a part of TC39" as long as your company is willing to pay a fee.
Look at the list of members: http://tc39wiki.calculist.org/about/people/ the overwhelming voice in the committee are large corporate entities that want to make their particular vision of the web happen.
Its not a democracy, its an oligarchy, we need to admit that up front if we are going to come up with a strategy that makes any difference at all.
We need to figure out up front, what our goals are, what the obstacles are, and how do we communicate those goals.  Our changes need to be in the committees interests, in other words they need to save corporations money, or make corporations money.
As for ESDiscuss, I'm not sure what role that mailing list plays, but from the threads I've read, getting a receptive response relies on the readership to understand what the feature is and why it is beneficial.
I think we'll hit a wall if we get too abstract here, if we get bogged down in theory or elegance.  We need to talk about why a given feature will lead to less bugs, or less code, or simplify implementations of well known libraries.  We need to relate our proposals back to the mainstream e.g. how would this feature be used in a React app?  And we need to assume absolutely 0 knowledge or appreciation of functional programming - in fact it is probably safer to presume antagonism.
Its easy to get defensive, but that won't help us change the language.  We need to be calm and patient and ultimately we will need to suffer ignorance graciously.  We need to make our case on their terms because at this point we need them and they don't need us.
We have to keep in mind, we are not trying to convince tc39 that FP is the right direction, we are trying to save millions of JS developers time by giving them access to a better set of tools.
We need to lean on the goodwill of the subset of FP that OO people like (Rx/Observables, linq, Elm, F# and React, FlowType/TS).  We need to tread lightly referencing Haskell, ML, Categories, Monads etc.  We can't start there.  We have to be realistic of the terrain.  Let's try and get one proposal into the language to prove the value of our counsel, to dispel the myth that FP has no real benefits, that it is all "theoretical, ivory tower, academic nonsense".  I know that is the prevailing perspective, we've all seen it I'm sure.
I know how hard that it is to hear, but we know better.  It is on our shoulders to communicate the value downstream.
I think we need to stop talking about libraries/transpilers/hacks to make JS better.  We are a community who deserves a voice in the process but to date our default reaction is to write a new language, or create a library etc.
Those reactions are all valid and worthy and should be continued.  But we need to also direct our collective force at the web platform itself.  I think it will be hard, I think we'll need to form a careful strategy, but so many JS users will benefit if our counsel is heard.
Evan Czaplicki's "Let's be Mainstream" talk comes to mind.
I also say this with absolute deference to the knowledge of this community.  I know I have a lot to learn about FP, that I am in no way an expert in this field.  But I do feel I am a bridge between this world and the other, I can see their connotations and I can empathise with them.
So let's come up with a list of proposals, discuss the pro's / cons of each proposal and different strategies.  Maybe we want to put all our weight in one proposal, or maybe its better to hit them with many proposals simultaneously?  Let's study previous successes and previous failures and learn from them.  But let's not embark on a war of principles, let's not attempt to convert the JS community to "see the light" - that will never work, we need to identify our goals and guide our interactions with the committee to achieve those goals, nothing more.

I've got some input from @isiahmeadows re: es-discuss.  You can subscribe to the mailing list here:
https://mail.mozilla.org/listinfo/es-discuss
And you can make proposals by posting an email to<EMAIL_ADDRESS> The goal is to convince a member of tc39 to become a "champion" of your feature, which then moves your proposal to stage 0.
I don't think we should make any proposals yet, but that's just my view on it.  But I'm going to subscribe and get a sense of the climate.  Also turns out there is already a proposal for a composition operator in the mailing list: https://esdiscuss.org/topic/function-composition-syntax which might be of interest.
Here are some notes on contributing to ECMAScript
https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md

Note: at the bottom of that email thread about function composition, here's my gist strawman for it. I'd definitely take suggestions on how to improve upon it. If we come up with something worth adding, that would still work within the confines of the language, this would be wonderful.

Here's what I'm thinking:

Standardize a basic set of protocols based on a subset of the basic algebras here. Let's not add the full package yet, but we can maybe round it out later:

Setoid (equals)
Semigroup (concat)
Monoid (Semigroup + empty)
Functor (map)
Apply (Functor + ap)
Applicative (Apply + constructor.of)
Chain (Apply + chain)
Monad (Applicative + Chain)
Bifunctor (Functor + bimap)

(Why include so little? Consider Promises, iterables, etc.: it's much easier to flesh out known, commonly implemented semantics. Most Promise implementations were ES6-compatible from the start, for example.)

Propose that several existing types implement these protocols:

All primitive types (including boxed types) except null/undefined implement Setoid
Objects implement nothing
Functions implement Monad
Symbols implement Monad and Setoid
Arrays, TypedArrays, Maps, and Sets implement Monad, Monoid, and Setoid
WeakMaps and WeakSets implement nothing
%IteratorPrototype% implements Functor
Promises implement Monad and Bifunctor (return on right)
Proposal-wise: %AsyncIteratorPrototype% implements Functor, etc.

Note that equals on collections works recursively, and that iterator.map(f)'s return value's prototype is %IteratorPrototype%.

Push for the bind operator proposal (or some other pipelining operator) to gain better traction and increased priority.

Propose a few new classes:

Option or Maybe, implements Thenable (with coercion, undefined error), Monad and Setoid (either one works)
right-biased Either, implements Thenable (flipped, with coercion to right), Monad, Bifunctor, and Setoid
return-biased Try, implements Thenable (with coercion), Monad, Bifunctor, and Setoid (for safer exception handling)

We should allow methods to accept arguments beyond what each protocol requires in the proposal itself, since some types with existing correct methods (like Array with Array.of, array.concat, etc.) accept more parameters than necessary.
As for polyfills for steps 2 and 4, I suspect it'd be extraordinarily straightforward to do. Promises will require a boilerplate object to prevent coercion with map/etc., but that's about the end of it. Note that the invariants of callbacks (e.g. matching prototypes for map) are checked, though, and failure is an immediate synchronous TypeError, or synchronous rejection in the case of Promises.
Note that those that implement Bifunctor also implement Thenable, with the arguments in reverse order and with coercion (like what Promises do today).

Oh, and with these, JS might start feeling a little like a lighter, more dynamic Scala.

For the record, here's the discussion on the pipeline op: https://esdiscuss.org/topic/the-pipeline-operator-making-multiple-function-calls-look-great

@isiahmeadows that is a lot more ambitious than I would have expected we could be.  But you do have a lot more experience in these matters.
Few questions:

why does Object implement nothing, is that a performance concern?
Do you think pushing for bind would help our cause in the future, or hinder it?  I don't think many here are in favour of bind syntax (correct me if I'm wrong).  Would getting bind into the language create the impression they've already catered to the FP community so pushing for compose/map/pipe would be harder?  Or do you think just getting one proposal through the door would help future proposals?
Why would synchronous types like Option implement thenable?  That seems counter to the principle of Promises always be async, also I think this community would prefer map.
Do you think we'd gain more traction if chain was renamed to flatMap when proposing monads?
Do you think we should use terms like Monad/Setoid in esdiscuss?  I'm worried it will create the impression that this feature is not useful for most people.  But maybe its better to bite the bullet use the correct terms and just be gracious when introducing concepts and provide lots of examples?  I hope for the latter I'm just concerned A+ will happen again.

Thanks @mindeavor

@SimonRichardson also I can't act on your request I'm not a member.

Hey, everyone. Thanks for the mention. I think I can help out a bit here.
I think there have been some mischaracterisations of TC39 as a whole. TC39 has many members, and the representatives that participate have very diverse backgrounds and goals. It would be wrong to try to label the entire group as "anti-FP" or really subscribing to any sort of unified philosophy.
I also don't think that proposals of individual prototype methods are the best way for this community to get started contributing. And I know that the committee would never pull in the entire Fantasy Land protocol wholesale. Every proposal that the committee works on is motivated by real world usage, often already proven out by successful libraries/frameworks or implemented in compile-to-JS languages. So I think two strategies should be taken: build out as much of what you want to see in libraries/frameworks/languages (done here already; good job!) and propose features that will allow you to do more of this prototyping yourselves without involvement from the language authors. Let me give an example.
A few months ago, I prototyped the definition of algebraic interfaces if we were given a kind of "mixin" or "interface implementation" syntax on top of classes. I defined a couple of "type classes" which define their protocol using static symbols (to permanently avoid name collision), then use a new with syntax to extend or implement that interface. Now if I fudged the new syntax bits into some function calls (or just used sweet.js macros), I could get this working today as-is. And that would show that this feature has a real use case. And then, once it is in the language, that feature could be used to create an even more easily implementable and even better "standard protocol" like Fantasy Land. Once it gains enough traction, it would be a no-brainer for the committee to include something like it in the language.
So, at least in my opinion, this won't all happen at once. We need to take a bunch of small steps in a direction that will inevitably lead to the place we actually want to be. Push for an interface-like feature or macros to help in proving out prototypes. Symbols were a big win and we didn't even know it!
I love this community and this effort (I have implemented it in some of my own projects), so feel free to lean on me for advice regarding the TC39 process or to champion a proposal.

@michaelficarra Thank you for the advice.  There are a lot of helpful insights there that I think we can act upon.  I apologise for mis-characterising the committee themselves.  My previous comment is really addressing systems and structures.  I'm not assuming the members themselves have some ill intentions.  That's some advice we can act upon productively.
This is probably a discussion for another time and another place - but I do think a lot of the criticisms and frustrations that are directed at the process are valid, and it would be disingenuous for me to pretend otherwise.  Things have definitely improved, discussions are in the open, and are informed by the community.  But there is a corporate story there, and whether or not it is intentional (I'm sure it isn't) there is an identifiable power imbalance.  But I have no malice toward anyone, its all just people at the end of the day and its a hard thankless job.
It would be great if there was a process for iterating on the process and not just the language.
It seems there are already a lot of functional proposals in the mix, maybe a productive avenue for us is to research the existing proposals and see if they are something our community can get behind, and if not we can debate possible amendments to those proposals and add those amendments to the esdiscuss thread.
Maybe that is a good first step.

I'm surprised Traversable wasn't in that list.

You can get Functor from it, plus all things you can derive from Functor.
You can get Foldable from it, plus all things you can derive from Foldable.
There are a ton of data types that can implement it.
There are additional things it provides on its own, like scan.
It's a small step away from the van Laarhoven lens hierarchy.
You could technically derive it automatically instead of by hand.

@SimonRichardson also I can't act on your request I'm not a member.

That can be arranged 😛

@SimonRichardson @rpominov So which way should we go?  A repo for tc39 discussions, or a general forum repo for discussions not directly related to any particular project?

One point for a general repo is discoverability. For example say we an issue discussing creation of a new library there, someone comes to that issue from a link and then finds discussions about ES proposals in other issues in same repo.
But I guess either way is good anyway.

@JAForbes Sorry for the late response, but in reply to this comment:

why does Object implement nothing, is that a performance concern?

Practical concern. You could argue for equals being this === other by default, but it wouldn't make sense for it to implement the rest, like, say, map or concat. Otherwise, they'd bleed into other types like functions (which shouldn't implement concat) or strings (which shouldn't implement map).

Do you think pushing for bind would help our cause in the future, or hinder it? I don't think many here are in favour of bind syntax (correct me if I'm wrong). Would getting bind into the language create the impression they've already catered to the FP community so pushing for compose/map/pipe would be harder? Or do you think just getting one proposal through the door would help future proposals?

Why would synchronous types like Option implement thenable? That seems counter to the principle of Promises always be async, also I think this community would prefer map.

This was initially for compatibility with Promises, but it'd be mostly useful for those who want auto-absorption semantics (like what exist with Promises). Admittedly, when I write Option types, I myself include absorption just to simplify the implementation and avoid boilerplate.

Do you think we'd gain more traction if chain was renamed to flatMap when proposing monads?

Yes, and IMHO that would be preferable. chain is a little odd compared to, say, Java's Stream.flatMap or Rx.js's Observable.prototype.flatMap.

Do you think we should use terms like Monad/Setoid in esdiscuss? I'm worried it will create the impression that this feature is not useful for most people. But maybe its better to bite the bullet use the correct terms and just be gracious when introducing concepts and provide lots of examples? I hope for the latter I'm just concerned A+ will happen again.

It might be better to use them (e.g. the term "monad" is starting to become better understood by those less versed in type theory), but with a thorough explanation of how each distinct concept works, why they are distinct concepts (e.g. tuples are applys that aren't applicatives, strings are monoids that aren't monads, among others), and how they relate to OO idioms. I'll note that monads will be easy (they're already using them), but applies that aren't applicatives may be a little harder.
I do suspect names might change as time goes on, mainly because the OO and FP communities don't use the same terminology. What we call monads, they call object wrappers. What we call comonads, they call builders and factories. What we call most monadic monoids, they call collections. Oh, and don't forget the similaries between SQL and FP. It's pretty obvious when you consider the F# version here as a direct translation of the SQL, just using immutable sequences instead:
-- SQL
SELECT Foo.One, Bar.Two FROM Foo
    INNER JOIN Bar ON Foo.Id = Bar.FooId
    WHERE Foo.Total < 100
    SORT BY Bar.Name ASC;

// F# equivalent
fooList
|> Seq.collect (fun foo ->
    barList
    |> Seq.filter (fun bar -> bar.FooId = foo.Id)
    |> Seq.map (fun bar -> (foo, bar))
|> Seq.filter (fun foo -> foo.Total < 100)
|> Seq.sortBy (fun (_, bar) -> bar.Name)
|> Seq.map (fun (foo, bar) -> (foo.One, bar.Two))

@JAForbes

[...] that is a lot more ambitious than I would have expected we could be.

You can't exactly expect to get anywhere without at least a hint of idealism. :wink:
And this is merely adding a bunch of easy-to-polyfill methods initially.

I was just thinking that, in the end, this may be better done with decorators and similar instead. Things like this:
@Functor
class Foo {
    map(f) {}
}

@Monad
class Bar {
    chain(f) {}
    static of(x) {}
}

// etc.

Decorators could fill in all the derivations as well. So, instead of having to implement everything, all you would actually need to implement for a basic List or Promise would be this:
@Monad
@Monoid
@Traversable
class List {
    static of() {}
    static empty() {}
    equals(other) {}
    concat(other) {}
    chain(other) {}
    traverse(f, T) {}

    // Derived:
    // map(f) {}
    // ap(f) {}
    // reduce(f, acc) {}
}

Furthermore, chainRec could be easily derived from any chain with a general function like this, mod the stack space requirement:
const result = done => value => ({done, value})
function chainRec(f, acc) {
    const {done, value} = f(result(false), result(true), acc)
    return done ? value : value.chain(v => chainRec(f, v))
}

It won't be trivial to both avoid blowing the stack and generalizing for both sync and async chains, but pull-stream's drain implementation would be highly informative in this area (they also have to deal with maybe-sync, maybe-async). IMHO, that belongs in Ramda/etc., not here. But I'll stop before this gets too off-topic.

@rpominov @SimonRichardson could either of you create the discussion repo?  I don't have sufficient permissions.

Here you go https://github.com/fantasyland/ECMAScript-proposals

Thank you @rpominov

Just to note, defining composition operator in a language would open opportunity for VMs to optimize stack usage when running composition of many functions without need to do it manually this way

@safareli great point.
I was hoping VMs could inline a lot of functions as well if the compositions are static.

@JAForbes Hell yeah for this. Some concepts from Promises/A+ are starting to get baked into the language syntax, duck typing and all, and I feel some design decisions are not being sufficiently contested and hashed out. Ironically, some of the problems (e.g. in https://github.com/tc39/proposal-async-iteration) directly stem from issues where input from the fantasy-land community was dismissed as, well, "fantasy land" suggestions:

Confusion over implicit wrapping and unwrapping of promises would not be such a problem if flatMap and map had not been conflated
A perfectly synchronized dance between stateful async iterators and their consumers would not be necessary if a separation between describing the computation and initiating it had been maintained

@masaeedu

Some concepts from Promises/A+ are starting to get baked into the language syntax, duck typing and all, and I feel some design decisions are not being sufficiently contested and hashed out.

I agree they weren't all thought through the best (the iterator protocol isn't particularly elegant), but I disagree about the specific argument with Promises/A+ - the thenable interface has been de-facto standardized in Promise libraries as an interop point since around when Angular was even a thing - jQuery adopted Promises/A+ interop, with absorption semantics, when version 2 was first released. So it's been around for quite a while, including the absorption semantics.
And in general in my experience, absorption makes Promise handling way easier, since I only need to care about "am I doing something asynchronous" rather than "did the caller make this asynchronous".
As for standardization points, I feel that there are some things that could be done to improve the lives of functional JS programmers, such as native Option, Try, and Either types (think of Scala's analogues) and some form of conditional pattern matching. You don't need to specifically assist any particular standard, and keep in mind, there's also the Static Land spec and lodash/fp, so they aren't likely to cater to any individual community without first consulting and identifying how it could help others.

@isiahmeadows The recursive flattening that Promises/A+ performs is a useful way of interoperating between the large constellation of promise libraries that have arisen for historical reasons. This doesn't mean then and its recursive flattening are a good abstraction to introduce directly into language constructs.
As a specification for libraries, or even as a class available in the standard library, I'm fine with how Promises behave. However things like await should operate on a more general abstraction than Promises, as is the case in other languages. The fact that a nested promises are reserved as an interoperability concept is baggage associated solely with promises, and should not affect how async functions and async iterators are specified.

If there were a JS type system that was expressive enough, I'm sure we'd gladly switch to it.

What about reasonML? It's ML family, not really just type system but familiar with javascript syntax.
https://reasonml.github.io

@dfdgsdfg I'll note that the ML family does not have type classes - it works more like Static Land than Fantasy Land.

Here is something I'd like to see in JS and would like to get feedback on. This is basically a do-notation like syntax and a generalization of existing async/await syntax (actually, I think this is how it should have been implemented in the first place).
// Number -> Maybe String
const findFullName = chain (id_) => {
  const { firstName, lastName } = from S.find(({ id }) => id === id_, users);
  return `${firstName} ${lastName}`;
};

findFullName(2);
// -> Just('Bob Marley')

findFullName(3);
// -> Nothing

The above function declaration would be equivalent to calling .chain.
More examples: https://github.com/futpib/es-monadic-chain
What do you think?


Package request: nicstat

Project description
nicstat is a tool similar to iostat, but for network interfaces.
Originally written by Brendan Gregg for Solaris. Ported to Linux by Tim Cook.
Metadata

homepage URL: https://nicstat.sourceforge.io/
source URL: https://github.com/scotte/nicstat (There may be better-suited sources. This one's been updated after the SourceForge version.)
license: Artistic License 2.0
platforms: Linux

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

Re: Brendan Gregg presenting about nicstat

Hey. I remember this tool from Solaris so gave it a shot.
I don't want to PR and maintain this myself so here's the code. Feel free to go through the process of submitting it yourself if you so desire.
{ lib
, stdenv
, fetchFromGitHub
}:

stdenv.mkDerivation rec {
  pname = "nicstat";
  version = "unstable-2018-05-09";

  src = fetchFromGitHub {
    owner = "scotte";
    repo = "nicstat";
    rev = "1fbe28198b49a2062b0c928554f93db33cb288c3";
    hash = "sha256-7+11K9636dGeW0HaaH6OJF5Wy4CXYXfoaZOVfhHK6kg=";
  };

  buildPhase = ''
    runHook preBuild

    $CC -O2 nicstat.c -o nicstat

    runHook postBuild
  '';

  installPhase = ''
    runHook preInstall

    install -d "$out/bin"
    install -m 755 nicstat "$out/bin"

    install -d "$out/share/man/man1"
    install -m 644 nicstat.1 "$out/share/man/man1"

    runHook postInstall
  '';

  meta = with lib; {
    description = "Network traffic statistics utility for Solaris and Linux";
    homepage = "https://github.com/scotte/nicstat";
    changelog = "https://github.com/scotte/nicstat/blob/${src.rev}/ChangeLog.txt";
    license = licenses.artistic2;
    maintainers = with maintainers; [ ];
    mainProgram = "nicstat";
    platforms = platforms.all;
  };
}

Ok. I added you as a maintainer.


[INTERPRETER] Use acc's dtype as computation dtype in tl.dot

I found with TRITON_INTERPRET=1, tl.dot almost always gives wrong result for INT8 input, due to np.matmul use inputs' dtype as result dtype by default:
>>> a = np.array([[10, 20]], np.int8)
>>> np.matmul(a, a.transpose())
array([[-12]], dtype=int8)
>>> np.matmul(a, a.transpose(), dtype=np.int32)
array([[500]])

Yes, please add a test case

Done. It seems related test cases were deliberately skipped due to this deficiency.

Side note: I found a 3xtf32 vs tf32x3 mismatch when running related tests on my end:
https://github.com/openai/triton/blob/c9800840489fbe04619ad2d4e0e46b868c589d48/python/triton/runtime/interpreter.py#L73
https://github.com/openai/triton/blob/c9800840489fbe04619ad2d4e0e46b868c589d48/python/test/unit/language/test_core.py#L2919
Both are from commit https://github.com/openai/triton/commit/47a35b6ead3f897686991fadd23690c1cd7dd68f, not sure why this was not caught by CI.

allowed_dot_input_precisions

It doesn't quite matter. allowed_dot_input_precisions is just a placeholder, not used

allowed_dot_input_precisions free feel to fix the typo in this PR directly. Maybe the name was changed.


Any plan to implement an express server ?

Did you think about using express in server.js to make this generator production ready ?

Yes, in fact I did. But not in this generator. I wanted to build a generator on top of this generator that adds express and graphql into the mix.

Would be nice !

Closing this down. You can follow me if you'd like, then you'll get updated as soon as I release this.

for sure :)


Renames near.gitignore to .gitignore during project creation

Note: I'd like some guidance with folks familiar with publishing this to npm. I'm not aware of how to "test" this yet without publishing.
From my understanding (see links below) the .gitignore files we have created are not being created when using the generator commands like npx create-near-app….
This is not good as end users may accidentally commit sensitive info, like in the neardev directory.
For context, here's two links discussing the missing .gitignore files in folks' generators.
https://github.com/npm/npm/issues/1862
https://github.com/npm/npm/issues/3763
Reading through those, there's discussion of adding a .npmignore file, but I don't think those threads are on track with our issue here.
My solution here is to add a new file, near.gitignore that will not be omitted during the process of publishing to npm. Then in the package.json files under the scripts key adding postinstall and simply renaming it after the npm install. (rename near.gitignore to .gitignore)
Then when it comes to our own development, we'd like a normal .gitignore file, so I've created a symlink (.gitignore » near.gitignore) so we don't have to maintain two of those files.

While I couldn't test the npx command, I did locally remove the node_modules directory and npm i and see that this works, and that git uses the symlink like I hoped it would.

@mikedotexe I think the easiest solution is just name file differently in repo (e.g. gitignore without dot) and then rename it when copying files to create new project (somewhere here https://github.com/nearprotocol/create-near-app/blob/master/index.js#L28)
Symlinks won't work on Windows I think and aren't very critical as generally there shouldn't be keys created inside of templates folders when developing this project.

@mikedotexe I think the easiest solution is just name file differently in repo (e.g. gitignore without dot) and then rename it when copying files to create new project (somewhere here https://github.com/nearprotocol/create-near-app/blob/master/index.js#L28)
Symlinks won't work on Windows I think and aren't very critical as generally there shouldn't be keys created inside of templates folders when developing this project.

I like this approach. Thanks for pointing me to that function, @vgrichina. I just pushed up that change. This PR is ready for a re-review

@amgando noticed this issue here as well. https://github.com/nearprotocol/create-near-app/issues/99
Bump on this topic.
Travis is acting up and that's why it looks like it's failed:
FetchError: request to http://shared-test.nearprotocol.com:3030/ failed, reason: socket hang up

This is good to go if tests are not passing simply due to flakiness as mentioned. I would re-run trying to make sure that's the case, then merge away.


Support to select2 ajax

fix error

option 'ajax' is not allowed for Select2 when attached to a <select> element

Sorry, I don't understand this.
This shows ajax being used with a  https://select2.org/data-sources/ajax

I think is this an issue for versions of Select2 before version 4.
Thanks but I don't think I want to merge this. All the examples for Select2 v4 use . I think we might have to accept that we only support Select2 v4 moving forward.
https://select2.org/getting-started/basic-usage

This should definitely not be merged. It wouldn't only add compatibility issues, but even remove functionality.

I'm all for closing this. If anyone really needs to support select <4.0, they will simply have to extend the .select2entity() function themselves.


Allowed DAG branches to be taken lazily

@etrain @shivaram
This is key for hyperparameter tuning, checkpointing, lazy block solvers, etc.

Can you think of a good way to test these changes for surprising behavior? Either via a unit test or a few end-to-end things?

I could write a unit test that manually constructs a DAG and executes it, making sure it doesn't execute stuff that weren't requested yet (to ensure lazyness)

LGTM - merging this. We are going to want to run the integration tests on this before too long.


Plug & Play kit?

Not an issue, but a question from a fellow Dutchy.
I'd love to have this unit in my PC09ST unit(s), so it's not dependent on an internet connection to control it via Home Assistant.
Would it in any way be possible to order a 'plug & play' kit via @JanM321?
So it would just be a matter of connecting the ESP to the unit & my wifi and go from there.

Would it in any way be possible to order a 'plug & play' kit via @JanM321?

No I'm not offering this, but sometimes people have spare PCBs available. See some of the recent issues.


Azure CLI antlr4 error

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az vm list
Errors:
No module named 'antlr4'
Traceback (most recent call last):
lib/python3/dist-packages/knack/cli.py, ln 206, in invoke
    cmd_result = self.invocation.execute(args)
azure/cli/core/commands/__init__.py, ln 528, in execute
    self.commands_loader.load_arguments(command)
dist-packages/azure/cli/core/__init__.py, ln 300, in load_arguments
    loader.load_arguments(command)  # this adds entries to the argument registries
azure/cli/command_modules/vm/__init__.py, ln 31, in load_arguments
    from azure.cli.command_modules.vm._params import load_arguments
azure/cli/command_modules/vm/_params.py, ln 31, in <module>
    from azure.cli.command_modules.monitor.actions import get_period_type
azure/cli/command_modules/monitor/actions.py, ln 7, in <module>
    import antlr4
ModuleNotFoundError: No module named 'antlr4'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az vm list

Expected Behavior
Environment Summary
Linux-5.4.0-kali3-amd64-x86_64-with-debian-kali-rolling
Python 3.7.6
Shell: bash

azure-cli 2.0.81 *

Extensions:
azure-devops 0.17.0

Additional Context

@qwordy please take a look.

I haven't seen this error before. It's a ModuleNotFoundError. How do you installed Azure CLI?

@Kamusta any update?

Hi Sorry this was installed on kali using this command "pip3 install --upgrade --pre azure-cli --extra-index-url https://azurecliprod.blob.core.windows.net/edge --no-cache-dir --upgrade-strategy=eager"

Looks like anltr4 is somehow missing. Could you check whether antlr4-python3-runtime is installed correctly?
> pip list | grep antlr

antlr4-python3-runtime    4.7.2

BTW, we recently moved the dependency of antlr4-python3-runtime from azure-cli-core to azure-cli in https://github.com/Azure/azure-cli/pull/12917, but it should't cause this problem. +@MyronFanQiu

I have the same problem on Debian Buster.
{
"azure-cli": "2.0.81",
"azure-cli-core": "2.0.81",
"azure-cli-telemetry": "1.0.4",
"extensions": {
"azure-devops": "0.17.0"
}
}
Python 3.8.2
I installed the Azure cli from the debian packages you provide:
ii  azure-cli                             2.0.81+ds-3                          all          Azure Command-Line Interface (CLI)

pip3 list | grep antl

returns nothing. There is a python3-antlr3 debian package available but it is not installed (and it's the wrong version of antlr).
This seems to be a missing dependency in the azure-cli packaging.

Hi @cure, 2.0.81 is an old version. Could you let us know which package you installed and how? So that I can follow your steps to repro it.
We do have the correct dependency as shown in https://github.com/Azure/azure-cli/pull/12917.

hi @jiasli I installed azure-cli as per the instructions at

https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view=azure-cli-latest

The version I have installed is

$ dpkg -l |grep azure-cli
ii  azure-cli                             2.0.81+ds-3                          all          Azure Command-Line Interface (CLI)
ii  python3-azure-cli                     2.0.81+ds-3                          all          Azure Command-Line Interface (CLI)
ii  python3-azure-cli-core                2.0.81+ds-3                          all          Azure Command-Line Interface (CLI)
ii  python3-azure-cli-telemetry           2.0.81+ds-3                          all          Azure Command-Line Interface (CLI)

The package came from the repository at
deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ buster main
You are right that this is not the most recent version available (there is even a newer package available for the 2.0.81 version).

I am installing Azure CLI with
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

I tested on Ubuntu TLS 18.04 first:

$ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"
NAME="Ubuntu"
VERSION="18.04.4 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.4 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

$ dpkg -l | grep azure-cli
ii  azure-cli                          2.4.0-1~bionic                              all          Azure CLI

Then on Debian Buster
$ cat /etc/*-release
ID="azure"
VERSION="20200210-166"
AZURE_VERSION="0.20200210.166"
BUILD_INFO_URL="https://salsa.debian.org/cloud-admin-team/debian-cloud-images-daily/-/jobs/555200"
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

$ dpkg -l | grep azure-cli
ii  azure-cli                        2.4.0-1~buster              all          Azure CLI

az vm list works as expected on both platforms.
The package azure-cli (2.0.81+ds-3) is not distributed by us. Could you uninstall other packages of Azure CLI and try the official 2.4.0 version? + @fengzhou-msft to take a look.

@jiasli I can confirm that this bug is not present on Debian Buster with the latest version 2.4.0 of the Azure CLI, installed as per https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view=azure-cli-latest
I tested on a fresh installation of Debian Buster. From my perspective, this issue can be closed. Thanks!

@cure. You are welcome. I am glad the issue is solved. I doubt in your old Debian Buster https://packages.debian.org/ somehow overrides https://packages.microsoft.com/ for Azure CLI, so the installed Azure CLI is not the official release.


Some Questions

I have some questions about the configurations,can someone give me the answers,please.
My Project: Spring-boot2.0.4, JPA, MySql

In this configuration "sharding.jdbc.datasource.names=ds0,ds1", Both of the names are real database-names, are them?
When I set the names as this "sharding.jdbc.datasource.names=ds_0,ds_1",  It shows me some errors: "Configuration property name 'sharding.jdbc.datasource.ds_0' is not valid", also give me some advice：”Reason: Canonical names should be kebab-case ('-' separated), lowercase alpha-numeric characters and must start with a letter“， I did this, It showed mysql error:"check the manual that corresponds to your MySQL server version for the right syntax to use near '-0.my_test_1 mytest0_ where test0_.fid=1'".
Can I name the database with characters "_" like this: "test_db0" when use sharding-jdbc?

All of those questions you can try it first.
Practice is the best experience.

If the answer is enough, cloud you close this issue?

yes

How to resolve the question 2 ?


Review metric schema in context of other OSS projects

Worthwhile to look at concepts in other systems to see how we map. Please add more here ....
Prometheus
https://github.com/prometheus/client_model/blob/086fe7ca28bde6cec2acd5223423c1475a362858/metrics.proto#L76-  L81
New Relic
attributes: https://docs.newrelic.com/docs/agents/manage-apm-agents/agent-data/collect-custom-attributes
metrics: https://docs.newrelic.com/docs/agents/manage-apm-agents/agent-data/custom-metrics
well-known attributes: https://docs.newrelic.com/docs/insights/new-relic-insights/decorating-events/insights-attributes
AppDynamics:
custom metrics: https://docs.appdynamics.com/display/PRO42/Analytics+Events+API
well known attributes: https://docs.appdynamics.com/display/PRO42/Transaction+Analytics+Data
DynaTrace:
well-known attributes: https://community.dynatrace.com/community/display/APMSAASDOC/Data+Models+for+REST+API+Payloads

Statsd: https://github.com/etsy/statsd/blob/master/docs/metric_types.md

Also worth considering:

AWS CloudWatch

Custom Metrics: http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html
Well-known metrics and dimensions: http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html

Stackdriver Monitoring will publish its API metrics soon. Please consider it as well.

Please consider also
http://metrics20.org/
and https://github.com/vimeo/carbon-tagger

Zack, do we need to do anything specific here?

Given our decisions around descriptors where we punt to adapter config to handle backend representation (so our representation of a metric in Istio is just a value and dimensions, nothing else) I think we're fine on this front.


Fix issue with restoring selected preset

Fix #40
When the user selects a preset and closes the application it didn't stored the item which was selected in the presets plugin.
This fix will also use a more rigid check in order the destroy any previous instances of application in order to maintain a good relation with Maya callbacks

@aardschok Sweet stuff! I pulled this in my own repo to perform one additional fix, now as PR #59. Closing this one in favor for that PR.


Open dialog on page load

Hey,
is there a way to open the dialog on the page load? I want to show the dialog for password reset when there are certain params set in the URL. I was able to open the dialog by setting the open attribute on page load, but the problem is that the backdrop is not visible in Chrome.
Thanks for the great you're putting in the development of this dialog which I use every time I need any kind of modal / popup functionality. ❤

Hello there!
If you run on version 5, you should be able to add the open attribute to the <dialog> element. Chrome has some slightly buggy behaviour with the backdrop, but it shouldn’t be because of a11y-dialog.
Otherwise, you can also use this.dialog.show() right away programmatically. ;)


Resumable uploads using MediaUploader class

Hello,
I am looking to use MediaUpload class for uploading large attachments, upto 15 MB.
From source code I found out below mentioned text in googleapis/client/service/media_uploader.h.h file,

TODO(user): The interface does not yet support
-- streaming content
-- resumable uploads
*-- auto protocol selection

Is there any plan to include resumable download option in Media Uploader?
Or any other way to upload larger attachments while sending an email?
Thanks,
Harshal

Thanks for filing the issue, but we deprecated this repository, so closing.


How is NVIDIA DCGM Documentation built from sources?

Question
I found an official NVIDIA DCGM Documentation, which is built with Sphinx.
However, I couldn't find Sphinx's configuration file, conf.py in this repository.
Therefore, I wonder how NVIDIA DCGM Documentation is built from sources?
Screenshots

Hi @hwhsu1231,
You're right that Sphinx was used to build the official documentation, but unfortunately, it's not open-sourced and it's not part of this repository.
We don't have any plans to open-source it right now.
Best regards,
Nik


[Core] Use Map instead of Response-Object for send() methods

sendAndCheckDat() is returning the new Map<String, String> (header, payload), but other send() methods do still return the plain Response-Object.

In some use cases, returning an okhttp-response-object makes sense. Is not changed for now.
As soon as the check-DAT methods are used, a response-object is not returned, e.g. sendAndCheckDat().


Why right click will appear red dot。

Why right click will appear red dot.
They are can drag and left-click to disappear.
The default case also has this kind of phenomenon.
D:\Python2.7.10\share\kivy-examples\application\app_with_build.py
Do you have this kind of problem? Or this is my personal problem?
I'm afraid you can't send pictures。

This not a problem, this is feature!
By default, the middle and right mouse buttons, as well as a combination of ctrl + left mouse button
are used for multitouch emulation. If you want to use them for other purposes, you can disable this
behavior by activating the “disable_multitouch” token:
[input]
mouse = mouse,disable _ multitouch
You can read more in the manual.


Generalization of quantum gates to qudits

Now that cirq supports qudits, we should generalize our quantum gates where possible/appropriate. Some examples of gates that should work on qudits:

generalization of Pauli gates: X|k⟩ -> |k + 1 mod m⟩, Z|k⟩ -> e^(2πi/m)|k⟩,
generalization of Hadamard/Fourier transform that takes X to Z under conjugation.

Naming will get tricky. We should probably not make users look for generalized gates under obscure names. Instead, the most pythonic solution is to just make cirq.X etc work on qudits. Hadamard/Fourier is probably a little trickier, because the matrix of the qudit version of the Hadamard gate is not a Hadamard matrix, so cirq.H is a weird name. We could follow literature and call it cirq.W, but that might qualify as hiding generalized gates under obscure names.
Gates such as CX and CZ when control is a qubit and target is a qudit are straightforward, but it would be misleading to stringify the qudit version of CX as "CNOT".
Filing for discussion @balopat @dabacon @Strilanc

The current behavior of the gates when applied to qudits is to raise a ValueError:
ValueError: Wrong shape of qids for <cirq.H>. Expected (2,) but got (3,)

Related: #3058

What we found when we considered doing this is that it had a lot of really bad corner cases, especially when involving noise operations.
Here is a relevant question on the quantum computing stack exchange where the same issue is encountered with "how do I control a Kraus operator?": https://quantumcomputing.stackexchange.com/questions/12196/deriving-a-controlled-kraus-operator-from-an-uncontrolled-kraus-operator . The same logic applies to trying to apply a Kraus operator to the 01 subspace but not the 2 space.

For example, consider the Reset operation when using the "just work on the 01 subspace" interpretation suggested at the start of this issue. Is the reset operation really something that leaves the |2> state alone, or is the obviously correct generalization the one that also sends |2> to |0>? That's certainly what happens for the reset operation in our hardware.
I'm not even sure I would say the obvious generalization of X to a qutrit is to leave 2 alone. The equivalent of the X Pauli operation on qutrits are +0, +1, and +2 (mod 3). So perhaps X should be thought of as +1 (mod 2) in which case it would become +1 (mod 3) when operating on a qutrit.

I didn't suggest that we should implement qudit gates by unleashing corresponding qubit gates "on the 01 subspace". This is rarely (never?) the right thing to do. Instead, I noted that some gates admit natural generalization and provided examples for unitary gates:

generalization of Pauli gates: X|k⟩ -> |k + 1 mod m⟩, Z|k⟩ -> e^(2πi/m)|k⟩,

As you point out, natural generalizations are sometimes also available for non-unitary operations (e.g. reset).
I argue that:

wherever a unique natural generalization exists, we should use it (e.g. Paulis).
wherever multiple generalizations exist, but one if most common/natural, we should probably use it (e.g. reset).
wherever generalization is ambiguous, we should raise an exception.

Regarding Pauli X on qutrit: "swap 0 and 1" is the wrong thing to do and +1 mod 2 is the right thing to do. The former fails to satisfy the canonical commutation relations that users would expect of X and Z. The latter satisfies the CCRs. In fact, by Stone-von Neumann theorem, it is the unique generalization of Pauli operators that satisfies the CCRs.

Interesting caveat: I think there is actually some freedom in the form of generalized X. If we let
X|k⟩ -> |k + h mod m⟩

then we obtain reasonable(*) commutation relations as long as gcd(h, m) = 1. In a Hilbert space of prime dimension m any h=1, ..., m-1 works. The advantage of the choice h=1 is that it works in any dimension m. I think this still qualifies it as the right choice.
Also, I had a closer look at Stone-von Neumann and the uniqueness guarantee is in fact qualified with a free parameter corresponding to h (it hides in the exponentiated form of the commutation relations).

(*) By reasonable I mean that I can find an isomorphism onto the finite Heisenberg group. The isomorphisms for different h differ in how they map the generator of the center. Also, if gcd(h, m) > 1 then it's easy to see that no representation can contain X as defined above.

Regarding the idea of "swapping 0 and 1": In addition to the math way of seeing that this isn't the right way to generalize Pauli X there is also the physics way:
The math way: "swap 0 and 1" is order two operator (i.e. X^2 = I), but the Heisenberg group on Z/3Z does not include any element of order two.
The physics way: X and Z correspond to the position and momentum operators, so if you identify computational basis with the position basis then it becomes natural to expect that X does something like X|k⟩ -> |k + h mod m⟩. In particular, one would expect that X doesn't have fixed points, so it cannot leave higher levels unchanged.

Heisenberg-Weyl gates would be great.  This would be good to add to the roadmap feature for how we want gates to be interoperable or not.  I'm not sure of the advantage of overloading Pauli, for example, but I do see the advantage of overloading procedural calls (the former leads to problems that are consumers...each needs to support all qudit infrastructure or reject it, whereas the later is about construction, where we want it to be easy for users to create these objects).

I agree: if cirq has qudits then cirq should have Heisenberg-Weyl gates. As is so often the case, the hard issue is how to name the new gates?
Some options:

Overload cirq.X and cirq.Z.
cirq.Clock and cirq.Shift.
cirq.HeisenbergWeylX and cirq.HeisenbergWeylZ or somesuch.

My preference is for 1 over 2 over 3.
In support of 1:
It seems awkward to have cirq.X(qudit) raise an exception when the name together with input type make it clear what the intention is. Consider the precedent in numpy: np.sqrt works with both a scalar and a matrix - after all you can think of a scalar as a 1x1 matrix. Along the same lines, it seems reasonable that cirq.X works with both a qubit and a qudit - after all you can think of a qubit as a 2-level qudit. It seems safe, unambiguous and pythonic to just let users write cirq.Z(qudit) etc.
In support of 2:
Longer than 1, but perhaps still short enough to render well in circuits. I have seen the names used only occasionally (e.g. in the wikipedia article on generalized Paulis), but the intuitive connection between the names and what the gates do is very clear.
Against 3:
The long names are ugly and render poorly in circuit diagrams.
WDYT?

There is also the question of generalizing other gates/operations that have clear meaning for multi-level systems, e.g. reset. I think necessity will eventually push us towards including such gates. This presents an additional argument for option 1 above: When we generalize reset to qudits it is unlikely we'll want a different name for it. Once this happens we'll have an inconsistent API where some generalizations have their own names and others share the well-known name for qubits.

I think that there could be some confusion when reading Cirq code cirq.X(qudit) is

a qudit Pauli (+1 mod d) gate or
a qubit X gate on the 0-1 subspace

but I would prefer the first as a default if there is a clear way to also get the second (maybe cirq.X.on_01_subspace(qudit) that defaults to adding no phase to the other states).
For measurement (and reset), maybe there should be a "QubitHardwareMeasurementGate" that correctly simulates leaked (non-0/1) states in a hardware-specific way to produce only 0/1 measurements.  This would be used for NoiseModels that use qudits.  The usual cirq.measure(qudit) (cirq.reset(qudit)) already does the expected ideal qudit measurement (reset to 0).

In my own research I've used qudits in two paradigms with often conflicting names:

Extended Clifford hierarchy gates like you discuss for base-d computation and qudit error correction.
Example names: X, CSUM, H/Chrestenson.
Qubit gates on the 0-1, 0-2, 1-2, etc. subspaces [1, 2].
Example names: X_01, H_02, C2X02 (X on the 0-2 subspace if the control is a |2>)

I've implemented some of these gates for my own use but haven't contributed them to Cirq yet because the names aren't all consistent and the questions about integration with the rest of Cirq that you bring up.  (I haven't found a good name for the qudit Hadamard gate.  The name Chrestenson that I used for that comes from [3, 4])

One clear way to get the X gate on the 0-1 subspace would be something like
cirq.X(qudit.subspace(0, 2))

where subspace method of a qudit exposes a subspace as a qubit. This helps avoid the need for hardcoding subspace information in names of gates (and proliferation of different classes/instances for what is essentially one thing).
Re QubitHardwareMeasurementGate : Is there a universally valid "quantum hardware measurement" that accounts for leakage in the way appropriate to all types of quantum hardware?
"CSUM" is a good printed name for a qudit CX (in place of "CNOT").
Re name for the analog of Hadamard: on second thought I think that if we overload cirq.X and cirq.Z for Heisenberg-Weyl gates then we should probably overload cirq.QFT for the Chrestenson gate (perhaps that's an argument against overloading any of the names, but I think the argument about precedents for inferring details of functionality from the type of arguments applies to QFT as well).

+1 for
cirq.X(qudit.subspace(0, 2))

We should extend the gates we have to qudits since qudits are general. Having cirq.H and cirq.Chrestenson is duplication IMO.

cirq.X(qudit.subspace(0, 2)) is an interesting idea.  Would you implement it something like this (being careful about infinite recursion)?
class Gate:
    ...
    def on(self, *qubits):
        if any(isinstance(q, QuditSubspace) for q in qubits):
            return SubspaceGate(self, <subspace indices for each qubit>).on(*qubits)
        ...

This would require an awkward new type, QuditSubspace (that probably shouldn't be a Qid subclass), only used as an indicator for constructing gates on subspaces of qudits.

fu**ing your comment.why don't you write more clearly?
for example :
import cirq
circ = cirq.Circuit()
qbits = [cirq.LineQubit(x) for x in range(2)]
circ.append([cirq.H(qbits[0]), cirq.CNOT(qbits[0], qbits[1])])
print out the circuit
print(circ)
or 👍
circuit = cirq.Circuit()
circuit.append(cirq.H(q) for q in cirq.LineQubit.range(3))
print(cirq.Circuit(cirq.SWAP(q, q+1) for q in cirq.LineQubit.range(3)))

I looked into this, and it looks like this will have to be done gate-by-gate. The reason is that most gates define an _apply_unitary_, and we'd have to update each of those to accept an optional subspace argument and use it accordingly.
I see two ways of avoiding gate-by-gate. First, the apply_unitary protocol first calls ApplyUnitaryArgs._for_operation_with_qid_shape before passing the result of that into the gate's _apply_unitary_ method. We could update that function to accept the optional subspace argument and use that in constructing the transformed ApplyUnitaryArgs for the gate. However I don't see a way to do such an operation efficiently, as the view would have different dimensions and thus require a full copy of the tensors rather than just a view (unless numpy has some magic I'm not aware of).
The other option would be to remove _apply_unitary_ from all these gates and allow the unitary protocol to fall back to the _strat_apply_unitary_from_unitary strategy. Within that strategy, the unitary of the gate could then be stuffed with identity on the non-applied subspace, to make it the appropriate shape before applying it. But I assume that this would be less efficient or we wouldn't have gone through the trouble of implementing _apply_unitary_ everywhere?

Or wait, for the first alternative above, it looks like that's exactly what slices allows. We're just using it to slice the full size of the qid_shape, but it could be specialized to slice to a subspace. I'll try that out.

To note, #4783 is a valid mathematical representation of it, and the simulator worked great for all our unitary gates. The only thing is there are places where we need to make sure we're using the underlying qudits instead of the wrapped ones. Diagram drawing for instance. I closed the PR because I don't think I'll have any time to work on it. But if for some reason this becomes a big need, that PR is a good starting point.
Also FWIW Reset already supports qudits. https://github.com/quantumlib/Cirq/blob/d58b58ba7c71af97cb96b667e7e6a3865c9a4bc4/cirq-core/cirq/ops/common_channels.py#L744-L746

Upon implementing it, putting a wrapper around qubits and making a qudit.subspace(0, 2) was too dangerous IMO. Even though it worked, there were just too many places we'd have to distinguish between a Qid and a QidSubspace.
I changed the linked PR so that we wrap the gate instead. It's  DimensionAdapterGate(cirq.X, slice(0, 3, 2)).on(qudit). It all still uses slices under the hood to work efficiently. We can of course write a helper to clean that up to cirq.X.for_subspace(0, 2) or something. Again it all seems to work, and this time it's "just another gate" type, so far less invasive. And given it's just a gate, it's something that could more easily be serialized and run on HW too.
@viathor @dabacon How do you feel about this approach? Or, given this is an ancient issue, are we no longer interested in the feature?

Upon implementing it, putting a wrapper around qubits and making a qudit.subspace(0, 2) was too dangerous IMO. Even though it worked, there were just too many places we'd have to distinguish between a Qid and a QidSubspace.
I changed the linked PR so that we wrap the gate instead. It's  DimensionAdapterGate(cirq.X, slice(0, 3, 2)).on(qudit). It all still uses slices under the hood to work efficiently. We can of course write a helper to clean that up to cirq.X.for_subspace(0, 2) or something. Again it all seems to work, and this time it's "just another gate" type, so far less invasive. And given it's just a gate, it's something that could more easily be serialized and run on HW too.
@viathor @dabacon How do you feel about this approach? Or, given this is an ancient issue, are we no longer interested in the feature?

I think the DimensionAdapterGate is a reasonable thing to have, though it does sort of miss the original problem which was that we wanted this to be seemless.   I think the conclusion was the the seemless version wasn't going to work and we have decided to create specific X and Z gates for qudits.
Let's close this for now, but if we want to revive DimensionAdapterGate we could definitely do that, but I don't think we have the evidence that people will use that over existing or custom gates.


Consistent release version-correlated decrease of LGBMRanker performance

Description
First of all thank you for your work in this amazing library, it has been extremely useful in our research. I open this issue to ask for your opinion about something we have observed in my research group and perhaps is relevant to other people here using LGBM ranker.
It all started when a colleague of mine couldn't reproduce my results and then we noticed that we were using different versions of the lightgbm library. We went on a small experiment to see the differences of performance (we use a custom metric function) depending on the release version and we saw that actually performance decreases quite consistently from old to new releases. See the plot below.

We tried to pinpoint which were the possible breaking changes and to do so we tracked the commit history of the lambdarank test function, located at tests/python_package_test/test_sklearn.py . Particularly, we were able to observe several changes in the lambdarank loss function and changes in default parameters. Unfortunately, we are not well versed with the inner workings of lambdarank so we can't fully grasp the relevance of such changes. What was surprising to us, was to see that the plaintext performances used in the equality tests also decrease quite consistently from old to new releases. Please see the plot below which shows the performance written as plaintext as a function of time (commit date).

Is there any guidance that the developers could offer us to justify the use of one or another version? Is there any reason why the changes in loss function were applied? Any bugs we should be aware of?
Reproducible example
The performances for the later plot were extracted from the following commits (from old to new):
# https://github.com/microsoft/LightGBM/commit/496a07d1dbd5c3a8cf28d50f5aad84428fddf2f4#diff-711a5439fdebb728fb5859f49561c5cd1388e25276dd03c409dc63c46f2f88d2
# https://github.com/microsoft/LightGBM/commit/aee92f63ba124e1f6a3168eb2864d032567cbf9e#diff-711a5439fdebb728fb5859f49561c5cd1388e25276dd03c409dc63c46f2f88d2
# https://github.com/microsoft/LightGBM/commit/0dfda82607633132e10a693eba9666ed75585ac8#diff-711a5439fdebb728fb5859f49561c5cd1388e25276dd03c409dc63c46f2f88d2
# https://github.com/microsoft/LightGBM/commit/509c2e50c25eded99fc0997afe25ebee1b33285d#diff-98ca62132fa18e4a80cd57f16e9337fe3d72a08d5862d02eae9935bed9e43486
# https://github.com/microsoft/LightGBM/commit/ba0a1f8d38d12aeb29f1c769596308eb8b1e5874

Thanks very much for using LightGBM and for the thorough write-up!
Are you able to provide a reproducible example? Without an example to try (and to rule out some theories), I think it will be very difficult to find an answer to this question.

to see that the plaintext performances used in the equality tests also decrease quite consistently from old to new releases

After re-reading I understand what you mean by this. You're saying that for the lambdarank tests in LightGBM's tests suite, you can see hard-coded performance expectations being reduced.
e.g., from https://github.com/microsoft/LightGBM/commit/509c2e50c25eded99fc0997afe25ebee1b33285d#diff-98ca62132fa18e4a80cd57f16e9337fe3d72a08d5862d02eae9935bed9e43486

I think maybe @shiyu1994 or @btrotta will be able to give you the best guidance on this question.

Yes, that's right. Thank you for your prompt answer!

@GerardBCN Thanks a lot for sharing your observations! All commits were made to fix bugs or increase ranking performance on real data. I promise that no commit was merged with the aim to intentionally decrease ranking performance 😃 . You can see that some important changes were proved to increase the score on some kind of "standard" ranking datasets for benchmarking: https://github.com/microsoft/LightGBM/pull/2322#issuecomment-520588581, https://github.com/microsoft/LightGBM/pull/2331#issue-308379577, https://github.com/microsoft/LightGBM/pull/3425#issuecomment-702436728.
Regarding intentional score decreasing in the test_sklearn.py file, this was done given that improvements for the ranking algorithm in general or particular bug fixes are not always positively act on one particular dataset used in our tests. I guess that this is also applicable for your situation.
Thanks for providing the list of commits you've found related to ranking! Thanks to GitHub, we can easily check corresponding Pull Requests and find out what was the aim of those PR.

https://github.com/microsoft/LightGBM/commit/496a07d1dbd5c3a8cf28d50f5aad84428fddf2f4#diff-711a5439fdebb728fb5859f49561c5cd1388e25276dd03c409dc63c46f2f88d2
std::sort was replaced with std::stable_sort in some places to fix reproducibility issue on different platforms caused by non-deterministic sorting of same values in case of std::sort.
https://github.com/microsoft/LightGBM/commit/aee92f63ba124e1f6a3168eb2864d032567cbf9e#diff-711a5439fdebb728fb5859f49561c5cd1388e25276dd03c409dc63c46f2f88d2
More accurate implementation according to the original LambdaMART paper.
https://github.com/microsoft/LightGBM/commit/0dfda82607633132e10a693eba9666ed75585ac8#diff-711a5439fdebb728fb5859f49561c5cd1388e25276dd03c409dc63c46f2f88d2
Brought normalization back after its' removal with the commit listed above. Also, made it optional by lambdamart_norm parameter.
https://github.com/microsoft/LightGBM/commit/509c2e50c25eded99fc0997afe25ebee1b33285d#diff-98ca62132fa18e4a80cd57f16e9337fe3d72a08d5862d02eae9935bed9e43486
Huge global LightGBM refactoring not related to ranking, but related to the speed. This was the main breaking change that forced us to bump major version (3.x.x) of LightGBM.
https://github.com/microsoft/LightGBM/commit/ba0a1f8d38d12aeb29f1c769596308eb8b1e5874
Fix to better handle k in NDCG@k.


⚠ ClamAV has degraded performance

In 6b70bb9, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 270 ms

Resolved: ClamAV performance has improved in 4e11af3 after 5 minutes.


docs: update with Expo installation steps

Resolves #1159

Summary

Test Plan

What's required for testing (prerequisites)?
What are the steps to reproduce (after prerequisites)?
Compatibility

OS
Implemented

iOS
✅❌

Android
✅❌

Checklist

[ ] I have tested this on a device and a simulator
[x] I added the documentation in README.md
[ ] I mentioned this change in CHANGELOG.md
[ ] I updated the typed files (TS and Flow)
[ ] I added a sample use of the API in the example project (example/App.js)

Thanks for this!

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


DAI Shielding Error

DAI shielding is not working.
Gives "params.data" type error...

thanks for reporting. this error should be resolved now. comment here if you see it again.


Support for Addressable Pixels

Generalized protocol buffer API for controlling addressable pixels including WS2812 (NeoPixel), WS2801, APA102 (DotStar).
Some communication API inspiration from our BLE docs,
https://github.com/adafruit/bluetooth-low-energy#addressable-pixel-service---0x0900

This has been supported since Nov 18, 2022. Closing!


Add missing parenthesis

Related tickets & documents
Link to JIRA ticket if there is one.
Description
Provide a meaningful description about the changes you've made.

fixed in https://github.com/paytrail/api-documentation/pull/12


Cosmetics

Hey there, nothing special here, just cleaning up a bit.

These look fine, but they'll need to be applied to the master branch instead of stable.
I'll do that in a bit.
(We never actually delete the ReductionOpUntyped's, but if we did, we'd want this fix.)

Check. I'll refile against master. Sorry about that.


Added test cases NMS_FT_177.

Added test cases NMS_FT_177

ok to test

ok to test

ok to test

ok to test


⚠ DDoS-Relay US-E-ash-2 has degraded performance

In f0c3b96, DDoS-Relay US-E-ash-2 (http://<IP_ADDRESS>:42069/;csv) experienced degraded performance:

HTTP code: 200
Response time: 4 ms

Resolved: DDoS-Relay US-E-ash-2 performance has improved in 0f470da after 12 minutes.


renal pelvis not part of ureter

http://purl.obolibrary.org/obo/MP_0004194

I'm not sure KP should be treated as part of the ureter, and hence abnormalities of the KP are not necessarily abnormalities of the ureter.
I think in FMA, KP used to be part_of ureter, but no longer, now it is explicitly continuous_with.
Uberon used to follow FMA and MP, but will likely change

Some ontologies use upper urinary tract for whole kidney (which includes KP) plus the ureters

Discussion on similar structures in NCIT https://github.com/NCI-Thesaurus/thesaurus-obo-edition/issues/43

I've removed the connection to ureter and updated the definition to reflect the revised definition on the NCIT site. This is also in keeping with the EMAP structure where renal pelvis is a child of metanephros.


Highlighting is not removed in Metadata Editor after moving focus and saving changes

System information:

Operating system (distribution) and version Mac
DBeaver version 21.0.5 EA

2 Mac specific cases exist:
Case 1
Steps to reproduce, if exist:

Open an editable object in Metadata Editor
Make some inline edit
Click to inactive Save button after that
Click to the field with the object and then click on Save button again (it is active now)

Expected: the changes are saved, the highlighting is removed
Actual result: the changes are saved, the highlighting remains visible
https://user-images.githubusercontent.com/51405061/118277517-8a83f380-b4d1-11eb-847b-76d4954868a5.mov
Case 2
Also Boolean checkbox jumps in Metadata Editor/Data transfer dialog
https://user-images.githubusercontent.com/51405061/118293313-32a1b880-b4e2-11eb-9d02-5ecee4615932.mov

There is a much bigger usability problem in the entity editor. If you double-click on the boolean editor in case 1, the table column editor opens.

The issue with the coloring can only be reproduced on the light theme using the default color scheme (and still not 100% of the time).

Case 1 is fixed. Case 2 deserves its own ticket. The issue I mentioned above seems to be particularly my problem with double-clicks. As of now, I believe it needs to be addressed only if other users will complain.

Case 1 is verified, separate ticket is created for case 2 https://github.com/dbeaver/dbeaver/issues/12566


chore(docker): use zksync-build-base as a builder image

What ❔

Why ❔

Checklist

[ ] PR title corresponds to the body of PR (we generate changelog entries from PRs).
[ ] Tests for the changes have been added / updated.
[ ] Documentation comments have been added / updated.
[ ] Code has been formatted via zk fmt and zk lint.
[ ] Spellcheck has been run via zk spellcheck.
[ ] Linkcheck has been run via zk linkcheck.

Looks like we're still running the same apt-get commands and stuff . Shouldn't it have been solved by the base image or am I missing something here?

I am going to merge this and proceed with similar docker files for CUDA and the runner that still runs apt-get and such

still the same apt-get command?

🎉 🌮 🎸 🚀

Not often


Database.listDocuments() unexpected behavior with offset and filter

Offset and Limit appear to be switched for the listDocuments() function.
What's odd, is I check the code here and it looks fine.  But when I run this code, this is what I get.
const response = await .database.listDocuments(
        BOT_RUN_COLLECTION_ID,
        ['last_processed_id!=null', 'last_processed_id!=""'],
        0, // offset, should be the limit according to docs.
        1, //limit, out of order. Should be switched with offset according to docs.
        'processed_to',
        'DESC',
        'datetime'
      )
      console.log(response)

Console:
{
  sum: 12,
  documents: [
    {
      "$id": "*****",
      "$collection": "*****",
      "$permissions": { read: [Array], write: [Array] },
      mentions_processed: 3,
      processed_to: "2021-04-03T01:30:23.000Z",
      duplicate_submissions: 0,
      novel_submissions: 0,
      last_processed_id: "****"
    }
  ]
}

When I switch them and run:
      const response = await database.listDocuments(
        BOT_RUN_COLLECTION_ID,
        ['last_processed_id!=null', 'last_processed_id!=""'],
        1, // supposed to be the limit
        0, // supposed to be the offset
        'processed_to',
        'DESC',
        'datetime'
      )
      console.log(response)

I get this resposne:
{ sum: 12, documents: [] }

So the offset and limit appear to be switched in order.

Hey @trydalch 👋🏻
I am gonna look into it to see what is happening 🙂
Do you mind sharing the JSON of your collection? Can be found in the Dashboard.


Attempting to add federation endpoint

I tried adding federation with some other prometheus servers with the following config:
prometheus_scrape_configs:
- job_name: 'federate'
  scrape_interval: 15s

  honor_labels: true
  metrics_path: '/federate'

  params:
  'match[]':
    - '{job="prometheus"}'
    - '{__name__=~"job:.*"}'

  static_configs:
  - targets:
    - 'monitoring.dev.example.net:9090'
    - 'monitoring.uat.example.net:9090'
    - 'monitoring.prod.example.net:9090'

But getting the following error:
fatal: [monitoring]: FAILED! => {"changed": false, "checksum": "e68e2ea1f72f8aeb8769b1949ec862b89459bb99", "exit_status": 1, "msg": "failed to validate", "stderr": "  FAILED: parsing YAML file /home/ubuntu/.ansibl e/tmp/ansible-tmp-1597304467.1828673-51060614977003/source: yaml: unmarshal errors:\n  line 31: field match[] not found in type config.plain\n", "stderr_lines": ["  FAILED: parsing YAML file /home/ubuntu/.ansible/ tmp/ansible-tmp-1597304467.1828673-51060614977003/source: yaml: unmarshal errors:", "  line 31: field match[] not found in type config.plain"], "stdout": "Checking /home/ubuntu/.ansible/tmp/ansible-tmp-1597304467. 1828673-51060614977003/source\n\n", "stdout_lines": ["Checking /home/ubuntu/.ansible/tmp/ansible-tmp-1597304467.1828673-51060614977003/source", ""]}
Using latest version of the role and ansible 2.9.6
Is this particular feature not currently supported by the role?

Your indent is invalid. It should be:
  params:
    'match[]':
      - '{job="prometheus"}'
      - '{__name__=~"job:.*"}'

thanks, that was it. Embarrassing!


Socket Error OSX

OSX 10.11.4
Rethinkdb 2.3.2 (CLANG 7.3.0 (clang-703.0.31)) installed over homebrew
Tried to port an existing projekt to horizon, but it wasn't working at all.
Then I tired the init project:
hz init hello-world

Started the server with
hz serve --dev

Admin interface is working. Tables hello-world and hello-world_internal got created.
But the h1 hello world works does not appear.

App available at http://<IP_ADDRESS>:8189
Starting Horizon...
debug: Added HTTP handler at /horizon/horizon.js
debug: Added HTTP handler at /horizon/horizon.js.map
debug: Added HTTP handler at /horizon/auth_methods
info: Connecting to RethinkDB: localhost:28015
debug: Connection to RethinkDB established.
debug: running metadata sync
info: Groups metadata synced.
info: Index metadata synced.
info: Collections metadata synced.
debug: adding admin user
debug: redirecting users table
debug: metadata sync complete
info: Metadata synced with database, ready for traffic.
Horizon ready for connections 🌄

(yep, no error about the connections or anything)
and what I see in browser dev tools is

Could you run hz serve with the --debug option please and see if it prints any message when refreshing the website?

After refreshing I get
Horizon ready for connections 🌄
debug: Handling HTTP request to horizon subpath: horizon.js
debug: Client connection established.
debug: Closing client connection with message: No connection to the database.
debug: info: {"error":"No connection to the database."}
debug: Client connection terminated.
debug: Handling HTTP request to horizon subpath: horizon.js.map

@apertureless Ah, what is hz version? We fixed a similar issue in Horizon 1.0.1 yesterday.

Installed it yesterday, but still got 1.0.0
Will update and report back.

@danielmewes I am running v1.0.1 by the way

@steelbrain Ah and you were already running with --debug, I missed that.
It's weird that you're not even getting any of the "debug: Handling HTTP request" outputs from hz serve. Does refreshing the page generate no debug messages at all?

@danielmewes Not really, It not showing anything, not even that handling HTTP request one

Pretty odd. Is this just the default application generated by hz init? If not, could you share the application code?

I could share the config.toml, here it is https://gist.github.com/steelbrain/5f0f01948110eaf719813aae30c05a20

                                                                                Thanks, I was more curious about how you were importing the Horizon client into the application and how you're establishing the Horizon connection.

@danielmewes Good catch, to future visitors, I was using a local copy of monkey-patched horizon client to fix a promise bug. Pointing the <script /> to the horizon server's script path fixed it

Ah nice, I think we can close this then.
@apertureless please re-open if you're still seeing this issue after the 1.0.1 upgrade.

I'm getting the same error message in 1.1.1 (updated today) but it may have a different underlying cause. When I run in debug mode I get a number of errors from the database:

debug: Connection to RethinkDB terminated: ReqlOpFailedError: cannot subscribe to table api_internal.groups: primary replica for shard ["", +inf) not available in:
r.db("api_internal").table("groups").changes({"squash": true, "includeInitial": true, "includeStates": true, "includeTypes": true})
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
debug: stack: ReqlOpFailedError: cannot subscribe to table api_internal.groups: primary replica for shard ["", +inf) not available in:
r.db("api_internal").table("groups").changes({"squash": true, "includeInitial": true, "includeStates": true, "includeTypes": true})
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
at ReqlOpFailedError.ReqlError [as constructor] (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/errors.js:23:13)
at ReqlOpFailedError.ReqlRuntimeError [as constructor] (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/errors.js:90:51)
at ReqlOpFailedError.ReqlAvailabilityError [as constructor] (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/errors.js:167:56)
at new ReqlOpFailedError (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/errors.js:178:52)
at mkErr (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/util.js:177:10)
at TcpConnection.Connection._processResponse (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/net.js:152:16)
at TcpConnection.Connection._data (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/net.js:122:12)
at Socket. (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/net.js:683:32)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at readableAddChunk (_stream_readable.js:172:18)
at Socket.Readable.push (_stream_readable.js:130:10)
at TCP.onread (net.js:542:20)
debug: Connection to RethinkDB established.
debug: running metadata sync
info: Index metadata synced.
debug: Connection to RethinkDB terminated: ReqlOpFailedError: cannot subscribe to table api_internal.collections: primary replica for shard ["", +inf) not available in:
r.db("api_internal").table("collections").changes({"squash": true, "includeInitial": true, "includeStates": true, "includeTypes": true})
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
debug: stack: ReqlOpFailedError: cannot subscribe to table api_internal.collections: primary replica for shard ["", +inf) not available in:
r.db("api_internal").table("collections").changes({"squash": true, "includeInitial": true, "includeStates": true, "includeTypes": true})
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
at ReqlOpFailedError.ReqlError [as constructor] (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/errors.js:23:13)
at ReqlOpFailedError.ReqlRuntimeError [as constructor] (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/errors.js:90:51)
at ReqlOpFailedError.ReqlAvailabilityError [as constructor] (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/errors.js:167:56)
at new ReqlOpFailedError (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/errors.js:178:52)
at mkErr (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/util.js:177:10)
at TcpConnection.Connection._processResponse (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/net.js:152:16)
at TcpConnection.Connection._data (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/net.js:122:12)
at Socket. (/usr/local/lib/node_modules/horizon/node_modules/rethinkdb/net.js:683:32)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at readableAddChunk (_stream_readable.js:172:18)
at Socket.Readable.push (_stream_readable.js:130:10)
at TCP.onread (net.js:542:20)
debug: Connection to RethinkDB established.
debug: running metadata sync
info: Groups metadata synced.
info: Index metadata synced.
info: Collections metadata synced.
debug: adding admin user
debug: redirecting users table
debug: metadata sync complete
info: Metadata synced with database, ready for traffic.
Horizon ready for connections 🌄

Ok, it appears that my JWT token was expiring. Is this something I am meant to manually manage or shouldn't this be done as part of the Horizon housekeeping?

Note: this is in "dev" mode and in an unauthenticated area

@ksnyde Sorry for the late response. I think this was addressed by https://github.com/rethinkdb/horizon/issues/554 and should now work automatically as of Horizon 1.1.1.

Great, thanks.


🐛 Remove Auth headers from request if auth is not needed

Closes ncpi-fhir/ncpi-ui-fhir-data-dashboard#8
Also doesn't send auth header if a url uses a proxy url

I cant reproduce :( whats your .env file?


(FACT-1906) networking.dhcp fact is blank on RedHat 8 beta

Reference: https://github.com/puppetlabs/facter/pull/1769

#1770

CLA signed by all contributors.

jenkins please test this on redhat8-64a


[BUG] Inferred field types ignoring [Nested] and [Keyword] attributes?

What is the bug?
I've found that when using [Nested] and [Keyword] attributes on C# properties, and then indexing them into a non-existent index, when the index is created and the documents are finished indexing, the property exists, but they are not of "nested" or "keyword" types, as if those attributes are being ignored entirely.
If I instead delete the index and recreate it using a PUT call with the fields defined explicitly as "keyword" or "nested" then it works fine.
How can one reproduce the bug?
Index a document with a string property flagged with the [Keyword] attribute into a new index, and then do GET /your-index/_mappings and you'll see in the results that the field is of type "text" with an inner automatic "keyword" field, instead of just making the top level field of type "keyword".
What is the expected behavior?
If you use the [Keyword] attribute, the resulting field should be of type "keyword" not of type "text". Similar for [Nested], the resulting property should be of type "nested".
What is your host/environment?
OpenSearch.Client 1.4.0 connecting to OpenSearch 2.7.0.
Do you have any additional context?
This is how I'm setting up the client I use to index the documents:
ConnectionSettings settings = new ConnectionSettings
(
    new Uri(OurAWSOpenSearchEndpoint),
    new AwsSigV4HttpConnection()
)
.DefaultFieldNameInferrer
(
    // This is specified as a method that does nothing, so that the field names will
    // remain un-touched, i.e. remain in PascalCase instead of being converted to camelCase.
    fieldName → fieldName
)
.DefaultIndex("messages")
// Set the defaults for the Message object type
.DefaultMappingFor<Message>
(
    m → m
    .IndexName("messages")
    .IdProperty(nameof(Message.MessageKey))
);

#if !RELEASE
settings.EnableDebugMode();
#endif

var client = new OpenSearchClient(settings);

@winzig The auto creation of indices is a behaviour of the server itself, not of the client. So while the server will automatically create a missing index when you make a request to index a document (or bulk index), these requests contain no mapping information, so the server will guess the mappings from the document data. To provide mappings you must explicitly create the index (or update its mappings).
To create an index taking advantage of the attributes you need to do it like so:
await client.Indices.CreateAsync("messages", i => i
        .Map(m => m
                .AutoMap<Message>()
        )
);

What is the point of the attributes then?

What is the point of the attributes then?

Primarily any relating to type information/mapping are used to reduce verbosity when creating and index and configuring its mappings.
For example given a type:
public class Employee
{
    [Text(Name = "first_name", Norms = false, Similarity = "LMDirichlet")]
    public string FirstName { get; set; }

    [Text(Name = "last_name")]
    public string LastName { get; set; }

    [Number(DocValues = false, IgnoreMalformed = true, Coerce = true)]
    public int Salary { get; set; }

    [Date(Format = "MMddyyyy")]
    public DateTime Birthday { get; set; }

    [Boolean(NullValue = false, Store = true)]
    public bool IsManager { get; set; }

    [Nested]
    [PropertyName("empl")]
    public List<Employee> Employees { get; set; }

    [Text(Name = "office_hours")]
    public TimeSpan? OfficeHours { get; set; }
}

You could do:
client.Indices.Create("employees", c => c.Map<Employee>(m => m.AutoMap()));

Or you could manually build the mappings in fluent syntax:
client.Indices.Create("employees", c => c
            .Map<Employee>(m => m
                .Properties(ps => ps
                    .Text(t => t
                        .Name("first_name")
                        .Norms(false)
                        .Similarity("LMDirichlet")
                    )
                    .Text(t => t.Name("last_name"))
                    .Number(n => n
                        .Name(o => o.Salary)
                        .DocValues(false)
                        .IgnoreMalformed()
                        .Coerce()
                    )
                    .Date(d => d
                        .Name(o => o.Birthday)
                        .Format("MMddyyyy")
                    )
                    .Boolean(b => b
                        .Name(o => o.IsManager)
                        .NullValue(false)
                        .Store()
                    )
                    .Nested<Employee>(n => n.Name("empl"))
                    .Text(t => t.Name("office_hours"))
                )
            )
        );

Those relating to renaming and formatting of properties and such will also be taken into when performing indexing and searching though.


login Clear text transmission

Description
When logging in to the login page, it is transmitted in clear text. How to encrypt the transmitted account password?
http://IP:8889/hue/accounts/login?next=/
http://IP:8889/hue/accounts/login
csrfmiddlewaretoken: BNHRZnFovTgKNsA8BEOygfaQF3FfD9RxtsBbYv7jcZ6CfhMwfxF1pchF8i8vQzlW
username: admin
password: admin
next: /

Hi @Luo-Xinmin and thanks for reaching out. You should use SSL and connect to Hue via https. @Harshg999 please correct me if I'm missing something here.


[BUG] BadRequest when calling CreateOrUpdateFunctionSecretAsync

Library name and version
Azure.ResourceManager.AppService
Describe the bug
Consider the following code:
var subscriptionName = "my-subscription";
var resourceGroupName = "my-rg";
var appName = "my-app";
var funcName = "my-func";

var client = new ArmClient(new DefaultAzureCredential());
var subscriptions = client.GetSubscriptions();
var subscription = await subscriptions.FirstOrDefaultAwaitAsync(x => ValueTask.FromResult(x.Data.DisplayName == subscriptionName));
ResourceGroupResource resourceGroup = await subscription.GetResourceGroups().GetAsync(resourceGroupName);
WebSiteResource app = await resourceGroup.GetWebSiteAsync(appName);
SiteFunctionResource func = await app.GetSiteFunctions().GetAsync(funcName);
AppServiceConfigurationDictionary keys = await func.GetFunctionKeysAsync();
FunctionAppHostKeys hostKeys = await app.GetHostKeysAsync();
WebAppKeyInfo keyInfo = await func.CreateOrUpdateFunctionSecretAsync("my-key", new WebAppKeyInfo {Name = "my-key", Value = "my-secret"});
keyInfo.Dump("Key Info");

Call to CreateOrUpdateFunctionSecretAsync throws this exception:
RequestFailedException: Service request failed.
Status: 400 (Bad Request)

Content:
{"Code":"BadRequest","Message":"Properties object is not present in the request body.","Target":null,"Details":[{"Message":"Properties object is not present in the request body."},{"Code":"BadRequest"},{"ErrorEntity":{"ExtendedCode":"51006","MessageTemplate":"{0} object is not present in the request body.","Parameters":["Properties"],"Code":"BadRequest","Message":"Properties object is not present in the request body."}}],"Innererror":null}

This problem is most likely described in https://tomaszoledzki.eu/2020/07/24/badrequest-error-function-app-create-or-update-host-secret/, but the Azure.ResourceManager.AppService lib appears broken at the moment.
Expected behavior
I expect calls to CreateOrUpdateFunctionSecretAsync to be successful.
Actual behavior
Call to CreateOrUpdateFunctionSecretAsync fails with Bad Request error.
Reproduction Steps
See the code snippet above.
Environment
Windows 10 on .NET Core 6.0

Thank you for your feedback.  Tagging and routing to the team member best able to assist.


this is not working in firefox

Hi, first I was using this slick for angular working fine on both firefox and on chrome. now I am using this current one but it is not working on firefox.
Please tell me how to make it work on all the browsers.

Hi @BhuvneshGupta  what version of firefox you got the problem, can you be more specific about it? thanks

it was not working because I was not using ng-if we need to use ng-if="loaded". because data is coming via service and it takes time.
sorry.
so problem is resolved but can you please tell me whats the  difference between these 2 slick
https://github.com/vasyabigi/angular-slick
https://github.com/devmark/angular-slick-carousel

Hi @BhuvneshGupta  they kinda do the same thing, but the other one looks abandoned last updated 25th of march 2015. :)

yeah absolutely @douglasdeodato  that is abandoned and using this my main issue is automatically solved of adaptiveHeight: true . Thanks man:)
Now I am facing one more issue I hope you can help me in that.
Issue is I am having two carousels on same page. And I am using same settings for both the sliders, i.e slideToShow:3
now as my data is dynamic so one slider has 3 images and the other slider has only one image and what wrong is happening is. Slider with 3 images working perfect but slider with one image is not looking good because that single image is stretching and taking width of 3 slides i.e 760px;
How to stop using width?
and yes one more question is that I am using infinite:true so it should slide no matter how many images I have but its not sliding as number of slides = slideToShow.
Thanks :)

@BhuvneshGupta  sorry but do you have a https://jsfiddle.net/ ? sample? I could not understand well what you want. thanks


Adding policy ALLOW_OBSOLETE_MSVCRT suppressing dependency check for msvcrt.dll

As suggested in #1124 this adds a new policy named ALLOW_OBSOLETE_MSVCRT which suppresses the check for dependencies on msvcrt.dll. This helps when installing libraries from binary distributions which depend on this CRT library.

@hkaiser,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Glad this wasn't too tough to do, looks good!
I think you originally had the logic inverted for what CRT regexes to use, so I switched that back. I also made it a separate static variable, since within the same execution of vcpkg.exe we might build multiple packages with different settings -- those static vectors should really be const.
Finally, I added the plumbing into scripts\ports.cmake so portfiles can use the cmake variable and have it properly exported out to the intermediate file.

Thanks!


Remove NPM Community

Site no longer exists (everything was moved to github discussions)

Thanks for your contribution!


check name for illegal values during tus uploads

The code was not checking for invalid file names during uploads and moves.

@phil-davis, are those supposed to be issue demonstrations?
apiOcisSpecific/apiWebdavMove1-moveFolder.feature:20
apiOcisSpecific/apiWebdavMove1-moveFolder.feature:31
apiOcisSpecific/apiWebdavMove1-moveFolder.feature:42
apiOcisSpecific/apiWebdavMove1-moveFolder.feature:53
apiOcisSpecific/apiWebdavMove1-moveFolder.feature:64
apiOcisSpecific/apiWebdavMove2-moveFile.feature:22

What should I do with those tests now? Delete them?

What should I do with those tests now? Delete them?

https://drone.cernbox.cern.ch/cs3org/reva/2304/6/6
HTTP status code 400 is not one of the expected values 201 or 500
I guess those tests were returning 500 and now return 400 - an improvement. But it looks like they should be able to really work and return 201.
IMO adjust the expectation to Then the HTTP status code should be "400" to "record" the current behavior.
Then someone needs to review all those "local" API tests to see what use they are. We have expected-failures files these days, that keep track of what core tests are known to be failing.

HTTP status code 400 is not one of the expected values 201 or 500
I guess those tests were returning 500 and now return 400 - an improvement. But it looks like they should be able to really work and return 201.

Not quite right. They were returning 201 (ocis storage) or 500 (eos storage) but should have been returning 400 because the scenarios are testing illegal behavior like renaming files/folders to contain invalid characters.
So I think those tests can be removed now, right?

So I think those tests can be removed now, right?

True - there are core scenarios in core apiWebdavMove1/moveFolder.feature like:
Scenario Outline: Renaming a folder to a backslash should return an error
Those get run in the usual core API test pipelines.
Remove these "local" API tests.

@C0rby should we also add these checks for copy?

That's a good point. Let me check if copy is also affected.

Yes, I added the check to COPY and MKCOL.