[Discussion] Immutable defaults for mutable JS API:s

Following the discussion about immutable defaults in https://forum.rescript-lang.org/t/ann-rescript-core-a-new-batteries-included-drop-in-standard-library/4149, let's discuss which API:s are problematic and what we can do to remedy that.
First off, there's a few things we need to keep in mind in this discussion:

A goal is to stay close to the JS API:s (deliberately not saying "as close as possible", but close). This means we have wiggle room to brush over inconsistencies and "improve" the JS API:s we bind to so they make more sense for idiomatic ReScript usage, where it makes sense. But a complete overhaul of API:s isn't something we'll pursue for Core. Not everyone is going to agree with this, and that's fine. But that's the way forward for Core.
For full immutability, Belt is still a great alternative, and Belt isn't going anywhere, it'll keep being around.

With that said, providing immutable defaults where it makes sense is definitively a good idea. So, let's detail what API:s are problematic right now. Please write down the API:s with mutability you worry about, and we'll discuss what we can do about it, if anything.
Let's also discuss what we can do about the mutable API:s to make it apparent that they're mutable. A few things come to mind:

Return unit always, even if the underlying JS API returns itself mutated. One example for this is Map.set which mutates and returns itself. This would return unit instead to signify that it's mutating.
Naming. This is already the case, suffixing functions mutating the original thing with inPlace. We can check that that's consistent.
Doc strings. Have a bolded **This mutates the original array** on top of each doc string, plus suggesting the immutable alternative. This will make it very apparent that you're using a mutable API as you're working in your editor.

Also, there's https://github.com/tc39/proposal-change-array-by-copy. The question is how far we should go from the JS API

From perspective of a ReScript module API, making dangerous functions more visible is good, but I’m not sure if it’s good enough. When a module Foo has no mutating methods, you have a strong guarantee that Foo.t is immutable, and the invariant new value == new ref is enforced. Which have consequences for pattens that take advantage of this invariant, e.g. the React hooks with dependencies arrays.
But when you simply discourage mutating, say, arrays, instead of completely ruling it out, you don’t have those guarantees. In a team of app developers that have other things on their mind than just remembering not to mutate things, you’d probably at least want a linter to strongly discourage calling *inPlace functions. And I think a totally immutable Array module (with a way to copy-and-convert from/to a mutable array) is safer than a linter.
That said, it’s rather weird to omit bindings when binding to Array.prototype, and a totally immutable Array module might actually belong in Belt.

Return unit always, even if the underlying JS API returns itself mutated. One example for this is Map.set which mutates and returns itself. This would return unit instead to signify that it's mutating.

I’m torn on this. I like the idea of clearly separating getters and setters, but then bindings like this are not true to the underlying API, which might be too opinionated for a standard JS lib, and I bet some people are going to miss the chained calls those return values enable.

A goal is to stay close to the JS API:s

I totally agree going on this direction, for me it's more important to be able to use the real JS api, and be consistent with the real JS api, than having some pure immutable layer, and for several reasons including performance and porting existing JS code.
Javascript it's mixed, in the sense that has both mutable and immutable APIs, in the case of Array, for example one cannot expect expect to be close to JS without mutability.

Return unit always, even if the underlying JS API returns itself mutated. One example for this is Map.set which mutates and returns itself. This would return unit instead to signify that it's mutating.

This makes sense even though there are some benefits like chaining, it's clearer to leave mutable operations as unit
Naming. This is already the case, suffixing functions mutating the original thing with inPlace. We can check that that's consistent.
I would prefer to be consistent with JS api if one really cares about the JS ecosystem, it may be consistent with rescript ecosystem, but not with JS.
Being consistent with JS apis will also allow to have better tools for generating rescript bindings from typescript/javascript

Fo example Scala.js has a set of both mutable and immutable collections, while also keeping the JS Arrays one for interop, and their JS api the closest to native JS, because they have plenty of their own Scala standard library without having to sacrifice any JS api consistency.

That said, it’s rather weird to omit bindings when binding to Array.prototype, and a totally immutable Array module might actually belong in Belt.
Yeah this pretty much sums it up well I think. We're trying to stay close to the JS array API, which is ultimately what we're binding to, not just as a backing structure. An immutable array module is of course very welcome in Belt, or as something standalone.

I haven't really made up my mind yet, but I want to share where I'm coming from and what my thoughts are to facilitate further discussion:
My hope / expectations for a new rescript standard library has been a "full-fledged belt-like" lib embracing functional idioms.
I understand this is a non-goal of Core and absolutely see the necessity to have all JS bindings in one place and well documented.
Regarding immutability:
I don't have an issue per se with immutable APIs being present in Core.
I guess for me, it's all about positioning Core and setting expectations:

Core are mainly bindings to vanilla js?
But not exclusively?
What's the maximum desired deviation from vanilla JS bindings?
What's the guideline for deciding what to include and what's too far off?
If Core were just bindings, the distinction on what to include here and in another "higher order" lib would be obvious. Including parts of Belt and other handy functions (but not bindings) blurs the line further.
It would be technically possible to provide two distinct api surfaces: mutable / immutable - but this would unnecessarily split up the js bindings, therefore I don't like this approach. Duplicating APIs is even worse in my opinion.
I'm also thinking about what would be the next step forward for a "functional immutable standard lib"? Would it make sense to vendor Core or use it as a dependency?

I'm aware this is becoming slightly off-topic, but I think the implications are pretty relevant to the discussion.

@woeps I'm guessing you saw this https://github.com/rescript-association/rescript-core#guiding-principles?

hoichi has a good point ‘
When a module Foo has no mutating methods, you have a strong guarantee that Foo.t is immutable’
What about keeping the api very close to the original js (without a few small tweaks to remove warts etc.. eg returning unit for mutation) and separate immutable datatypes eg as per tc39 proposal.  https://github.com/tc39/proposal-record-tuple

Yes, that's the best way forward here. Array binds to JS array, which is mutable, the same way that Set binds to the mutable JS Set. For immutable sets, we have Belt.Set. For immutable arrays, if there's demand for it and we have contributors willing to put in the work to build it, we could have either Core.ImmutableArray or Belt.ImmutableArray, depending on where we want to draw the line for what is included where.

I would be down to try and implement this.
I have some questions I would like feedback on first.
Where does this go?
Should it be in Belt or Core?
My thoughts are we could have Core.ImmutableArray that has most of the same functions as Core.Array but it just doesn't mutate things and returns a copy of the original array. That would leave room for us to do something like Belt.List  for a more custom data type. Same thing for Core.ImmutableObject and something like Belt.Record. I took names from Immutable.js for these and was thinking of using that as a starting point? That could come later so it doesn't need to be decided now. We could also wait for Tuple and Record to be added to JS.
What should ImmutableArray and ImmutableObject do?
Should ImmutableArray only have immutable versions of mutable array functions like set? Or should it have most of the same functionality as Array? Should it follow a different design and be like an Immutable.js List?
Should Array and ImmutableArray be compatible?
I don't think you should be able to swap functions on these two and that they need distinct types. We could add functions to convert from one to the other like ImmutableArray.fromArray and Array.fromImmutableArray that would allow you to swap if needed.
How do you make an ImmutableArray?
If we want to do this without adding any syntax to the language I think we can use ImmutableArray.of([1,2,3]) to create one.

Technically, it's possible to have a single set of bindings that map closely to the JS API, and also have a subset of them work on a distinct immutable array type, by adding a phantom type argument.
// Instead of
type array<'a>

// we add a phantom type argument to specify mutability
type array<'mut, 'a>

// then a couple of abstract phantom types to put there
type mut
type imm

// and now you can define functions that work on every kind of array, or just one kind
@get_index external get: (array<_, 'a>, int) => option<'a> = "" // can be called on any kind of array
@set_index external set: (array<mut, 'a>, int, 'a) => unit = "" // can only be called on mutable arrays

Not saying this is a good idea, there are certainly significant downsides to it, like making the types and type error messages more complicated, but it does make for a smaller API surface and is quite intuitive I think.

Wouldn't that mean that while my call of set wouldn't mutate the value, but another call of that function could mutate it? I think that's why I like the idea of types. But in theory we could some up with a way to share the functions that are duplicated on each? Maybe some type of InternalArray that we don't export and use in Array and ImmutableArray.

Not sure what you mean. set mutates. On every call. But it can only be called on arrays that are tagged as mutable. A set function that makes a copy instead of mutating would have to live elsewhere, but that also goes with the idea of having the Array module stick close to the JS array API. You could instead have an Array.Immutable module with immutable versions of the mutable bindings though.

Sorry I wasn't clear.
If you have an Array.set function that mutates an array<'a> you wouldn't want to be able to pass it to an Array.Immutable.set function.
I think there should be a clear distinction between an array and an immutable array.

Technically, it's possible to have a single set of bindings that map closely to the JS API, and also have a subset of them work on a distinct immutable array type, by adding a phantom type argument.
// Instead of
type array<'a>

// we add a phantom type argument to specify mutability
type array<'mut, 'a>

// then a couple of abstract phantom types to put there
type mut
type imm

// and now you can define functions that work on every kind of array, or just one kind
@get_index external get: (array<_, 'a>, int) => option<'a> = "" // can be called on any kind of array
@set_index external set: (array<mut, 'a>, int, 'a) => unit = "" // can only be called on mutable arrays

Not saying this is a good idea, there are certainly significant downsides to it, like making the types and type error messages more complicated, but it does make for a smaller API surface and is quite intuitive I think.

The issue with that is going to be variance.
Immutable arrays are covariant, and mutable ones are invariant (no subtyping at all).
I don't think the language lets you have both in one definition.

As for where this should live, there was talks a while ago about a separate package dedicated to ReScript data structures, where this and several other things would fit well. Might be good to start with that, and then we can decide on where it should live more long term when it's tried and tested.

If you have an Array.set function that mutates an array<'a> you wouldn't want to be able to pass it to an Array.Immutable.set function.
I think there should be a clear distinction between an array and an immutable array.

That is is exactly what I'm proposing. There would be no array<'a>, but instead array<mut, 'a> and array<imm, 'a>. Array.set would take only the former, Array.Immutable.set would take only the latter, and Array.get would take either.

The issue with that is going to be variance. Immutable arrays are covariant, and mutable ones are invariant (no subtyping at all). I don't think the language lets you have both in one definition.

Can you illustrate the issue with an example? If I understand correctly, covariance would just mean that if 'a is a subtype of 'b, then array<'a> is also a subtype of array<'b>, while if it's invariant that relation wouldn't transfer? And in practice just means you'd have to map it?

The issue with that is going to be variance. Immutable arrays are covariant, and mutable ones are invariant (no subtyping at all). I don't think the language lets you have both in one definition.

Can you illustrate the issue with an example? If I understand correctly, covariance would just mean that if 'a is a subtype of 'b, then array<'a> is also a subtype of array<'b>, while if it's invariant that relation wouldn't transfer? And in practice just means you'd have to map it?

Yes that's what it means.
Combining both kinds of arrays in one type would give up the opportunity to make immutable ones covariant.
This has come up a number of times, an it seems that having covariance is desirable.

We'll need a way to convert a regular array into an immutable array. How would I go about that? The types from the input don't let me just take in an array and return it as an immutableArray.

We'll need a way to convert a regular array into an immutable array. How would I go about that? The types from the input don't let me just take in an array and return it as an immutableArray.
Nevermind, I just needed a .resi file.

You can't convert a mutable array to an immutable one without making a copy. It's unsafe.

Same for the other way round.

The issue with that is going to be variance. Immutable arrays are covariant, and mutable ones are invariant (no subtyping at all). I don't think the language lets you have both in one definition.

Can you illustrate the issue with an example? If I understand correctly, covariance would just mean that if 'a is a subtype of 'b, then array<'a> is also a subtype of array<'b>, while if it's invariant that relation wouldn't transfer? And in practice just means you'd have to map it?

I did not really answer your question: why it matters.
And empty mutable array is tricky with typing. Just like references.
An immutable one is not.
That's just one example.
Another one: how comes I can't type coerce array of this record to array of that record? (Question people asked). Because arrays are not covariant.

Ok, I based it off from the work done here in this thread: https://forum.rescript-lang.org/t/immutable-array-implementation/761
module Array: {
  /* Put this in the interface file */
  type t<'a>
  let make: array<'a> => t<'a>
  let isEmpty: t<'a> => bool
  let head: t<'a> => option<'a>
  let tail: t<'a> => t<'a>
  let toArray: t<'a> => array<'a>
  let map: (t<'a>, 'a => 'b) => t<'b>
  let concat: (t<'a>, 'a) => t<'a>
  let append: (t<'a>, 'a) => t<'a>
} = {
  /* Put this in the module file */
  type t<'a> = array<'a>
  let make = arr => arr->Array.copy
  let isEmpty = t => t->Array.length == 0
  let head = t => t->Array.get(0)
  let tail = t => isEmpty(t) ? [] : t->Array.slice(~start = 1, ~end = t->Array.length)
  let toArray = make
  let map = Array.map
  let concat = (t, a) => [a]->Array.concat(t)
  let append = (t, a) => t->Array.concat([a])
}

let t1 = [1,2,3]

let t2 = t1->Immutable.Array.make->Immutable.Array.head // no error
let t3 = t1->Immutable.Array.head // error

I'm going to clean this up and add more functions and some basic documentation.

The way I have it above it's not a zero cost binding. Trying to see if I can do that now.

The more I poke at this I don't think there is a way to have this pass directly to JS functions directly. There has to be a middle layer for these types to work and to not mutate the input values.
But that's something I might be able to improve on.

The more I poke at this I don't think there is a way to have this pass directly to JS functions directly. There has to be a middle layer for these types to work and to not mutate the input values.
But that's something I might be able to improve on.

On needs to decide what immutable means.
To some people it means: don't mutate. To other it means: make a copy for every single operations.
The former can be done with just omitting mutating functions. The latter cannot.

To me I would expect it not to mutate and to return a copy.

I did not really answer your question: why it matters. And empty mutable array is tricky with typing. Just like references. An immutable one is not.
That's just one example.
Another one: how comes I can't type coerce array of this record to array of that record? (Question people asked). Because arrays are not covariant.

Thanks for the examples! These problems aren't going to go away by adding a separate second-class immutable array type though. As long as the default is a mutable array, and that is what's used by all sorts of bindings and such, people are still going to stumble across these issues and get confused. And at that point, are these issues severe enough that they'll choose to switch over to an immutable array, converting to and from mutable arrays where needed and adapt to different usage patterns?

I did not really answer your question: why it matters. And empty mutable array is tricky with typing. Just like references. An immutable one is not.

That's just one example.

Another one: how comes I can't type coerce array of this record to array of that record? (Question people asked). Because arrays are not covariant.

Thanks for the examples! These problems aren't going to go away by adding a separate second-class immutable array type though. As long as the default is a mutable array, and that is what's used by all sorts of bindings and such, people are still going to stumble across these issues and get confused. And at that point, are these issues severe enough that they'll choose to switch over to an immutable array, converting to and from mutable arrays where needed and adapt to different usage patterns?

I don't think there are easy answers here either way.
Just pointing out things to take into account for the overall design.

I did not really answer your question: why it matters. And empty mutable array is tricky with typing. Just like references. An immutable one is not.
That's just one example.
Another one: how comes I can't type coerce array of this record to array of that record? (Question people asked). Because arrays are not covariant.

Thanks for the examples! These problems aren't going to go away by adding a separate second-class immutable array type though. As long as the default is a mutable array, and that is what's used by all sorts of bindings and such, people are still going to stumble across these issues and get confused. And at that point, are these issues severe enough that they'll choose to switch over to an immutable array, converting to and from mutable arrays where needed and adapt to different usage patterns?

That is a good point. Users would have to start with an mutable array, convert it to immutable, and then convert back to a mutable one. That is a pain, but it is something users already have to do when working with Immutable.js.
Implementation aside, what I think would be a good experience for the user would be the ability to create an Immutable array that is somehow still an array<'a> that you do pass to functions that expect an array, and that you could use non mutating Array functions on like Array.map and Array.get. You would not be able to use Array.set, but maybe we could add in Array.safeGet?

If it's an array<...> there's nothing stopping mutable array functions from mutating it.
If it's a copy of your immutable array you don't care, except when you get it back into immutable land you need to copy it again.
The only way to avoid that, is to store a mutable bit with the array. And fail at runtime if you try to mutate it. Not sure how useful that would be.

I'd rather like to have a compile error, than a runtime error.
Imho an immutable array is a "Data Structure" and should be chosen accordingly for the task at hand. It shouldn't be possible to use functions for Array and ImmutableArray interchangably.
ImmutableArray using a js array for it's runtime representation should be an implementation detail (opaque type) and not usable from outside of the module.
If I want to mutate an ImmutableArray I need to convert it to an array first. (implemented as copying the array and returning it typed as an array). This seems fine, since I'd need to do this anyway for any other datastructure.

If I want to mutate an ImmutableArray I need to convert it to an array first. (implemented as copying the array and returning it typed as an array). This seems fine, since I'd need to do this anyway for any other datastructure.

Yeah, the more I think about it the more I like the idea of a separate type for immutableArray<'a>.

Seems like what we really want is linear types, like Rust has. Though that wouldn't solve the variance issue either...

...some prompts...

The mutability lifecycles of the examples I provided can vary depending on the specific implementation and requirements of each game. However, I can outline some common scenarios where mutability is used differently in these games:

Minecraft:

Chunks: Chunks in Minecraft are typically immutable once generated. They represent a fixed portion of the game world and store information about the terrain and blocks. Once a chunk is generated, its contents are typically not modified. However, during world generation or when loading new chunks, mutable data structures may be used temporarily to populate the chunk before it becomes immutable.

Diablo III:

Components: In Diablo III's entity/component system, components are often treated as immutable. They represent different aspects of an entity's behavior or properties, such as position, health, or abilities. Components are stored in immutable arrays and shared across game systems. However, certain systems or gameplay events may require temporary mutability, such as when applying damage to an entity or modifying a component's state.

Celeste:

Replay Events: Celeste's replay system records player actions and game events as immutable events in an array. These events capture the inputs, positions, and other relevant data for precise replays. During the recording phase, the events are appended to the array in a mutable manner. However, once the recording is complete, the array becomes immutable and is used for subsequent replays.

FTL: Faster Than Light:

Event Queue: FTL uses an immutable event queue to manage the branching narrative and choices in the game. Events representing different narrative options or outcomes are stored in an immutable array-like structure. The game progresses by processing events from the queue, which can involve mutable operations like dequeuing or consuming events. However, once an event is processed, it remains immutable.

In these examples, the mutability lifecycles are often shaped by the need for data consistency, performance optimizations, and gameplay requirements. While immutability is favored in many cases, there are specific phases or operations where mutable structures may be used temporarily. These mutable phases typically serve purposes like world generation, real-time updates, or event processing. However, the overall design often aims to minimize mutability and leverage the benefits of immutability for performance, safety, and maintainability.

Technically, it's possible to have a single set of bindings that map closely to the JS API, and also have a subset of them work on a distinct immutable array type, by adding a phantom type argument.
// Instead of
type array<'a>

// we add a phantom type argument to specify mutability
type array<'mut, 'a>

// then a couple of abstract phantom types to put there
type mut
type imm

// and now you can define functions that work on every kind of array, or just one kind
@get_index external get: (array<_, 'a>, int) => option<'a> = "" // can be called on any kind of array
@set_index external set: (array<mut, 'a>, int, 'a) => unit = "" // can only be called on mutable arrays

Not saying this is a good idea, there are certainly significant downsides to it, like making the types and type error messages more complicated, but it does make for a smaller API surface and is quite intuitive I think.

I went ahead and tested this idea out.
For now I created a different type called _array<'a>, this could eventually just replace array<'a> but there would have to be some backwards compatibility?
// a.res
module Array: {
  type _array<'mut, 'a>
  type mut
  type imm

  @get_index external get: (_array<_, 'a>, int) => option<'a> = "" // can be called on any kind of array
  @set_index external set: (_array<mut, 'a>, int, 'a) => unit = "" // can only be called on mutable arrays

  @send
  external make: array<'a> => _array<mut, 'a> = "slice"

  @send
  external fromImmutable: array<'a> => _array<mut, 'a> = "slice"

  module Immutable: {
    @send
    external make: array<'a> => _array<mut, 'a> = "slice"
    let set: (_array<_, 'a>, int, 'a) => _array<imm, 'a>
  }
} = {
  type _array<'mut, 'a> = array<'a>

  type mut
  type imm

  @get_index external get: (_array<_, 'a>, int) => option<'a> = "" // can be called on any kind of array
  @set_index external set: (_array<mut, 'a>, int, 'a) => unit = "" // can only be called on mutable arrays

  @send
  external make: array<'a> => _array<mut, 'a> = "slice"

  @send
  external fromImmutable: array<'a> => _array<mut, 'a> = "slice"

  module Immutable = {
    @send
    external make: array<'a> => _array<mut, 'a> = "slice"

    let set = (a, i, v) => {
      let c = a->Array.copy
      c->Array.set(i, v)
      c
    }
  }
}

index.res
let t1 = [1, 2, 3]->A.Array.make
let t2 = t1->A.Array.get(0)
let t3 = t1->A.Array.set(0, 100)
let t4 = t1->A.Array.Immutable.set(0, 10) // array is now immutable

let i1 = [1, 2, 3]->A.Array.Immutable.make
let i2 = i1->A.Array.get(0)
// let i3 = i1->A.Array.set(10, "foo") // error
let i4 = i1->A.Array.Immutable.set(0, 10)

// a.mjs
// Generated by ReScript, PLEASE EDIT WITH CARE

function set(a, i, v) {
  var c = a.slice();
  c[i] = v;
  return c;
}

var Immutable = {
  set: set
};

var $$Array = {
  Immutable: Immutable
};

export {
  $$Array ,
}
/* No side effect */

// index.js
// Generated by ReScript, PLEASE EDIT WITH CARE

import * as A from "./a.mjs";
import * as Curry from "rescript/lib/es6/curry.js";

var t1 = [
    1,
    2,
    3
  ].slice();

var t2 = t1[0];

t1[0] = 100;

var t4 = Curry._3(A.$$Array.Immutable.set, t1, 0, 10);

var i1 = [
    1,
    2,
    3
  ].slice();

var i2 = i1[0];

var i4 = Curry._3(A.$$Array.Immutable.set, i1, 0, 10);

var t3;

export {
  t1 ,
  t2 ,
  t3 ,
  t4 ,
  i1 ,
  i2 ,
  i4 ,
}
/* t1 Not a pure module */

It feels easier to use than the separate ImmutabeArray<'a> type. My concern would be how to get the new array<mut, a>to be compatible with everything else and be backwards compatible. IIf I have a bunch of types in my files likelet t: array = [1,2,3]` how could that be dealt with without breaking existing code?

I was wondering where immutable data structures arise as a fundamental need. So I thought that if such a need exists, it would show up in games.
What I found is that Braid uses immutable keyframes  https://www.youtube.com/watch?v=8dinUbg2h70
What I could not find, is any examples of, say, arrays in real games that oscillate between mutable and immutable. So I don't know of that arising as a fundamental need, so far.

I think that need would mostly arise from wanting to use immutable arrays, and needing to interop with JS APIs which would expect (or are at least most safely typed as) mutable arrays.

My concern would be how to get the new array<mut, a>to be compatible with everything else and be backwards compatible. IIf I have a bunch of types in my files like let t: array = [1,2,3]` how could that be dealt with without breaking existing code?

The array type could just be an alias of an underlying general array type. E.g.:
module Array: {
  type t<'mut, 'a>
}

type array<'a> = Array.t<mut, 'a>

It's a pretty simple code mod if it is made a breaking change too though.

I think the simplest possible solution already teaches the top complexity budget justified by the need for this.
Any breaking changes or departures from the normal array API (except from removing the mutating functions) can be considered but it seems unlikely they'll get broad support and accepted.

While I think having array<mut, 'a> feels like a better long term solution, it seems like it would take more effort and community buy in.
Does this mean we should continue to look at using a separate implementation for immutable arrays, like Immutable.Array? Which would just be JS arrays that removes the mutation functions and replaces them with safe alternatives?

I opened up a PR over here to add an ImmutableArray. Docs still need to be sorted out, but I'll wait to clean those up until I know if this is something we want to add.


fix: use and expose reducibles

The reducible_dispatch function seems like it has a bug. Did you test it?


Support prepareUpgrade from an implementation address

Fixes #777

Wow that was fast. Awesome!!! We really need this.

@ericglau thanks a lot for this. Just to plan accordingly, any expected date or timeframe for this to be released?


spell fix

@avannaldas,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@nitinme Please review these proposed changes. Thanks.

#sign-off


TABLESPACE not recognized by autocompletion for PostgreSQL database

Hi,
This is just a minor issue, but I noticed that the TABLESPACE keyword is not recognized as a valid keyword by the autocompletion and thus not highlighted, even though table spaces are listed in the Database Navigator. This is with DBeaver 5.1.0 and PostgreSQL as the database connected.

The query executes without issues though.

Thanks for noticing


Set max concurrent uni streams accordingly -- do not over allocate open uni streams

Problem
We can over allocate max concurrent open uni streams than the total streams allowed within a throttle window.
For example, an unstaked node might be eligible for 2 uni streams per throttle window, but we might allocate the 128 concurrent uni streams for it.
This has two problems: allocating resources on the server side unnecessarily and allow the client to open concurrent uni streams which will be throttled on server side, more timeout error on client side and more load on the server side.
Summary of Changes
Do not allow more open concurrent uni streams than the one permitted in a throttle window.
Fixes #

Codecov Report
Attention: Patch coverage is 97.29730% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 82.1%. Comparing base (2bc026d) to head (d21dab8).
Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##           master    #1060     +/-   ##
=========================================
- Coverage    82.1%    82.1%   -0.1%
=========================================
  Files         893      893
  Lines      236600   236677     +77
=========================================
+ Hits       194429   194488     +59
- Misses      42171    42189     +18

Can we split the new functionality in its own struct, and add unit tests for the math?

Done.

Some nits. Otherwise the logic looks good to me.
Let's wait for @alessandrod to also take a look.

@alessandrod -- this is the formal change for the experiments we have done in '3gG' where we hard coded concurrent streams to 1 for unstaked connection based on the calculation of max allowed streams count per throttle window. This change makes the stream count limit to take the minimum of (original max current uni streams per stake, max allowed streams per throttle window).

Oops sorry I had missed this! I'll take a look in the morning

Hi @alessandrod , any further comments on this PR? I'd like to wrap it up

From what I understand, I don't think this code is needed, adds complexity and probably some round trips to communicate the new limit to peers. (And locking and wakeups of the connection task, but admittedly those should be infrequent). I could be wrong of course, but I haven't seen any plausible explanation of why this is needed (or multiple streams are needed to begin with).

From what I understand, I don't think this code is needed, adds complexity and probably some round trips to communicate the new limit to peers. (And locking and wakeups of the connection task, but admittedly those should be infrequent). I could be wrong of course, but I haven't seen any plausible explanation of why this is needed (or multiple streams are needed to begin with).

Can you clarify why it is not needed? I think you would agree over allocate is bad. If you are questioning why we have multiple streams in the first place. As I mentioned it is based on the thinking of reducing head of line issue and 2. for better performance using parallelism. And I mentioned in the slack channel that 1 stream vs the current default there is at least 3 times of difference in bench-tps test. Your point of multiple stream may cause fragmentations among the stream is a valid point. But it is orthogonal to this PR. I am not making it worse. If you are proposing just change stream count to 1 for everything, I am thinking it is too drastic change. Please explicit if you are proposing something different.

From what I understand, I don't think this code is needed, adds complexity and probably some round trips to communicate the new limit to peers. (And locking and wakeups of the connection task, but admittedly those should be infrequent). I could be wrong of course, but I haven't seen any plausible explanation of why this is needed (or multiple streams are needed to begin with).

Can you clarify why it is not needed? I think you would agree over allocate is bad.

Over allocate what? From what I understand - and again I could be wrong - we're not allocating anything more on the server side whether we allow 1 stream or 1000 streams. The max streams limit is a protocol limit that is communicated to the client. The server doesn't pre-reserve anything about it. Just the client will stop opening streams once it runs out of streams. Stream id tracking is done in the client, it requires no synchronization with the server.  We have one task per connection. We read one stream at a time - not in parallel: we pop the next stream from the connection and process it. What gets over allocated?
The thing that changes how much the server allocates is the receive window, and we already bound that.

If you are questioning why we have multiple streams in the first place. As I mentioned it is based on the thinking of reducing head of line issue and 2. for better performance using parallelism.

I thought we agreed on slack that there's no HOL issue? If you don't agreen, can you explain to me where the HOL issue is exactly?
And can you explain where the parallelism is, if the server has one task per connection and pops one stream at a time? How is parallelism increased exactly?

And I mentioned in the slack channel that 1 stream vs the current default there is at least 3 times of difference in bench-tps test. Your point of multiple stream may cause fragmentations among the stream is a valid point. But it is orthogonal to this PR. I am not making it worse.

You are adding code that I don't think is necessary. More code is always bad: more complexity and more bugs. In that sense, it's worse. Obviously I can be wrong, but I'd like to know how I'm wrong if you want me to approve the PR.

If you are proposing just change stream count to 1 for everything, I am thinking it is too drastic change. Please explicit if you are proposing something different.

I'm not proposing to set streams to 1 in the context of this PR. I do think we should do it, but as you said it's orthogonal to this PR and likely requires fixes in the client before we can do it.

From what I understand, I don't think this code is needed, adds complexity and probably some round trips to communicate the new limit to peers. (And locking and wakeups of the connection task, but admittedly those should be infrequent). I could be wrong of course, but I haven't seen any plausible explanation of why this is needed (or multiple streams are needed to begin with).

Can you clarify why it is not needed? I think you would agree over allocate is bad.

Over allocate what? From what I understand - and again I could be wrong - we're not allocating anything more on the server side whether we allow 1 stream or 1000 streams. The max streams limit is a protocol limit that is communicated to the client. The server doesn't pre-reserve anything about it. Just the client will stop opening streams once it runs out of streams. Stream id tracking is done in the client, it requires no synchronization with the server. We have one task per connection. We read one stream at a time - not in parallel: we pop the next stream from the connection and process it. What gets over allocated?

Lijun: To follow up. I mentioned in the PR description:
This has two problems: allocating resources on the server side unnecessarily and allow the client to open more  concurrent uni streams which will be throttled on server side, more timeout error on client side and more load on the server side. My simple intuition was: if we allow to max N streams in a throttle window, do not allow the max concurrent open streams to be more than N, as the ones exceeding that will be throttled anyway. Open uni streams does require allocating resources to maintain the states.


Sonoff devices not refreshing

I erased the sonoff.json file a couple of times and if I open the file I can see that the device I added is there, but when I go to the entities in Home assistant, I can't see it. Is there something more I can do?
Thank you!

This custom component doesn't use sonoff.json.

How do I refresh sonoff devices then?
On Sun, Apr 3, 2022, 8:30 PM Alan Tse @.***> wrote:

This custom component doesn't use sonoff.json.
—
Reply to this email directly, view it on GitHub
https://github.com/custom-components/alexa_media_player/issues/1552#issuecomment-1087047830,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APWALHSL7FCEBZVNMSNKBSLVDJH5HANCNFSM5SHFVEPQ
.
You are receiving this because you authored the thread.Message ID:
@.***>


Fix error when there is no "basket" defined

This is a simple change that removes an error if someone starts a django-oscar project and goes to the front page without adding any data.

Duplicate


Duplicated conditions in if expression inside uwac-display.c

https://github.com/FreeRDP/FreeRDP/blob/1a058ed8f650ff5cb748767608a9c265f90fd934/uwac/libuwac/uwac-display.c#L423

What's wrong with the fact that we wanna do 2 round trips ?

It may be a bug(but in this case, based on your comment, it is not).
Also some analyzers like Sonarcloud(which I used) may think that is probably wrong.
So if in this line is everything fine, then nothing needs to be changed, but it could be changed to prevent similar reports in the future.

Ok, closing as not an issue.


Bug fix - When generating nodes without datadump

Bug fix
Description:

Changed the names of the types for generated events to match the config.json file.
This mismatch was causing event types not to be recognized and therefore not displayed.

resolves #37

and therefore not displayed
Maybe the frontend needs a fallback event type, new event types may be added at any time.

and therefore not displayed

Maybe the frontend needs a fallback event type, new event types may be added at any time.

It would be safer yes. A possibility would be to include a check with a default node type. We will create an issue to address this.


go build main.go

./main.go:77:26: model.Train undefined (type *lstm.Model has no field or method Train)
???

Hello,
This repo is a work in progress,
Sadly I had no time recently to work on it recently.
As I was stuck with the LSTM implementation, I wrote a helper tool transcode the mathematical equation directly into code. This has been blogged here.
I will try to work on the example within this month.


Color coded maps for queries

In the QueryCard component the circle showing the area of the query should have a color representing the average network quality
Get the network quality by taking the average bandwidth, latency and signal strength, assign to them the appropriate value from the list below, and take the average
The colors should range from red -> orange -> yellow -> light green -> dark green
Fix color coding in pie chart as well

Value ranges:

Bandwidth: 0-99 (1), 100-499 (2), 500-999 (3), 1000-4999 (4), 5000+ (5)
Latency: 0-29 (5), 30-79 (4), 80-119 (3), 120-199 (2), 200+ (1)
Signal strength: null or 0 (1), 1  (2), 2 (3), 3 (4), 4 (5)

Extra:

Adjust the mock generator to generate numbers more suited to this range, so latency 1-250, bandwidth 0-10000

Due to high variation in data this would almost always show yellow for average, thus is an insufficient visualization.


Upstream web support for IterableProperty

Description
table_rendering_test uses IterableProperty which fails on web platform due to default double.toString() behavior. This PR updates diagnostics to use debugFormatDouble to support web platform.
Related Issues
#37491
Tests
I added a test in diagnostics_test.dart for IterableProperty.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[x] I signed the [CLA].
[x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (Please read [Handling breaking changes]). Replace this with a link to the e-mail where you asked for input on this proposed change.
[x] No, this is not a breaking change.


Category model doesn't considered as having relationship

I use Kyslik/column-sortable for handling column sorting in Laravel 5.[5-7].
But the issue here is your Category model doesn't considered as having relationship like hasOne or belongsTo.
Of course I have added these functions to my Models in order to work-around the problem but the fact is, it only hides the try/catch errors. No functionality at all.

I think packages is using cached categories and you will get null (or a hardcoded relation model)

I'm not sure about the above package, but our categories package is working fine with https://github.com/spatie/eloquent-sortable
If you believe there's something we can improve in this package, feel free to submit a PR 🙂


resolves #483 fix test against upstream

update script to handle new gemspec contents
only run upstream test on first job in build

This pull request solves some errors, but reveals others. It will also need to be applied against the 1.6.0 branch.

Strange thing is that the upstream build worked for me locally also before this PR.
Great that the travis is green again finally!

Cherry-picked into asciidoctorj-1.6.0 as f27691fe8c9537cf88a802c0a38166f2e624e394

Almost green ;)
I want to clarify that this was an issue related specifically to JRuby 1.7, which doesn't implement a method option I was using the the gemspec. However, I applied a fix that will work for all Rubies, so it should be very safe now. :+1:

It appears we get a test failure on AsciidoctorJ on AppVeyor. We should enable the flag that reports the test failures on the commandline so we can see them. The other option is to define the test reports as artifacts, which AppVeyor makes available in the workspace after the build.
For example:
artifacts:
  - path: **/build/reports/tests/**

It seems to fail here: https://github.com/asciidoctor/asciidoctorj/blob/asciidoctorj-1.6.0/asciidoctorj-distribution/src/test/groovy/org/asciidoctor/diagram/WhenDitaaDiagramIsRendered.groovy#L84
Seems like the first test or the when has failed so that png is not initialized. Wonder why Spock doesn't report that.
Could be this one: https://github.com/jruby/jruby/issues/3957
This test was specifically made to catch such errors :-)

This test was specifically made to catch such errors :-)

At least we can take comfort in the fact that its a meaningful failure ;)


Upgrade parachain to Polkadot 0.9.16

same revisions as snakenet to ensure storage compatibility
target branch: hydra-parachain https://github.com/galacticcouncil/HydraDX-node/tree/hydra-parachain

@lumir-mrkva same revisions as in the latest release? https://github.com/galacticcouncil/HydraDX-node/releases/tag/v11.2.0


Added ReferenceFile trait, modified TwoBitFile to extend it

Can one of the admins verify this patch?

Jenkins, add to whitelist.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/623/Build result: FAILUREGitHub pull request #607 of commit 8857f36ab298d8c4de5d1f14595b45de39614246 automatically merged.Notifying endpoint 'HTTP:https://webhooks.gitter.im/e/ac8bb6e9f53357bc8aa8'[EnvInject] - Loading node environment variables.Building remotely on amp-jenkins-slave-01 (centos) in workspace /home/jenkins/workspace/ADAM-prb > git rev-parse --is-inside-work-tree # timeout=10Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/bigdatagenomics/adam.git # timeout=10Fetching upstream changes from https://github.com/bigdatagenomics/adam.git > git --version # timeout=10 > git fetch --tags --progress https://github.com/bigdatagenomics/adam.git +refs/pull/:refs/remotes/origin/pr/ > git rev-parse origin/pr/607/merge^{commit} # timeout=10Checking out Revision 721e3a6cee054c461e9c0e8674c1d53e527c1e12 (detached) > git config core.sparsecheckout # timeout=10 > git checkout -f 721e3a6cee054c461e9c0e8674c1d53e527c1e12 > git rev-list f260cb8edca472db9423a4964cc659f235caddd3 # timeout=10Triggering ADAM-prb » 2.2.0,centosTriggering ADAM-prb » 2.3.0,centosTriggering ADAM-prb » 1.0.4,centosADAM-prb » 2.2.0,centos completed with result FAILUREADAM-prb » 2.3.0,centos completed with result FAILUREADAM-prb » 1.0.4,centos completed with result FAILURENotifying endpoint 'HTTP:https://webhooks.gitter.im/e/ac8bb6e9f53357bc8aa8'
Test FAILed.

I'm fine with this. @ananth-pallaseni: are you implementing another alternative to a 2bit file?
Looks like there may also be formatting problems?  Try running scripts/format-source

@laserson some testing work for RNAdam. Essentially, we need to mock a 2bit file.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/629/Build result: FAILUREGitHub pull request #607 of commit c65cc3c97d6f9f7d8291cabe5cfe438699e8c000 automatically merged.Notifying endpoint 'HTTP:https://webhooks.gitter.im/e/ac8bb6e9f53357bc8aa8'[EnvInject] - Loading node environment variables.Building remotely on amp-jenkins-worker-05 (centos) in workspace /home/jenkins/workspace/ADAM-prb > git rev-parse --is-inside-work-tree # timeout=10Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/bigdatagenomics/adam.git # timeout=10Fetching upstream changes from https://github.com/bigdatagenomics/adam.git > git --version # timeout=10 > git fetch --tags --progress https://github.com/bigdatagenomics/adam.git +refs/pull/:refs/remotes/origin/pr/ > git rev-parse origin/pr/607/merge^{commit} # timeout=10 > git branch -a --contains aa2ba610e6747abebb15a49f5d7330895423b812 # timeout=10 > git rev-parse remotes/origin/pr/607/merge^{commit} # timeout=10Checking out Revision aa2ba610e6747abebb15a49f5d7330895423b812 (origin/pr/607/merge) > git config core.sparsecheckout # timeout=10 > git checkout -f aa2ba610e6747abebb15a49f5d7330895423b812First time build. Skipping changelog.Triggering ADAM-prb ? 2.2.0,centosTriggering ADAM-prb ? 2.3.0,centosTriggering ADAM-prb ? 1.0.4,centosADAM-prb ? 2.2.0,centos completed with result FAILUREADAM-prb ? 2.3.0,centos completed with result FAILUREADAM-prb ? 1.0.4,centos completed with result FAILURENotifying endpoint 'HTTP:https://webhooks.gitter.im/e/ac8bb6e9f53357bc8aa8'
Test FAILed.


[REVIEW]: Open Source Projects

Please review my projects:-

Instagram Clone-  https://github.com/mihir0699/Instagram-Clone
Polling Website- https://github.com/mihir0699/Insta-Poll

Thanks for sharing. Please edit your post to include only one project link as we typically review only one per issue.

Some suggestions:

add a contributing.md
add a code-of-conduct
add issue und pr templates
add a release
use issues and pull requests may take advantage of the project feature of GitHub to tell others what features are in progress

Thank you for updating your post- we will review on a live stream as time allows :)

Reviewed on live stream https://www.youtube.com/watch?v=XT3_O4jULRE

looks great, love the screenshots in the readme, description and link 👍
suggest using releases/tags
suggest hiding packages and wiki if not used
use issues with labels even if just you working on the project, so your project can get discovered
missing code of conduct, check insights-> community link to create using a GitHub template
there are build and test commands in the package.json, suggest adding these to a GitHub Action


chore: Update dependencies

Update make-dir to the version which will use native recursive mkdir, update devDependencies so npm audit shows clean.

Pull Request Test Coverage Report for Build 53

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 51:
0.0%

Covered Lines:
47

Relevant Lines:
47

💛  - Coveralls


Fix Data file read error

Add Sample applicants

Codecov Report

Merging #106 (52b48f8) into master (35a9b4e) will decrease coverage by 0.08%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master     #106      +/-   ##
============================================
- Coverage     76.77%   76.69%   -0.09%
  Complexity      566      566
============================================
  Files            89       89
  Lines          1800     1802       +2
  Branches        220      221       +1
============================================
  Hits           1382     1382
- Misses          350      352       +2
  Partials         68       68

Impacted Files
Coverage Δ

.../java/seedu/address/model/util/SampleDataUtil.java
14.28% <0.00%> (-1.51%)
:arrow_down:

Continue to review full report at Codecov.

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

Changed the isValid methods in JobId, Qualification and InterviewDate to take in "PENDING" value as valid
All 3 classes will display "PENDING" if isInit = false
Constructors for all 3 classes will take in a "PENDING" as argument, generate an instance of the class that is not initialised (isInit = false)


Add the coverage badge

I think the first will always be passed, is it useful?

Codecov Report

Merging #1180 into master will decrease coverage by 12.26%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master    #1180       +/-   ##
===========================================
- Coverage   43.50%   31.23%   -12.27%
===========================================
  Files         140      105       -35
  Lines       15246     9863     -5383
===========================================
- Hits         6633     3081     -3552
+ Misses       8025     6489     -1536
+ Partials      588      293      -295

Flag
Coverage Δ

#integration-tests
31.23% <ø> (+0.02%)
:arrow_up:

#unit-tests
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/agent/proxy/service.go
0.00% <0.00%> (-100.00%)
:arrow_down:

pkg/ovs/ovsconfig/default.go
0.00% <0.00%> (-100.00%)
:arrow_down:

pkg/agent/proxy/endpoints.go
0.00% <0.00%> (-84.10%)
:arrow_down:

pkg/agent/util/iptables/lock.go
0.00% <0.00%> (-83.34%)
:arrow_down:

...kg/agent/flowexporter/connections/conntrack_ovs.go
0.00% <0.00%> (-76.15%)
:arrow_down:

pkg/cni/client.go
0.00% <0.00%> (-75.00%)
:arrow_down:

pkg/agent/flowexporter/connections/conntrack.go
0.00% <0.00%> (-68.19%)
:arrow_down:

pkg/agent/querier/querier.go
0.00% <0.00%> (-64.29%)
:arrow_down:

pkg/agent/config/traffic_encap_mode.go
43.47% <0.00%> (-56.53%)
:arrow_down:

pkg/agent/proxy/proxier.go
0.00% <0.00%> (-40.51%)
:arrow_down:

... and 50 more

Can we make sure we incorporate coverage from the e2e tests before we display the badge?

Can we make sure we incorporate coverage from the e2e tests before we display the badge?

Sure, let's make #1160 be merged first.


Repo sync for protected CLA branch

The pull request is created from master637346653723847641 to master to fix git push error for protected CLA branch

@ghogen : Thanks for your contribution! The author(s) have been notified to review your proposed change. @evanwindom


Script to organise out-of-order pages in a  PDF File.

Aim

At times we get a pdf that is not ordered properly but we know the pages which have are out of order and it is tough to reorder it with an Android PDF app or windows app.
This script will make it easy to reorder your pages in a PDF with just one click.

Details

A python script that will take an input of pages which are unordered and where these unordered pages should go Example input:-

1,2
3,1
2,3
here the 1st page in the pdf should be on the 2nd page instead and so on
and parse it into dictionary.

Using this dictionary and a python library called 'pdfrw' I will reorder the PDF.

I would want to work on this issue for SWOC in python please assign it to me!

I would want to work on this issue for SWOC in python please assign it to me!


Donation proposal: OpenTelemetry Go Automatic Instrumentation

Description of donated project
This project adds OpenTelemetry instrumentation to Go applications without having to modify their source code.
Instrumentation is done by using eBPF uprobes.
Automatic instrumentation is available for a wide range of Go applications: Go version 1.12 and above, in addition to supporting stripped binaries (compiled with go build -ldflags "-s -w")
Instrumented libraries follow the OpenTelemetry specification and semantic conventions to produce standard OpenTelemetry data.
GitHub repos:
https://github.com/keyval-dev/opentelemetry-go-instrumentation
https://github.com/keyval-dev/offsets-tracker (used by this project, can also be donated if needed)
A detailed technical explanation is documented here.
Summary of existing usage of donated project
This project is a core part of keyval's product and production systems.
We are using this instrumentation successfully on many Go applications including multiple popular open-source Go projects.
Benefits to the OpenTelemetry community
OpenTelemetry Adoption
Go is the most popular programming language in the CNCF landscape (see DevStats)
Providing automatic instrumentation for Go applications would allow projects without the resources needed for implementing manual instrumentation to easily adopt OpenTelemetry.
Alignment
Currently, automatic instrumentation exists for Python, .NET, JavaScript, and Java. Our goal is to provide the same level of automatic instrumentation for Go applications. We hope this project will lead the way for automatic instrumentation for other compiled languages such as Rust and C++ which may also be implemented using eBPF.
Security
Running eBPF programs requires elevated privileges. We believe that being part of the OpenTelemetry community would make users more comfortable using this project.
Maintenance plan
Keyval will continue to maintain this project and we welcome the opportunity to work with more contributors.
Multiple developers in the OpenTelemetry community (from Go SDK SIG, Operator SIG & eBPF SIG) and in the eBPF community have expressed interest in contributing to this project.
Our current roadmap contains the following tasks:

Adding more instrumentations (with PostgreSQL and MySQL coming soon)
Integration with Go manual instrumentation
Better goroutine id tracking (supporting more complex scenarios)
Add Go as part of automatic instrumentation done by OpenTelemetry Operator - In Progress
Context propagation
Metrics support

Existing software license(s)
This project is licensed under the terms of the Apache 2.0 open source license.
List of trademarks (if any)
None

I've tranfered this issue. We can close this when the donation has been merged. Thanks, @edeNFed

Opened #4

@edeNFed The go-instrumentation uses https://github.com/keyval-dev/offsets-tracker to generate offset_results.json, I believe that is the critical input to the code. What are your thoughts , on how this work once the code is merged ?
Ideally , i believe offsets-tracker should be part of open-telemetry , but would be like to know your thoughts .

Hi @dineshg13 I totally agree (I mentioned the offset tracker repo in the original donation proposal). Not sure if this is needed as a first step but ultimately I also think this should be owned by the community.

Thanks @edeNFed , i don't think it is necessary as a first step. We can add it to our roadmap

Closing issue as PR is merged.


Match: support for supplying multiple app identifiers at once

this  is a rebased version of https://github.com/fastlane/fastlane/pull/6080 - as there is no activity for many days. - original commit is preserved.
i would like to see this feature in match.

ok closed this - as i saw the original  PR just has not yet been reviewed - sorry


Removed NPM dependency yoctocolors by replacing it with styleText function from node:util

Pull Request Checklist

[x] Readme and changelog updates were made reflecting this PR's changes
[x] Increase the project version number in package.json following Semantic Versioning

Changes Included

Version bump to 1.0.7
Removed NPM dependency yoctocolors by replacing it with styleText function from node:util
Replaced .length string length calculation with Bun.stringWidth() where unicode and emoji character usage is possible
Bun target version updated to 1.0.31

Waiting for @types/bun dependency to get updated to add styleText from node:util


Generate UID links for blacklisted user "why"

Coverage remained the same at 65.422% when pulling 4c47a57133da93cd56d0745e9594f8999abe9c66 on iBug:patch-2 into 31f68c692364e4a74c28f4c850bac1a009f00e1a on Charcoal-SE:master.

post.post_id is the post that's being scanned, not the post that the user was being blacklisted for

the proper fix is to store site, postid instead of the URL really

So is this incorrect now? I like the idea.

The easy way to do it in this instance would be to just pull the related post ID out of the link - write a regex that takes a link and matches the ID in it.

@ArtOfCode- In fact, I'm planning to do it with regex when I have time.


Add workflow to release chart and expose via GitHub Pages

This workflow makes use of the helm/chart-releaser-action which will automatically create a git tag whenever the the chart version changes.
This will cause a release to be deployed under your releases with a referenced tgz of the chart (example). After that, the action will create/update and index.yaml on the gh-pages branch (example) and allow people to use helm repo add meilisearch https://meilisearch.github.io/meilisearch-kubernetes
Note:
You'll want to create a gh-pages branch first before merging this. You can create an empty branch like this:
git checkout --orphan gh-pages
git rm -rf .
I also created an index.md (example) which you could use to add some instructions. Here's what it could like.
Once you push the new branch, then modify the repo settings to be like:

Then all should be good 🙈
Resolves #13

Thanks a lot for this contribution @carlreid! 🎉
The gh-pages branch is created with your example index.html that we can make evolve when everything is set. Can you confirm that everything is in place?

Just to be clear, I used an index.md. Might be better to use a markdown file if you want it "README" like, though I think a html file will be fine.
But otherwise yes, it should just work fine. You can check the action run and such on my fork. Nothing else needs to be changed 😊

Sure! Indeed, it would be preferable to use markdown, and we will populate it and make it look nicer :)
I'll change this and merge the PR!
Thanks again! 🎉 🎉 🎉

Bors merge

Bors merge

@eskombro Seems to be working great, also good job on the better looking index.md 😄 Thanks for reviewing so quickly 👍

Hello @carlreid!
Thanks a lot for your PR!! 👍
Do you have a Twitter account? We really would like to highlight your work with the MeiliSearch account! 😄

@curquiza Sure would be an honor, I have @carl__reid though as you can see, I'm not so active 😆 Otherwise feel free to tag my GitHub profile 👍

@eskombro Seems to be working great, also good job on the better looking index.md 😄 Thanks for reviewing so quickly 👍

Great, I was surprised with the timeout for merging, but seems to be a Bors problem. I just tested everything and works perfectly! Thanks 🚀


Add check for deploy freeze when triggering downstream deploy

This adds a step to the Deploy_App_Downstream job to query the Release app and prevent deployments if the deploy freeze attribute is true.

Script looks good 👍. Can we move it to its own step, before the sleep/Smokey step? I think it makes sense to abort early for this check; we benefit from doing the commit checks a bit later as they also debounce deployments for a string of PRs merged around the same time.

Sure thing!


Record field documentation doesn't align with field name

As can be seen in the screenshot below (look for flushInterval) the record field documentation doesn't always align with the field name.

$ haddock --version
Haddock version 2.14.2, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008

Getting
 to display like a table involves compromises: you have to fix the width of one of the columns and if the content overflows that width something bad will happen.  In this particular case, the text pushed the other column downwards.
I suggest scrapping
 entirely and replacing it with something like:

<dfn>host :: !Text</dfn> Server hostname or IP address

<dfn>port :: !Int</dfn> Server port

  …

and then use display: table-row and display: table-cell to tabularize them.


Skilling Calculators - Obsidian Redesign

Redesigned the skilling calculators, everything important should be listed on the commit message.

Added second constructor to the material tab group
Refactored the IconTextField to include the FlatTextField

@deathbeam we good?

Fixed two typos on the code:

Accidental parenthesis on the mouse listener
Accidental parenthesis (again) on the skill calc combined actions panel


MIC-427 Rewrite record-investigation/**/tests into cypress tests

./journeys/record-investigation/evidence-secured/tests.test.ts
./journeys/record-investigation/protective-factors/tests.test.ts
./journeys/record-investigation/staff-involved/tests.test.ts
./journeys/record-investigation/start/tests.test.ts
./journeys/record-investigation/tests.test.ts
./journeys/record-investigation/triggers/tests.test.ts
./journeys/record-investigation/usual-behaviour-presentation/tests.test.ts
./journeys/record-investigation/why-behaviour-occurred/tests.test.ts

re-written above tests into tests.cy.ts

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

Project coverage is 74.01%. Comparing base (248a026) to head (9753301).

Files
Patch %
Lines

...investigation/why-behaviour-occurred/controller.ts
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #139      +/-   ##
==========================================
- Coverage   75.35%   74.01%   -1.35%
==========================================
  Files         166      166
  Lines        2313     2313
  Branches      377      377
==========================================
- Hits         1743     1712      -31
- Misses        549      580      +31
  Partials       21       21

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


Is there a way to log remote client IP address and response code of the upstream SMTP server?

I need to log the client remote IP address and whether the mail transfer was successful or now. Is there a way to do this?

For the error handling I created a new struct, which satisfies the session interface, collect the error Data and assert it to *smtp.SMTPError.
As for the client IP, it is still an open issue.

it is possible to reuse state.RemoteAddr in Login and AnonymousLogin methods


Update Theme Submission Guidelines and README

We need to make it very clear to theme authors that themes need to be always maintained and that they should not be treated the same as personal projects

the link to the README needs to be made more prominent in the theme submission template (bold, bigger font or made into the headline etc i.e. Please make sure that you have read and met all theme guidelines before submitting an issue) because I keep seeing submissions with wrong screenshot dimensions, missing theme.toml attributes etc and it is apparent that authors have not read the README.

mainSections should be used instead of hardcoded sections for rendering lists

readFile or readDir should not be used in theme layouts templates, as well as no hardcoded PATHs in the form of: {{ .Site.baseURL }}/something either in templates or in the config of an Example Site.

never leave pages without layouts. Instead use disableKinds. A theme with no layouts for various kinds pollutes the Hugo Themes deploy logs to the point that these are almost unusable

never use the deprecated .Page.URL instead use .Permalink, .RelPermalink etc

also I propose that we discourage the use of third party CDNs to serve assets, it is no longer a good practice in this day and age (fingerprinting, security risk etc)

theme maintenance . If a theme demo breaks with the latest Hugo it will be removed from the Theme Showcase (it is the theme author's obligation to make sure that a theme renders with the latest Hugo)

keep the theme's Git Repo’s history down. No huge binaries.

never use photos that are copyrighted. Make sure that your theme’s resources can be used in an Open Source theme

If you agree/disagree with the above points, have suggestions etc please let me know so that I can send a Pull Request to update the README and make its link in the theme submission template more prominent.
Thanks
cc: @digitalcraftsman

Thanks for your work in keeping the themes site updated, @digitalcraftsman and @onedrawingperday! I'll make whatever changes are necessary to fix Indigo in the coming week.
Theme authors: I've found it helpful to follow the RSS feed at https://gohugo.io/news/ to stay up-to-date on what's changing with Hugo!

I have several thoughts around the idea of "theme maintenance" requirements — where would be the best place to have a discussion on this? A separate issue here? A topic on the forums? Thanks!

@AngeloStavrow
This issue is the best place to post your ideas.

Okay, so, this is going to be a bit of a long comment. Maintenance is the hardest part of any project, and I want to be thoughtful about the fact that this affects more than just the theme author, but also the hugoThemes maintainers, and maybe even the maintainers of Hugo itself.
Requiring ongoing theme maintenance of authors that want their theme in the gallery is a good thing. Having great, up-to-date themes in the gallery shows off all the great things that Hugo can do. Broken themes in the gallery are "bad publicity", if you will, for both Hugo and those theme authors.
I imagine that it's also a lot of work to curate the gallery, and at least some of the process seems to be manual, so it's time consuming on top of the time and effort the gallery maintainers put into answering questions from theme authors, both in GitHub and on the support forum. I fully support making their lives easier.

themes need to be always maintained and […] should not be treated the same as personal projects

I agree 100%, but would like to flag something here (that I'm sure you all are probably also thinking about): let's also make sure that theme authors (and everyone in the Hugo community) are set up for success! For example, I looked around and couldn't find documented maintenance or release commitments/processes for either the Hugo or hugoThemes projects, and I feel that those are necessary pre-requisites to a healthy culture of theme maintenance.
All of this preamble raises questions for me that I'd want to ask of theme authors, gallery maintainers, and the Hugo maintainers. I hope they prompt some constructive conversation!
How can theme authors and gallery maintainers prepare for new releases of Hugo?

Should we aim to have to some -beta or -nightly branch of Hugo that theme authors can test against before releases drop? I couldn't find any such branch in the Hugo repo.
Should theme authors and gallery maintainers expect a regular release schedule for Hugo?
Should theme authors expect a regular build schedule for the gallery?
What's the best way for theme authors, gallery maintainers, and Hugo maintainers to work together on a guidance document for theme maintenance?

What should happen when a theme is broken with the latest version of Hugo?

Should theme authors expect that a broken theme is removed from the theme gallery immediately?

If not, should theme authors expect that there's a grace period of X days where, e.g., their theme is in quarantine and invisible on the gallery until they fix it?
If a theme is broken and is removed/quarantined from the gallery, does the author have to go through the full "please add my theme" process?

Should the gallery build process include some automation to flip a switch between "include this theme" and "don't include this theme" based on some theme.toml metadata?
Should themes include some metadata in theme.toml like testedForHugoVersion that the gallery build scripts can pick up? How could we define what that means? (In my mind, it should mean that a theme author has confirmed that the theme builds with the version listed.)

Hello @AngeloStavrow
Below I have tried to answer all of your questions as best as I can:

Should we aim to have to some -beta or -nightly branch of Hugo that theme authors can test against before releases drop? I couldn't find any such branch in the Hugo repo.
Typically one would need to compile Hugo from source to test against new unreleased features. But I understand your point and that is why I am notifying @bep since he is the one who may consider a -beta or -nightly branch from Hugo

Should theme authors and gallery maintainers expect a regular release schedule for Hugo?
Typically one can follow Hugo's release cycle by having a look at its muilestones. Most of the time the milestones deadlines are honored but sometimes there is a delay. It all depends on the workload of the maintainer and the other contributors.

Should theme authors expect a regular build schedule for the gallery?
Due to https://github.com/gohugoio/hugoThemes/issues/259 the schedule is manual and usually it happens about once a week by @digitalcraftsman but there may be a delay.

What's the best way for theme authors, gallery maintainers, and Hugo maintainers to work together on a guidance document for theme maintenance?

The section regarding theme maintenance will be part of the updated README. Once I put the new version together, I will submit a Pull Request and ask for reviews by other members of the Hugo team. I may also ask for your feedback also.

Should theme authors expect that a broken theme is removed from the theme gallery immediately?
Yes. The days of opening issues in theme repos are over. Unless someone else is willing to come forward and invest the time.

If a theme is broken and is removed/quarantined from the gallery, does the author have to go through the full "please add my theme" process?
Yes. Theme authors will have to re-submit a removed theme once updated for a new review.

Should the gallery build process include some automation to flip a switch between "include this theme" and "don't include this theme" based on some theme.toml metadata?
We already have a few arrays in the Build Script such as noDemo for themes whose demo cannot be rendered or blacklist for demos that even if added in the repo do not appear on the showcase for various reasons. However adding a theme to these arrays is manual and is done if there is a good reason for doing so.

Should themes include some metadata in theme.toml like testedForHugoVersion that the gallery build scripts can pick up? How could we define what that means? (In my mind, it should mean that a theme author has confirmed that the theme builds with the version listed.)
We have the min_version attribute in theme.toml which indicates the minimum working version with which a theme functions. The Hugo Themes website always uses the latest Hugo release so a theme is always tested vs the new Hugo versions. If a theme demo breaks then this means that a theme is no longer functional with the latest Hugo.


Prerequisites for "v0: demangle structural constants and &str" (#55).

See #55 - my hope is that we can land these changes before #55 is ready, and to limit the amount of changes needed to be reviewed as part of #55.
Preferably merging should be done without squashing, but at least being split from #55 means that the prerequisites won't get mixed up with new demangling.

Seems reasonable to me, thanks!


How can i embed it in my theme

we are creating a theme for themeforest and want to embed it in. how can i do that. reference is given in function.php file its working but button is not showing

Rather than embedding the plugin in a theme, I recommend making it a "required plugin" using a tool like TGM Plugin Activation. This way the plugin can remain up to date without you having to update your theme every time we release a new version!


Clicking "Forums" on navbar never loads anything, something to do with new T&C addition

If I put https://sleepepi.partners.org/edge/www.myapnea.org/forums/ in my URL bar this pushes me just fine to https://sleepepi.partners.org/edge/www.myapnea.org/forums/terms-and-conditions
However, clicking "Forums" from the navigation bars does not do this. Nothing loads. I think we've seen this sort of behavior with some other pages before.
After accepting the T&C, the primary "Forums" links work again.

I can't replicate on my local machine. @remomueller could it have to do with turbolinks and apache?

Maybe it's the same sort of issue as #382 ?

Yes this has something to do with staging only (turbolinks/apache interaction). Closing issue.


[Feature Request] Add customgraph module

Hi, thank you for the awesome bar!
I was wondering, would it be possible to add a module creating a graph such as for example CPUGraph from QTile or Graph from eww. Ideally of course with being able to feed it custom data through continuous script similarly as custom module works.
I can now simulate it with the help of Sparks font, but it's a bit janky and it doesn't support all possible styling option.
I can help out a bit, however my C++ is very rusty so I wouldn't be the best help :)
Thank you!

that would be nice


Remove hook initialization in init from BigtableTableWaitForReplicationSensor

https://github.com/apache/airflow/pull/5974


update 02.7 and 02.8 for Turkish

update 02.7.md (Concurrency) for Turkish
update 02.8.md (Summary) for Turkish

这是来自QQ邮箱的自动回复邮件。您的邮件，我已经收到，O(∩_∩)O谢谢

#1314 has been merged with this pull request.


port: botbuilder-azure-blobs package

Port BlobsStorage class
Port BlobsTranscriptStore class

Note: I renamed the branch hence the fresh PR. See https://github.com/microsoft/botbuilder-js/pull/2892 for extra context.

@stevengum I think I addressed all your comments, thanks for the thorough review!


update neox arg docs

I believe we're out of github runner credits so this isn't automatic anymore.
FYI -- @jahatef

oops was on a fork. Redoing this from main.


tag and conda-forge Eric and Jiwoo external code.

@lee1043 @gleckler1 can you please point me to it.

@gleckler1 @durack1 @lee1043 is that the correct repo/tag:
https://github.com/eguil/ENSO_metrics/releases/tag/v0.1

https://github.com/eguil/ENSO_metrics/releases/tag/v0.1.1 might be the latest

@doutriaux1 Yes

@doutriaux1 @durack1 @lee1043  Yes v0.1.1 seems to be latest.  How goes the pmp-forge hook-up?

yes, v0.1.1 is latest


Support multiple engines under USER share level

1. Description
Kyuubi already supports CONNECTION, USER, SERVER share levels. A subDomain is a kind of MANUAL engine pool. It helps a user create more engines in user mode but require user assigns a unique character sequence. Based on #933, we can start to implement the feature of the engine pool.

2. Things to consider

Which share level to provide the engine pool?
How to control the concurrent create the engine?
How to share the pool size over two more kyuubi server?
Selection strategy(sequentially / randomly / load-based)?

3. Additional context
This needs a full design, any thoughs are welcome.
@wForget this issue is a bit overlapped with #786, we can split this to several tasks if possible 😃.

How to control the concurrent create the engine?

Is it possible to use InterProcessSemaphoreV2 to control concurrency.

How to share the pool size over two more kyuubi server?

The pool size should be configured through the user default configuration, and the user default configuration of multiple Kyuubi Servers should be consistent.

Can we create a proposal like what we did for the KYUUBI REST APIs https://docs.google.com/document/d/1yc-fk28oWbCNZjdFr1UXFbMtwSDQTpcwcNObn9ODnhQ/edit
You can make a draft on the google doc first, and we can polish it together before coding. Once it's been done, we can move it to https://github.com/apache/incubator-kyuubi/discussions/categories/ideas as a KPIP.

thanks @wForget, will open a github discussion first.
@yaooqinn, can we use github discussions directly? Google is restricted, can not open the google doc.

you use any public doc which can be viewed and modified by others. gh discussion is only modifiable for committers and author

hi @yaooqinn, does kyuubi has apache wiki space https://wiki.apache.org/?

and modified by others.

This maybe is not necessary. ok, will try to find online public doc, or put design on this issue first.

If github issue assigns to other users, can others modify it?

we use github only，no Wiki and jira，maybe we canuse 石墨 if Google doc does not work for you

@yaooqinn, it is still inconvenient to use 石墨.
1. Things to consider

Which share level to provide the engine pool?
How to control the concurrent create the engine?
How to share the pool size over two more kyuubi server?
Selection strategy(sequentially / randomly / load-based)?

engine pool is design for USER share level, we can set the pool size as the content of namespace znode.
2. Work Flow

3. How to update pool size

cc @wForget @yaooqinn

Motivation
Apache Kyuubi provides three engine share levels:

CONNECTION: engine will not be shared but only used by the current client connection
SERVER: the App will be shared by Kyuubi servers
USER: engine will be shared by all sessions created by a unique username

In the current design, kyuubi can provides engine pool through kyuubi.engine.share.level.sub.domain option for same user under USER share level. It does not have an auto-mechanisn, e.g. create two more engines under same subDomain, random picking engines.  The goal of this proposal is to provide such auto-mechanism to creating and picking subDomain to implement the feature of the engine pool.
Implementation
In this section, describe the implementation of Kyuubi Engine Pool. We need to consider several things

How to control the concurrent create the engine?
How to share the pool size over two more kyuubi server?
Engine pick strategy(sequentially / randomly / load-based)?

The key point is to set engine pool size as the content of engine space znode when create the engine space firstlly, so that we can share the pool size over two more kyuubi server, and avoid the inconsistent configuration between different servers effectively.
Design
1. High level

2. Detail work flow

Tests

KyuubiOperationPerConnectionSuite
KyuubiOperationPerServerSuite
KyuubiOperationPerUserSuite

Originally posted by @yaooqinn in https://github.com/apache/incubator-kyuubi/issues/974#issuecomment-904520407
一些想法
什么是引擎池？
一个引擎池是面向一个租户的，不同的用户使用不同的引擎池。一个引擎池是在一个目录下或者根据相应的目录过滤条件可发现的引擎集合。
假设我们为tom和jerry两位用户开启了引擎池。前者的大小为2，后者的大小为3。
所以，tom的引擎池看起来是这样的
kyuubi_USER/tom/engine-pool-0/serviceUri=ip:port;version=1.3.0;sequence=..../data
kyuubi_USER/tom/engine-pool-1/serviceUri=ip:port;version=1.3.0;sequence=..../data

而jerry的引擎池则看起来是这样的
kyuubi_USER/jerry/engine-pool-0/serviceUri=ip:port;version=1.3.0;sequence=..../data
kyuubi_USER/jerry/engine-pool-1/serviceUri=ip:port;version=1.3.0;sequence=..../data
kyuubi_USER/jerry/engine-pool-2/serviceUri=ip:port;version=1.3.0;sequence=..../data

注意，这里的整个“目录”设计规则和Kyuubi目前的规则没有任何的区别。其中，

第一层目录为server space加下划线再加share level，这里的share_level会是USER/Server。
第二层目录为用户名
第三层目录为subDomain。这里使我们需要关注的重点，因为引擎池化的逻辑主要围绕这一层目录的查找、创建暂开。我们可以复用和拓展现有的并发控制逻辑。在我们给的例子中’engine-pool-‘没有特别的含义，我们后面可以将它设置为参数或者hardcode的字符串前缀。而后缀则是0到pool size -1的自然数序列。如上面的例子所示，tom的引擎池会产生2个subDomain的目录。
剩余的目录就和现在的设计一样了，需强调的是和以前一样一个目录下依然只维护一个engine实例

引擎池大小控制

kyuubi.engine.pool.size.threshold, 引入该参数为服务端参数，由服务端控制引擎池的绝对上限。如果用户的设置超过这个设置值，则报错或者取该值
kyuubi.engine.pool.size，引入该参数为用户和服务端都可设置的参数，参数取值范围在kyuubi.engine.pool.size.threshold以下。当服务端统一或者用用户默认参数设置该值时，服务端会在统计当前存在subDomain目录数，即当前池大小，如果还未达预期，则递增一个subDomain目录并在该目录下创建一个引擎。

引擎的生命周期和现在的实现不变，可依据现在的缓存方式进行自我缓存，当生命周期到达上限，则自己退出并删除自己所属的subDomain
引擎的创建和复用 (RANDOM)
在 RANDOM 模式下，一切都是随机的，引擎的复用和引擎的创建在这个 POLICY 下是等价的。

举例，当jerry 在随机算法下使用连接池，假设 engine pool 的中间值为如下所示的状态，槽0和2已经有 engine 实例，而槽1 还未被初始化
kyuubi_USER/jerry/engine-pool-0/serviceUri=ip:port;version=1.3.0;sequence=..../data
kyuubi_USER/jerry/engine-pool-1/
kyuubi_USER/jerry/engine-pool-2/serviceUri=ip:port;version=1.3.0;sequence=..../data

此时，当 jerry 尝试连接时，

jerry 显示配置sub.domain，几个特例

sub.domain=engine-pool-0, 复用连接池内槽0的实例
sub.domain=engine-pool-1，只需对 engine-pool-1 加锁，直接创建槽1的实例，“手动”完成初始化，并连接
sub.domain=someothers，绕过引擎池的使用

jerry 未配置sub.domain， 则随机算法生成 engine-pool-x

当x=0时，复用连接池内槽0的实例
当x=1时，只需对 engine-pool-1 加锁，创建槽1的实例，完成初始化
当x=2时，复用连接池内槽1的实例

jerry 使用其他模式，照旧

两个 Kyuubi Server 对某用户配置了不同的 kyuubi.engine.pool.size 值怎么办？
假如 Server1 为4，Server2 为 5，则Server1，在[0, 3]区间内随机，而Server2可在[0, 4]之间取值。两者不存在耦合关系，当然最好的实践还是配置相同的参数值
kyuubi.engine.pool.size 是否对用户暴露，暴露后用户连接每次 kyuubi.engine.pool.size 不一致怎么办？不合理设置怎么办？
理论上可以对用户直接暴露，
当用户设置不合理时，比如过大，则由kyuubi.engine.pool.size.threshold 控制
当用户设置不一致时，比如增加，则 pool size 可随机增加。抑或减小，则新区间外的引擎将因随机不到而自我回收。

Can we make some follow-ups for this feature, e.g. other engine provider strategies, detailed doc?


transform function 3/4

3rd pull request for #154

Note that I am hoping that PR 4/4 can also come with a small example ipython notebook, or perhaps a new section in our main demo, demonstrating how this code works in a pedagogical fashion. That would be really great and I am sure such examples would increase adoption.

Let me know when you are ready for review, thanks for making these changes!

we are ready for review! (I'll improve the coverage tonight)

Actually, test coverage looks okay currently! Definitely add more tests if you like though.

for the notebook, do you prefer a section in main demo or separate?

Either would be great! Maybe easiest to add to main demo.

Should I go ahead and merge?

yup! there will be a 4/4 with transform functions and addition to the main demo


ptcl notes

I probably should've combined this with the last pr, but I just finished some brief notes on .ptcl files
It appears to be the nn::vfx2 version of ptcl (not aware of any complete documentation of the format) and they're only found embedded in .esetb.byml files (romfs/Effect)
Interestingly enough, these ptcl files have embedded BFRES/BNSH files which potentially means you could get an embedded file inside a BFRES file inside a PTCL file inside a BYML file 😄

come to think of it, g3pr may be g3d primitive🤔


Rack apps should return array

In this commit released with 0.12.0: 129ad6ef8d22579425f5b6ab655cd0c476d0bc76, the formatter middleware now returns a Rack::Response and not an array.
From what I understand, this breaks Rack's conventions (and broke the middleware in my app).
Also, the docs for Rack::Response clearly states that an app should return Rack::Response#finish (aliased to #to_a).
Any reason this has been done?
If not, I will be happy to provide a pull request that reverses the commit ;)

This is in UPGRADING, and see https://github.com/intridea/grape/pull/1029.
Rack spec (from what I remember after reading a lot of it :) just says you're supposed to return a Rack::Response or a "file-like object". With the change you describe above we are able to return a file stream. I couldn't find a single example where returning a Rack::Response itself would be an issue.
Are you seeing something broken or are you just worried about the convention?

Thanks for the answer ;)
I didn't realize this was for streaming (and I didn't notice the UPGRADING untill now)
This broke a custom rack middleware in my app, because in some scenarios it will be just before the Formatter middleware.
If I need to make changes to the response before returning from my middleware, I must now first check if it is an Array or a Rack::Response (The middleware is used in many different places).
If this is expected behavior, issue can be closed ;)

Yes, since UPGRADING documents this pretty thoroughly I think we're good. It's also easier to work with a Rack::Response in another middleware, you might want to consider adjusting all your code to that.

@dblock sorry to reopen an old issue here. From what I can tell, the Rack API docs do imply that you should not return the Rack::Response itself from the app.call:

Your application's call should end returning Response#finish.

via http://www.rubydoc.info/github/rack/rack/Rack/Response

Also:

A Rack application is a Ruby object (not a class) that responds to call. It takes exactly one argument, the environment and returns an Array of exactly three values: The status, the headers, and the body.

http://www.rubydoc.info/github/rack/rack/master/file/SPEC

I just don't read it the same way I suppose. If we undo this the whole streaming thing doesn't work at all, no?

@dblock, I haven't read the code, but wouldn't you do streaming by having the 3 value of the array be a special object that responds to each? http://www.rubydoc.info/github/rack/rack/file/SPEC#The_Body

From what I understand that doesn't work because of how Rack treats this, but I could be totally wrong. Maybe @dan-corneanu can help us here?

@dblock yeah, I'm just reading the spec, might be things I'm missing. It looks like Rails is just doing something with Rack::Chunked::Body: https://github.com/rails/rails/blob/b6760d8f14af6b00250395f2c830b89e43621860/actionpack/lib/action_controller/metal/streaming.rb

@dblock ran across this again and I still believe that Grape's behavior here is incorrect.

I'm virtually certain that the correct approach for streaming is to return a body (the third array element in the response) that handles the streaming. The response from call should always be a simple array.

I am not sure what to do with this, I think you should raise a PR and we can look at the change?

@dblock With some recent changes to Rack it seems like this may not work correctly anymore as implicit destructuring is no longer supported: https://github.com/rack/rack/commit/72959ebc2f300f3b2ccb7ae2aae9f199e611dfb6#diff-10b933d2c1fdc82ceecade456c64e1c2


Support removeListener function

It would be nice to have the possibility to unsubscribe specific handlers from the events like in the EventEmitter interface.
https://nodejs.org/api/events.html#events_emitter_removelistener_eventname_listener

Great suggestion, added in 1.2.0. You can now call removeListener(route, [listener]) to remove the registered listener.
One interesting difference I found when implementing this is that because this libarary is promise-based, you can't have more than one listener per route. That would be a race condition -- which promise would resolve first and pass data back? So it is different than Node's EventEmitter which can register many listeners.
So the listener param is optional, you can call it with just removeListener(route) and it will remove whatever is registered to that route (if anything).


Windows Support?

Is it supported in current version? If not can you please share tentative timeline of the availability

Not at the moment. in the future....


ciao-compute: remove the strategy free feature

The strategy free was causing some weird behaviour when running parallel tasks.
Returning to the default execution strategy fix this.
Closes https://github.com/clearlinux/clear-config-management/issues/72

The other roles might hit the same behaviour, please remove strategy from ciao_*.yml files

@albertomurillo Tested with a newer ansible version(<IP_ADDRESS>) and this issue is still present.

@albertomurillo can we merge this?