nth() (and therefore head()) to support Iterators

I'm aware that support for ImmutableJS has been discussed and deemed out of scope: https://github.com/ramda/ramda/issues/1367
However I've noticed that a lot of Ramda works with Immutables' Seq (etc) because Ramda detects that the List is an Iterable. map() and find, for example, work fine:
const double = compose(
     x => x * 2,
     tap(() => console.log('called'))
);

compose(
    find(equals(8)),
    map(double)
)(immutables.Range());

... logs 5 times then returns 8.
However, while this returns 0:
compose(head, map(double))([0,1,2])

This returns undefined:
compose(head, map(double))(immutables.Range(0,3))

... because head calls nth(0) and nth only caters for arrays and strings.
Any comments or objections to my writing a PR to make nth (or possibly just head) understand iterables?
I proved the concept with my own head:
const symIterator = typeof Symbol !== 'undefined' ? Symbol.iterator : '@@iterator';
const { head: oldHead } = require('ramda');

const head = list => {
  if (list[symIterator] != null) {
    return list[symIterator]().next().value;
  };
  return oldHead(list);
};

Of course there are more efficient ways to get the nth member of many objects that happen to be Iterables. In the case of an immutables Seq, get(n) -- but iterable is standardised and often we use low numbers in nth

I think it would be awkward if R.head works on iterables but not the other three tail, init, last of the quartet as well.
Admitted the indices are low integers, but without a ReverseIteratorin JS, it feels wrong even attempting it. Also with R.nth with negative index one would need to run to the end of the sequence in the implementation.
For infinite sequences we'd get infinite loops, but this I'd not consider a big problem, since that's Ramda's principle "Garbage in - garbage out".
While I like JS iterables and think that many of Ramda's List functions are in principle suitable candidates (contains, startsWith, ...)  to work on iterable sequences I think JS iterables do not qualify as full List collection type - it's just an interface for looping/iterating of the sequence.

As it happens, tail works on an immutables object, because Ramda dispatches to the object's slice. Hence with my head implementation head(R.tail(imm.Range(5,Infinity))) returns 6 as you'd want. Ramda is so close to working with these kinds of list.
Is there a preferable interface to Iterable that head could use? It could itself use slice() of course.

(I'm not especially concerned about init/last because I have a left-over instinct from learning Lisp all those years ago, thinking of the list as a linked-list. head and tail (car/cdr) are super-efficient; last involves traversing the whole list.

It may be I am the wrong guy to answer, since I am not familiar ImmutableJS. I've assumed you target JavaScript Iterables. That's why I am confused:

Is there a preferable interface to Iterable that head could use?

The only interfaces there are is [Symbol.iterator] for Iterables and next() for Iterators. Nothing else.
I don't know what imm.Range(5, Infinity) is, but this is an infinite JS iterable
function * naturalNumbersFrom(n){
    yield n;
    yield * naturalNumbersFrom(n + 1);
}

var it = naturalNumbersFrom(10);
it.next().value; // -> 10
it.next().value; // -> 11
...

for which R.tail would be a futile attempt indeed.

@semmel what I mean about interfaces might be clouded by nomenclature.
An object can have a bunch of functions as members. R.tail happens to work on an immutable.js Seq -- even if it's a Range with no end, because R.tail calls R.slice(1,Infinity), and R.slice dispatches to its parameter's slice method if there is one.
So slice and tail operate on any object that conforms to what I'll call Sliceable.
Many of Ramda's functions dispatch to a load of member functions -- slice, reduce, map, chain -- the list goes on.
But head does not. It works on a String or an array, and that's it.
Now, I know the immutable.js types implement Iterable, so I can make it work by implementing head in terms of the iterator. In the case of immutable.js I could also make it work by dispatching to the object's first method. That's an interface I might call Firstable, which Ramda currently doesn't recognise.
So I'm asking if there's an interface (maybe better to use the word 'specification' as FantasyLand does) other than Iterable, which Ramda's head could reasonably dispatch to.

If Ramda expanded its dispatching, it's possible that we could offer full integration with funkia/list.  But that's an extremely controversial idea.  Some of the core team would rather remove as much of it as we can.
Although I understand the objection from @semmel, I think that we could reasonably make head and tail work on iterables even if last and init don't.  Or we could create them and simply let them fail if they're passed infinite sequences.  People who try to get last on an infinite list deserve to wait a while! :smile:

Here's a branch for discussion: https://github.com/ukslim/ramda/tree/nth-for-iterable

I have a concern with regards to immutability and iterators.
Iterators are inherently stateful. An iterator gets consumed as one calls next on it. Thisd leads to some rather unintuitive behavior when working with these functions:
 const MyIterable = function*(){ var n = 0; while(true) yield n++; }
undefined
> const myIterator = MyIterable()
undefined
> myIterator.next()
{ value: 0, done: false }
> const head = (it) => it.next().value;
undefined
> const tail = (it) => { it.next(); return it; };
undefined
> const [a, b] = [head(myIterator), head(tail(myIterator))];
undefined
> a
1
> b
3

head(myIterator) === head(myIterator) // false

> const [c, d] = [head(tail(myIterator)), head(myIterator)]
undefined
> c
7
> d
8

and so on. This is a ll expected behavior, but it doesn't mesh well with the principles of Ramda as a whole.

@Bradcomp: Right.  It seems we'd have to implement something like immutagen  in order to get these to work as we'd like, and that seems a great deal of overhead.

var init = function(list){
    var itbl = {};
    itbl[Symbol.iterator] = function(){
        const it = list[Symbol.iterator]();
        var currentResult = it.next();
        return { next: function(){
		var result = currentResult;
		const nextResult = currentResult.done ? currentResult: it.next();
		if (nextResult.done){
			result = {value: undefined, done: true};
                }
		currentResult = nextResult;
		return result;
		}
 	};
    };
    return itbl;
};

var head = list => list[Symbol.iterator]().next().value;

var ar = [0, 1, 2, 3];
for (const x of init(ar)){ console.log(x); } // -> 0, 1, 2

head(init(init(init(ar)))); // -> 0
head(init(init(init(init(ar))))) // -> undefined

head(init(init(myIterable))); // -> 0

last should be trivial.
@ukslim could you perhaps run my ad.hoc implementations against ImmutableJS?
So it would be useful to extend some of Ramda's List functions on iterables?
Should attempt a PR?

@semmel: That makes sense.  I think a PR might be a fair bit of work.  While I'm in favor of seeing this, I would love for more of @ramda/core to chime in before you put in that effort.  (Of course, if you're itching to get started...)

@semmel Yes, your implementation of tail works:
var { Seq } = require('immutable');
head(init(init(Seq([0,1,2,3])))); // -> 0
head(init(init(init(Seq([0,1,2,3]))))); // -> 0
head(init(init(init(init(Seq([0,1,2,3])))))); // -> undefined

And yes, you're correct that statefulness isn't a concern for an Iterable -- the implementation requests a new iterator (which is stateful), uses it to iterate, then discards it without ever exposing it to the caller.

@ukslim

funkia/list is plausibly usable, however, it doesn't really work with (all of) Ramda's functions. Rather it provides its own functions with the same names as Ramda's, operating on its own datatype, hence the example on its front page:

That is true (but List does implements Foldable, Functor and Iterable which are abstractions that Ramda supports). The big benefit of the approach that List takes is that it actually works reliably with Ramda.
We can make head work for any iterable and we could also implement a very slow nth for any iterable. But very soon one runs into limitations. For instance, you can't implement insert, filter, partition, zip, sort, and many many more methods with Iterable. This means that attempts to make Ramda work directly on other data-structures only works every now and then. End users will, for each case, have to remember if a particular function works or not. That is not to say that doing that is a bad idea. It definitely has value. But the approach List takes has other benefits IMO. It can actually work 1-to-1 in a predictable manner and without sacrificing performance.
Ramda already supports iterables in a lot of functions which is nice. Making head work on iterables seems reasonable as well. But, I think making nth work on iterables would have bad consequences. Such an implementation would have a big performance overhead and people may not realize that they're writing really slow code. For instance, users might be tempted to call R.nth on a list from List without knowing that it is a lot slower than the nth function that List exports. That would slow down users code with no benefits.
In other words. I think supporting Iterables is great when it doesn't have a huge performance overhead. When it does have a huge performance overhead I'm afraid it will do more harm than good.

First let me focus the discussion on JS Iterables and put ImmutableJS and funkia/list aside.
@paldepind states that there are at least two drawbacks, which I agree with:
1.) A documentation issue.

... attempts to make Ramda work directly on other data-structures only works every now and then. End users will, for each case, have to remember if a particular function works or not.

If I understand JS Iterables as forward linked lists I cannot say which of Ramda's List functions can't (or shouldn't) be implemented. I don't agree that e.g. filter can't. (See example below)
2.) Performance.
as @ukslim said

... thinking of the list as a linked-list. head and tail (car/cdr) are super-efficient; last involves traversing the whole list

Hmm. One could argue that if you put your data into a linked list the user should be aware of the performance implications. So it's his/her own fault according to Ramda's famous principle ("Garbage in - garbage out").
// just proof-of-concept
var filter = function(pred, list){
    var tailItbl = {};
    tailItbl[Symbol.iterator] = function(){
        const it = list[Symbol.iterator]();

        return { next: function(){
		var itResult = it.next();
		while (!itResult.done && !pred(itResult.value)){
			itResult = it.next();
            	};
		return itResult;
	}};
    };
    return tailItbl;
};

var head = list => list[Symbol.iterator]().next().value;
var myIterable = {};
myIterable[Symbol.iterator] = function*(){ var n = 0; while(true) yield n++; };

head(filter(R.gt(R.__, 1), myIterable)); // -> 2
head(filter(x => x % 5 === 0, filter(R.gt(R.__, 11), myIterable))); // -> 15

@semmel

First let me focus the discussion on JS Iterables and put ImmutableJS and funkia/list aside.

I think that is a good idea :smile: But, we still need to keep in mind that Iterables are not just iterables. They're an abstraction implemented by data-structures that are a lot of other things in addition to being iterables. Iterables are like functors and foldables—they're an abstraction.

If I understand JS Iterables as forward linked lists I cannot say which of Ramda's List functions can't (or shouldn't) be implemented.

There is a connection between Iterables and forward linked list in that the performance of doing something on a linked list is similar to the performance of doing the same thing on an iterable. head is O(1), nth is O(n), etc. But, JS Iterables are not forward linked lists. They are data-structures that support iteration through a specified API. A lot of data-structures can implement the Iterable abstraction without being linked lists. For instance, JS Arrays are Iterables and List's relaxed radix balanced trees are also Iterables.

One could argue that if you put your data into a linked list the user should be aware of the performance implications.

People put their data into a linked list. People put their data into data-structures that, among other things, happens to be an Iterable.

I don't agree that e.g. filter can't. (See example below)

While the filter you've defined works well it has the problem that it returns a different type than the one given to filter. filter normally returns an instance of the same data-structure that it was given. I.e. filtering and array results in another array. But the filter you've defined always returns a data type which is nothing but an Iterable.

@paldepind
Let me explain. The idea was not to replace the existing implementations of the List functions, but to add support for iterables as fallback. So the implementation would proceed from dispatching (e.g. to a filtermethod if the data should happen to provide it), handling expected List types (isArray) - all like it is now - to finally inspect the provided List Object for iterator support.

For instance, JS Arrays are Iterables and List's relaxed radix balanced trees are also Iterables.

Yes if it happens to be a JS array, we can employ array methods, if it happens to be a List tree, it's api should be employed. But if it is neither of these types we could try the very general abstraction of a JS iterable.
However my plan has a problem for filter, reject and so one which work on Filterables which can be plain objects too. So if that key-value collection Filterable also is an interable; Should filter work on the key-value pairs at it's right now or employ the iterator from the collection?

filter normally returns an instance of the same data-structure that it was given. ... But the filter you've defined always returns a data type which is nothing but an Iterable.

Yes, the same is true for the tailand init examples above - they are not meant to be comprehensive. I left this part out. Of course the given data structure must be cloned (shallow?) in the implementation and returned as result. The only change would be the clone's iterator which swallows the filter predicate.
I don't know if this all is perfectly reasonable, therefore I am grateful for the good discussion. 😄

A general programming principle is that a function should not over-specify input parameter requirements because that restricts the usefulness of the function. Input arguments should be the most general and abstract possible. For example a “get length” function should not require a Set because that prevents usage with Array, Map, String, etc.
Output results should be the most specific since they are the most useful. For example if the user asks for Unique items then that should be returned as a Set, not just an Iterable, because sets already have an index to quickly find values while Iterables and Arrays do not.
Most general abstract in. Most specifically useful out.
Many Ramda functions over-specify the input to an Array when any kind of Iterable will do. Requiring an Array for input decreases runtime performance because the caller needs to first materialize a whole array when one-at-a-time processing is sufficient. Ramda would be more useful if it accepted Iterables everywhere it could. Nth, Head, Aperture, None, Length, Median, and others. If the input object is an Array or other well-known object with indexed access then certainly go ahead and use that optimization. But as a fallback I see no reason, other than download size, why all these functions shouldn’t work with Iterables or have iterable variants. Iterables are immutable (good) and lazy (good).
Likewise Ramda over specifies output results to Array for no obvious benefit and with the performance cost of materializing one. Much better to stream list results as an Iterable until the user says “ok I’m done with my filtering, mapping, inserting, expanding, and flattening- now give me an Array.” Backward compatibility aside, It would be nice to see more Ramda functions output Iterables, since lazy computations are efficient.

@jmagaram:
I think we're all pretty well in agreement that this is worth doing.  I've wanted this ability for years (thinking in terms of more general streams than specifically Iterables, but it's the same principle.)  We've discussed some possibilities since at least #446.
But as mentioned over on #2525, there is quite a bit of work to do here, both in API design and in implementation.  Some API questions:

Given this as your data:
const foo = {
  [Symbol.iterator]: function* f(n = 0) {
    yield n
    yield * f(n + 1)
  }
}

What is the expected behavior of some of those functions you mention, e.g.  none, length, median? (nth, head, and aperture seem to have straightforward answers.)  Ramda's usual philosophy of "let it fail" is much more problematic when failing means that your application crashes... and you can't even catch an exception to handle it.

Would we expect to be able to get back a more specific type than just Iterable, if we supplied data of a more specific type?  What is the return type of
map(n => n * n, new MyStream(/* ... */))

if instances of MyStream have Symbol.iterator?  Iterable?  MyStream? map's usual contract is map :: Functor f => (a -> b) -> f a -> f b.  So the output type is an instance of the same Functor as the input type.  Would we have to forgo this?  Do we try to apply some gloss that says, "Well, Iterable is our Functor here, not MyStream?"  Do we depend upon delegation to handle this before our iterable branch?  Something else?

How do we choose the functions that need this treatment?  Iterables are not arrays, but they do overlap a great deal.  Still, there are functions which make sense on arrays that might not on iterables.  Is there some clear criteria we can use to choose when to add a code-path for iterables to existing functions?

Likewise Ramda over specifies output results to Array for no obvious benefit and with the performance cost of materializing one.

Most of Ramda's transformation functions will always return the same type as is input to them.  This is important IMHO to allow clear reasoning about a system.  I wouldn't want, for instance:
const nbrs = [1, 2, 3, 4, 5]
const squares = map(n => n * n, nbrs) //=> iterarable yielding 1, 4, 9, 16, 25
squares[1] //=> undefined

That [1] is part of the Array interface, and Ramda should not be trying to enforce that you will need to use nth(1) on the results of a map call over an array.
But this is not any major issue; we can simply ensure that the array checks are made before the iterable ones.
The fact that Clojure can transform its collection types in similar circumstances is one of my main objections to it.  So I would suggest that if an array is input, Ramda should always output an array.

By the way, wanting to do this is not an application of Postel's Principle ("Be conservative in what you send, be liberal in what you accept.")  It is instead the recognition that there is a common abstraction underlying arrays, streams, iterables, etc., and that many of our functions could operate at that level.  Underscore, lodash, and particularly jQuery are built on Postel's Principle, but Ramda's underpinnings are a bit different.

If you give an infinite sequence to a function that requires a finite sequence, like length or sort, then the software should fail. This is a programmer error, like passing a negative number to square root. Infinite sequences are useful, like a random number generator, as long as you know when to stop pulling values.
If you have a function that takes an X as input I don't think the function can always generate an X on output. Otherwise the function would need to know too much - how to build a Map, a Set, an immutable.js Set, Stack, a custom collection, etc. and this is clearly not feasible. It also may not be necessary if the user wants to take the result and do further stream processing on it before materializing it. Better to output an Iterable and let the caller construct an X once they are ready for it. This lazy behavior will result in better performance. Of course if the function generates an Array or Set or Map to do its job, then return that rather than throwing away the extra info and just returning an Iterable.
I am very comfortable with code in C# that takes an array, does a bunch of stream processing on it with iterables, and then converts it back to an array when I'm done. That actually feels really good to me. My first reaction when I read the Ramda docs was "wow this is all really cool and powerful, but why create all these intermediate arrays?"
I think you could add Iterable input to nearly every function that takes an array. I don't know what to do about output. If you were starting from scratch you could output iterables everywhere. So maybe for backward compatibility it makes sense to have alterate versions that output iterables rather than arrays and the user of the library can pick which one they want.

@CrossEye

Most of Ramda's transformation functions will always return the same type as is input to them. This is important IMHO to allow clear reasoning about a system.

I very much agree.
@jmagaram

If you have a function that takes an X as input I don't think the function can always generate an X on output. Otherwise, the function would need to know too much - how to build a Map, a Set, an immutable.js Set, Stack, a custom collection, etc. and this is clearly not feasible.

I think it just requires the right abstraction. For instance map can always return the same output thanks to the Functor abstraction. Iterables, on the other hand, is not a good abstraction for map as there are many things that can support map but which cannot implement Iterable (async streams for instance).
IMO Iterable is a fine abstraction for functions that are essentially just iterations over a data structure (R.find, R.mean, etc). But, it is a poor abstraction for many other things like R.map, R.nth, R.filter, etc).
Sure, we could accept any Iterable in R.last and R.nth but I don't think that is necessarily a good idea. To me, it feels like putting a screw into a piece of wood with a hammer in the conviction that a hammer is a very general purpose tool.
The very first thing we should do in Ramda is to properly document when our functions supports Iterables. There are many functions that currently support Iterables with no mention in the documentation. Fixing that would be an obvious improvement to the current situration.

@paldepind:
While I agree overall, there are several things that I'm not so sure of:

Iterables, on the other hand, is not a good abstraction for map as there are many things that can support map but which cannot implement Iterable (async streams for instance).

I absolutely agree that the data supplied to map cannot always implement Iterable, would you see any problem with map supporting Iterable as a last check, as I mention in my previous comment?

But, [Iterable] is a poor abstraction for many other things like R.map, R.nth, R.filter, etc.

What do you mean by "is a poor abstraction for" here?  If you're suggesting that map, filter, et al have more general uses than simply on iterables, then I heartily agree.  But if you're suggesting that there are not reasonable functions to apply to iterables, then I don't agree.  Of course nth will have vastly different performance characteristics than it does on an array, and it's possible to imagine iterable data structures on which it has no real meaning, depending on exactly how iterable is defined.  But the others seem to have reasonable meanings, and straightforward implementations.

There are many functions that currently support Iterables with no mention in the documentation. Fixing that would be an obvious improvement to the current situration.

Absolutely.

I think I'm starting to understand more how Ramda works. I just read up on "Functors" and FantasyLand. It seems like Ramda works with abstract data types defined by FantasyLand, not just specific ones like Array.  Correct? Ok that makes sense to me and is quite elegant.
So maybe I could wrap any iterable in a lightweight wrapper, give it a bunch of fantasyland methods to make it a Functor (map), Filterable (filter), Setoid (equals), Semigroup (concatenation), Monoid (empty sequence), Traverseable (?), and then use Ramda on it. Because as I look through the FantasyLand specs it seems like most of those capabilities apply to any kind of iterable. Maybe this "wrapper" should be part of Ramda.
But as I look through the Ramda docs it doesn't look like Ramda consistently works with abstract data types. Head and Nth, for example, take an array or string. Why not take anything that is fantasyland "traversable" and return the result from doing that 1 or N times? Maybe there is a way to get Zip, UniqBy, Aperature, etc. to work with abstract data types like iterable too.

@jmagaram:

It seems like Ramda works with abstract data types defined by FantasyLand, not just specific ones like Array.

To some extent.  Ramda started working with arrays, objects, strings, and functions well before we tried integrating with FantasyLand.  This integration is quite important to Ramda, but it is not the only thing that Ramda is about.

So maybe I could wrap any iterable in a lightweight wrapper, give it a bunch of fantasyland methods...

Sure, but you could, but you might lose some specific features of your underlying type in doing this.  That's why we're concerned about maintaining the input types.  Since this works:
[1, 2, 3].map(n => n * n).push(42) //=> [1, 4, 9, 42]

we would also expect this to work:
R.map(n => n * n, [1, 2, 3]).push(42) //=> [1, 4, 9, 42]

which wouldn't happen if R.map returned a lightweight container.

[I]t doesn't look like Ramda consistently works with abstract data types.

Absolutely not.  We have plenty of functions, and only a small number of them work on multiple types.  But those tend to be the most important in the library.

Maybe there is a way to get Zip, UniqBy, Aperature, etc. to work with abstract data types like iterable too.

**Quick note::: I know you're coming from .NET, but function names in Javascript, and all of Ramda's functions, are written in lowerCamelCase.
You should note that the FantasyLand types are themselves abstract, and generally more abstract than is Iterable.  (You can easily make any Iterable a Functor, for instance, but there are plenty of Functors which are not iterable.)  zip and aperture could easily work with iterables.  I'm less convinced about uniq or uniqBy; there might be some difficulties again with infinite iterables.

By the way, I think you may have a misapprehension of traverse.  Tom Harding's explanation is worth a read although you may have to read earlier parts of his excellent series to follow all of it.

I just tried reading about Traversable and my head exploded. This is too abstract for me. Maybe FantasyLand doesn't have the concept of a "collection" that can be traversed. Iterable is a really nice abstract data type. There's got to be a way to get it to play nice with Ramda. A wrapped Iterable can definitely be a fantasyland Foldable. head, nth, maxBy, etc. can be calculated using a fold/reduce method. Aperature is some kind of map - map a collection to a collection<T[]>. I think I'm going to bow out here.


Develop

Codecov Report

:exclamation: No coverage uploaded for pull request base (gui@2be3dc3). Click here to learn what that means.
The diff coverage is 44.76%.

@@          Coverage Diff           @@
##             gui      #56   +/-   ##
======================================
  Coverage       ?   50.73%
======================================
  Files          ?       55
  Lines          ?     2501
  Branches       ?        0
======================================
  Hits           ?     1269
  Misses         ?     1232
  Partials       ?        0

Impacted Files
Coverage Δ

imagepypelines/core/util/color.py
20.68% <ø> (ø)

imagepypelines/core/io/Emailer.py
28.33% <ø> (ø)

imagepypelines/core/caching.py
41.42% <ø> (ø)

imagepypelines/core/standard_image.py
95% <ø> (ø)

imagepypelines/core/ml/ConfigFactory.py
22% <ø> (ø)

imagepypelines/core/util/__init__.py
100% <ø> (ø)

imagepypelines/core/pipeline_tools.py
25% <ø> (ø)

imagepypelines/core/constants.py
100% <ø> (ø)

imagepypelines/core/util/Summarizer.py
31.03% <ø> (ø)

imagepypelines/builtin_blocks/Orb.py
31.25% <0%> (ø)

... and 11 more

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 2be3dc3...6e34275. Read the comment docs.


Added Seal Append Blob

The spec was out of date, we don't need to add x-ms-blob-seal to AppendBlobClient.Append() or AppendBlobClient.AppendFromUri(), but we do need to add it to BlobBaseClient.StartCopyFromUri()

@tg-msft, I had to add a new parameter to BlobBaseClient.StartCopyFromUri().

@tg-msft, let me know the resolution for StartCopyFromUriOptions, and I'll do one more iteration.


keda-operator-metrics-apiserver unknown flag: --metrics-port

Report
Keda metrics-apiserver pod is in crashloop because of unknown flag: --metrics-port.
I'm deploying Keda via helm chart, using this values.yaml:
 image:
  keda:
    repository: ghcr.io/kedacore/keda
    tag: main
  metricsApiServer:
    repository: ghcr.io/kedacore/keda-metrics-apiserver
    tag: main
  webhooks:
    repository: ghcr.io/kedacore/keda-admission-webhooks
    tag: main
prometheus:
  operator:
    enabled: true
    serviceMonitor:
      enabled: true
      interval: 30s
      additionalLabels:
        app.kubernetes.io/part-of: kube-prometheus
  metricServer:
    enabled: true
    serviceMonitor:
      enabled: true
      interval: 30s
      additionalLabels:
        app.kubernetes.io/part-of: kube-prometheus
  webhooks:
    enabled: true
    serviceMonitor:
      enabled: true
      interval: 30s
      additionalLabels:
        app.kubernetes.io/part-of: kube-prometheus

Expected Behavior
I expected metrics-apiserver to startup while also exposing prometheus metrics
Actual Behavior
metrics-apiserver is stuck in crashloop with unknown flag: --metrics-port
Steps to Reproduce the Problem

Deploy helm revision v2.10.1 with values.yaml above
Observe metrics server not starting

Logs from KEDA operator
unknown flag: --metrics-port
Usage of /keda-adapter:
unknown flag: --metrics-port
      --add_dir_header                                          If true, adds the file directory to the header of the log messages
      --alsologtostderr                                         log to standard error as well as files (no effect when -logtostderr=true)
      --audit-log-batch-buffer-size int                         The size of the buffer to store events before batching and writing. Only used in batch mode. (default 10000)
      --audit-log-batch-max-size int                            The maximum size of a batch. Only used in batch mode. (default 1)
      --audit-log-batch-max-wait duration                       The amount of time to wait before force writing the batch that hadn't reached the max size. Only used in batch mode.
      --audit-log-batch-throttle-burst int                      Maximum number of requests sent at the same moment if ThrottleQPS was not utilized before. Only used in batch mode.
      --audit-log-batch-throttle-enable                         Whether batching throttling is enabled. Only used in batch mode.
      --audit-log-batch-throttle-qps float32                    Maximum average number of batches per second. Only used in batch mode.
      --audit-log-compress                                      If set, the rotated log files will be compressed using gzip.
      --audit-log-format string                                 Format of saved audits. "legacy" indicates 1-line text format for each event. "json" indicates structured json format. Known formats are legacy,json. (default "json")
      --audit-log-maxage int                                    The maximum number of days to retain old audit log files based on the timestamp encoded in their filename.
      --audit-log-maxbackup int                                 The maximum number of old audit log files to retain. Setting a value of 0 will mean there's no restriction on the number of files.
      --audit-log-maxsize int                                   The maximum size in megabytes of the audit log file before it gets rotated.
      --audit-log-mode string                                   Strategy for sending audit events. Blocking indicates sending events should block server responses. Batch causes the backend to buffer and write events asynchronously. Known modes are batch,blocking,blocking-strict. (default "blocking")
      --audit-log-path string                                   If set, all requests coming to the apiserver will be logged to this file.  '-' means standard out.
      --audit-log-truncate-enabled                              Whether event and batch truncating is enabled.
      --audit-log-truncate-max-batch-size int                   Maximum size of the batch sent to the underlying backend. Actual serialized size can be several hundreds of bytes greater. If a batch exceeds this limit, it is split into several batches of smaller size. (default 10485760)
      --audit-log-truncate-max-event-size int                   Maximum size of the audit event sent to the underlying backend. If the size of an event is greater than this number, first request and response are removed, and if this doesn't reduce the size enough, event is discarded. (default 102400)
      --audit-log-version string                                API group and version used for serializing audit events written to log. (default "audit.k8s.io/v1")
      --audit-policy-file string                                Path to the file that defines the audit policy configuration.
      --audit-webhook-batch-buffer-size int                     The size of the buffer to store events before batching and writing. Only used in batch mode. (default 10000)
      --audit-webhook-batch-max-size int                        The maximum size of a batch. Only used in batch mode. (default 400)
      --audit-webhook-batch-max-wait duration                   The amount of time to wait before force writing the batch that hadn't reached the max size. Only used in batch mode. (default 30s)
      --audit-webhook-batch-throttle-burst int                  Maximum number of requests sent at the same moment if ThrottleQPS was not utilized before. Only used in batch mode. (default 15)
      --audit-webhook-batch-throttle-enable                     Whether batching throttling is enabled. Only used in batch mode. (default true)
      --audit-webhook-batch-throttle-qps float32                Maximum average number of batches per second. Only used in batch mode. (default 10)
      --audit-webhook-config-file string                        Path to a kubeconfig formatted file that defines the audit webhook configuration.
      --audit-webhook-initial-backoff duration                  The amount of time to wait before retrying the first failed request. (default 10s)
      --audit-webhook-mode string                               Strategy for sending audit events. Blocking indicates sending events should block server responses. Batch causes the backend to buffer and write events asynchronously. Known modes are batch,blocking,blocking-strict. (default "batch")
      --audit-webhook-truncate-enabled                          Whether event and batch truncating is enabled.
      --audit-webhook-truncate-max-batch-size int               Maximum size of the batch sent to the underlying backend. Actual serialized size can be several hundreds of bytes greater. If a batch exceeds this limit, it is split into several batches of smaller size. (default 10485760)
      --audit-webhook-truncate-max-event-size int               Maximum size of the audit event sent to the underlying backend. If the size of an event is greater than this number, first request and response are removed, and if this doesn't reduce the size enough, event is discarded. (default 102400)
      --audit-webhook-version string                            API group and version used for serializing audit events written to webhook. (default "audit.k8s.io/v1")
      --authentication-kubeconfig string                        kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenreviews.authentication.k8s.io.
      --authentication-skip-lookup                              If false, the authentication-kubeconfig will be used to lookup missing authentication configuration from the cluster.
      --authentication-token-webhook-cache-ttl duration         The duration to cache responses from the webhook token authenticator. (default 10s)
      --authentication-tolerate-lookup-failure                  If true, failures to look up missing authentication configuration from the cluster are not considered fatal. Note that this can result in authentication that treats all requests as anonymous.
      --authorization-always-allow-paths strings                A list of HTTP paths to skip during authorization, i.e. these are authorized without contacting the 'core' kubernetes server. (default [/healthz,/readyz,/livez])
      --authorization-kubeconfig string                         kubeconfig file pointing at the 'core' kubernetes server with enough rights to create subjectaccessreviews.authorization.k8s.io.
      --authorization-webhook-cache-authorized-ttl duration     The duration to cache 'authorized' responses from the webhook authorizer. (default 10s)
      --authorization-webhook-cache-unauthorized-ttl duration   The duration to cache 'unauthorized' responses from the webhook authorizer. (default 10s)
      --bind-address ip                                         The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank or an unspecified address (<IP_ADDRESS> or ::), all interfaces will be used. (default <IP_ADDRESS>)
      --cert-dir string                                         The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "apiserver.local.config/certificates")
      --client-burst int                                        Maximum QPS burst for client-side throttle (default 10)
      --client-ca-file string                                   If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
      --client-qps float32                                      Maximum QPS for client-side throttle (default 5)
      --contention-profiling                                    Enable block profiling, if profiling is enabled
      --debug-socket-path string                                Use an unprotected (no authn/authz) unix-domain socket for profiling with the given path
      --disable-compression                                     Disable response compression for k8s restAPI in client-go.  (default true)
      --discovery-interval duration                             Interval at which to refresh API discovery information
      --http2-max-streams-per-connection int                    The limit that the server gives to clients for the maximum number of streams in an HTTP/2 connection. Zero means to use golang's default.
      --kube-api-burst int                                      Set the burst for throttling requests sent to the apiserver (default 30)
      --kube-api-qps float32                                    Set the QPS rate for throttling requests sent to the apiserver (default 20)
      --kubeconfig string                                       Paths to a kubeconfig. Only required if out-of-cluster.
      --lister-kubeconfig string                                kubeconfig file pointing at the 'core' kubernetes server with enough rights to list any described objects
      --log_backtrace_at traceLocation                          when logging hits line file:N, emit a stack trace (default :0)
      --log_dir string                                          If non-empty, write log files in this directory (no effect when -logtostderr=true)
      --log_file string                                         If non-empty, use this log file (no effect when -logtostderr=true)
      --log_file_max_size uint                                  Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
      --logtostderr                                             log to standard error instead of files (default true)
      --metrics-service-address string                          The address of the gRPRC Metrics Service Server. (default "keda-operator.keda.svc.cluster.local:9666")
      --msg string                                              startup message (default "starting adapter...")
      --one_output                                              If true, only write logs to their native severity level (vs also writing to each lower severity level; no effect when -logtostderr=true)
      --permit-address-sharing                                  If true, SO_REUSEADDR will be used when binding the port. This allows binding to wildcard IPs like <IP_ADDRESS> and specific IPs in parallel, and it avoids waiting for the kernel to release sockets in TIME_WAIT state. [default=false]
      --permit-port-sharing                                     If true, SO_REUSEPORT will be used when binding the port, which allows more than one instance to bind on the same address and port. [default=false]
      --port int                                                Set the port for the metrics API server (default 8080)
      --profiling                                               Enable profiling via web interface host:port/debug/pprof/ (default true)
      --requestheader-allowed-names strings                     List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed.
      --requestheader-client-ca-file string                     Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests.
      --requestheader-extra-headers-prefix strings              List of request header prefixes to inspect. X-Remote-Extra- is suggested. (default [x-remote-extra-])
      --requestheader-group-headers strings                     List of request headers to inspect for groups. X-Remote-Group is suggested. (default [x-remote-group])
      --requestheader-username-headers strings                  List of request headers to inspect for usernames. X-Remote-User is common. (default [x-remote-user])
      --s2a_enable_appengine_dialer                             If true, opportunistically use AppEngine-specific dialer to call S2A.
      --s2a_timeout duration                                    Timeout enforced on the connection to the S2A service for handshake. (default 3s)
      --secure-port int                                         The port on which to serve HTTPS with authentication and authorization. If 0, don't serve HTTPS at all. (default 443)
      --skip_headers                                            If true, avoid header prefixes in the log messages
      --skip_log_headers                                        If true, avoid headers when opening log files (no effect when -logtostderr=true)
      --stderrthreshold severity                                logs at or above this threshold go to stderr when writing to files and stderr (no effect when -logtostderr=true or -alsologtostderr=false) (default 2)
      --tls-cert-file string                                    File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory specified by --cert-dir.
      --tls-cipher-suites strings                               Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used.
                                                                Preferred values: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384.
                                                                Insecure values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA.
      --tls-min-version string                                  Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13
      --tls-private-key-file string                             File containing the default x509 private key matching --tls-cert-file.
      --tls-sni-cert-key namedCertKey                           A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. The domain patterns also allow IP addresses, but IPs should only be used if the apiserver has visibility to the IP address requested by a client. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". (default [])
  -v, --v Level                                                 number for the log level verbosity
      --vmodule moduleSpec                                      comma-separated list of pattern=N settings for file-filtered logging

KEDA Version
2.10.1
Kubernetes Version
1.24
Platform
Google Cloud
Scaler Details
N/A
Anything else?
No response

I just read "💡 DEPRECATED: Prometheus Metrics exposed from Metrics Server are deprecated, please consume metrics from KEDA Operator."
So I'm guessing it's safe to disable api server ServiceMonitor as those metrics are in the operator now?

@miguel-cardoso-mindera yes, I can also see that you are deploying an unreleased version of KEDA:
repository: [ghcr.io/kedacore/keda](http://ghcr.io/kedacore/keda)
    tag: main

I see, appreciate it. I will close this


Setup documentation for getting started with the tutorial material

The documentation for getting started with the tutorial will hold information on getting started.  The will include things like installing a containerization platform (e.g. docker) and pre-work necessary for participating in the tutorial.  As such, it shouldn't be hosted in the tutorial jupyter-book itself, but in a separate directory to be hosted on a different platform.  I think this works out pretty well as we can host the setup guide on readthedocs and host the jupyter-book on github pages (jupyter-book is easier to setup via the latter rather than the former).
Tasks:

[x] initialize the readthedocs yaml configuration file, .readthedocs.yaml
[x] initialize the sphinx configruation file, conf.py
[x] initialize the python requirements.txt file
[x] import project into readthedocs.org

Completed via 27deca7c97968a12cdc2a15708673d09ec266e7f and 8251290e016a542cf64ae42b809146906577a6c9.  Now hosted via https://ngee-tutorial-containers.readthedocs.io/en/latest/


Running Java methods from JavaScript page

I am trying to use new documentation page: Running Java methods from JavaScript.
But both in master and new-object branches I am facing this in attempt to load http://localhost:8080/
Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.

localhost/:1 Uncaught SyntaxError: Unexpected end of input
n.onreadystatechange @ XmlHttpRequest.js:163
c @ XmlHttpRequest.js:172
e._requestFileSync @ async.js:17
e @ XmlHttpRequest.js:316
(anonymous function) @ (index):17

XmlHttpRequest.js:318 Uncaught Error: Unable to find listing at URL: listings.json
e @ XmlHttpRequest.js:318
(anonymous function) @ (index):17

Looks like something wrong with generated listings.json. Are you sure this guide working on latest master?

The guide worked for me on my Linux machine, as of a few days ago.  Are you using OSX by chance?  I know I ran into that same error a few days ago on OS X; for whatever reason it appears to be a platform issue that results in the listings.json file being corrupt/invalid.  Anyway, I'd recommend trying on Linux and see if that works better for you.  Not sure what the root cause of the bad listings file is.

If you're not updated to the latest new-objects commit (which fixed this bug, but also changed the natives API), you can retrofit whichever commit you're on by changing the last line of tools/gen_dir_listings.coffee from:
process.on('exit', (-> console.log JSON.stringify(fs_listing)))

...to:
console.log JSON.stringify(fs_listing))

Apparently there's a race condition between the program exiting and the log statement completing that only triggers in some scenarios. The process.exit I had in there is a remnant from when gen_dir_listings operated asynchronously a long, long time ago. Hurray for code rot! :(
Closing as fixed. Reopen if it's still broken.

For latest new-object on attempt to run:
npm install
execsync v1.0.2] Attempting to compile native extensions.
[execSync v1.0.2]
    Native code compile failed!!
npm WARN prefer global<EMAIL_ADDRESS>should be installed with -g
npm WARN prefer global<EMAIL_ADDRESS>should be installed with -g

node v4.1.2
npm 2.14.4

@akadeev new-objects does not depend on execSync, marked, or npm anymore. See the package.json file here. Are you sure you aren't accidentally on the master branch?

Yeah, looks like there was some issue with branches, I have cloned repo again to make sure and npm install worked. Then bower install was silent (isn't it weird?).
Then grunt release finished without errors, but vendor directory contains only java_home and websockify.
But that is not good afaik - it has to contain browserfs for

I changed the build system on new-objects so bower is not required. :)
BrowserFS is now in node_modules/browserfs/dist/browserfs.min.js. I plan to merge new-objects into master, perform a new release of doppio, and update the doppio-demo repository to depend on the release this week. The current blocker is some weirdness in the unit tests and the Jython/JRuby issue, which I'm currently sorting out.
Do I still reference the old location of BrowserFS somewhere?

As an aside, note that I switched from require.js to Browserify -- thus, I am able to depend on NPM modules like browserfs for Browser code, and I rely on Browserify to replace references to Node modules with their BrowserFS equivalents (Buffer, path, fs, etc).

Old location of browserfs contains in guide: Running Java methods from JavaScript. :)

You are correct, @akadeev. The guide is slightly out-of-date. I'm prioritizing fixing the unit test issues before updating documentation. I won't be able to get to it until tomorrow.
The changes should be fairly superficial, though. I've changed the API, but doppioh will take care of generating correct code, and the native methods in DoppioJVM use the new API. The location of BrowserFS is different, but the BrowserFS portion of the guide should be correct.
I can ping you here when I've updated the guide. I'm also happy to answer any further questions you have until then.


database initialization problem when using different docker tags?

Following the request from @mssola to open a new issue regarding the problems with the db when upgrading portus described in #1620 , i tried to reproduce the problem and i got it, these are the steps:

cleared all previously downloaded tags (just to make sure everything is clean)
pulled 2.3 tag (image: opensuse/portus  2.3 d47008369714  17 hours ago)
spinned up a stack using the 2.3 tag for portus and background services, version
populated the db with some teams, namespaces and pushed a few test images
stopped the whole stack with docker-compose down (persistent volumes)
cleared images
pulled head tag (image: opensuse/portus head 42b0d1ac54c0 17 hours ago)
spinned up the same stack using head tag
got the problem when portus tries to initialize database

it seems that the issue does not occur if you repeat steps using the same image, i'm not sure if we should try with different images version of the same tag (i.e. with the next update of head?).
Notes:
2.3 version was 2.3.0@6c27eb83e3b23b12ce62d39e6823ec8cf5747921.
head version was 2.4.0-dev@46ae80aeed17075974988de5a88a75fd9d4ebb53.

Same problem here, but i did not use head only 2.3.
Got stuck here after pulling latest 2.3 version.

Today I tried to update an older opensuse/portus:head image (0bf3113a7bed) to 2.3 (5fd3f2196938) and it fails on the exact same issue:
portus_1      | Initializing database
portus_1      | portus_production already exists
portus_1      | -- create_table("activities", {:force=>:cascade})
portus_1      |    -> 0.0213s
portus_1      | -- add_index("activities", ["key"], {:name=>"index_activities_on_key", :using=>:btree})
portus_1      |    -> 0.0067s
portus_1      | -- add_index("activities", ["owner_id", "owner_type"], {:name=>"index_activities_on_owner_id_and_owner_type", :using=>:btree})
portus_1      |    -> 0.0069s
portus_1      | -- add_index("activities", ["recipient_id", "recipient_type"], {:name=>"index_activities_on_recipient_id_and_recipient_type", :using=>:btree})
portus_1      |    -> 0.0072s
portus_1      | -- add_index("activities", ["trackable_id", "trackable_type"], {:name=>"index_activities_on_trackable_id_and_trackable_type", :using=>:btree})
portus_1      |    -> 0.0071s
portus_1      | -- add_index("activities", ["trackable_type"], {:name=>"index_activities_on_trackable_type", :using=>:btree})
portus_1      |    -> 0.0073s
portus_1      | -- create_table("application_tokens", {:force=>:cascade})
portus_1      |    -> 0.0205s
portus_1      | -- add_index("application_tokens", ["user_id"], {:name=>"index_application_tokens_on_user_id", :using=>:btree})
portus_1      |    -> 0.0064s
portus_1      | -- create_table("comments", {:force=>:cascade})
portus_1      |    -> 0.0190s
portus_1      | -- add_index("comments", ["repository_id"], {:name=>"index_comments_on_repository_id", :using=>:btree})
portus_1      |    -> 0.0066s
portus_1      | -- add_index("comments", ["user_id"], {:name=>"index_comments_on_user_id", :using=>:btree})
portus_1      |    -> 0.0071s
portus_1      | -- create_table("namespaces", {:force=>:cascade})
portus_1      | rake aborted!
portus_1      | ActiveRecord::StatementInvalid: Mysql2::Error: Cannot delete or update a parent row: a foreign key constraint fails: DROP TABLE `namespaces` CASCADE

This has been finally fixed with #1970 and https://github.com/openSUSE/docker-containers/commit/293e28998f08f83de50335c854caecb9c1597d89. The head image will contain the fix once it's done building.
Thanks everyone for the feedback :clap:


s3fs w/ multi-processing hangs

Hello, we are using s3fs to store data on s3 as part of our AI evaluations library Inspect AI, and we are seeing that using multi-processing (but interestingly, NOT multi-threading) leads to our data loading hanging. i.e. for our internal function process_eval_logs, this will hang:
baselines_ctf = ["s3://platform.ws.aisi.gov.uk/agents/eval_data/"]
eval_data = process_eval_logs(baselines_ctf)

and this will not:
baselines_ctf = ["/home/ubuntu/inspect_ai/eval_data_local"]
eval_data= process_eval_logs(baselines_ctf)

It will hang in the s3 case if we use a ProcessPoolExecutor for our dataloading:

    with ProcessPoolExecutor(max_workers=num_workers) as executor:
        futures = {executor.submit(process_eval_log_single, eval_log): eval_log for eval_log in eval_logs}

but Not a ThreadPoolExecutor:

    with ThreadPoolExecutor(max_workers=num_workers) as executor:
        futures = {executor.submit(process_eval_log_single, eval_log): eval_log for eval_log in eval_logs}

I'm happy to give more details on how we are using the library, but before I do that I just wanted to check if this pattern matches to a known issue/limitation?

The asyncio/thread use in fsspec async implementations including s3fs is not safe to fork. Although some attempt is made to detect this manner of launching processes (and there was a PR to improve this in fsspec, which I can't immediately find), those techniques remain imperfect.
Remedies:

launch processes with spawn or forkserver
do not instantiate any filesystems in the main process before using the process poolk
call fsspec.asyn.reset_lock() as the first thing in the task run by the processes.

Thank you for the speedy + helpful reply! It might be worth adding to your docs, as I ctrl + f'd "thread-safe", "concurrency" etc. but couldn't find any mention of what you can + can't do w/ s3fs.

Probably this should be added in https://filesystem-spec.readthedocs.io/en/latest/index.html and referenced from the s3fs docs and others. Would you like to add it? I'm not quite sure where it fits in.

@max-kaufmann We have made some other changes to back off of s3fs concurrency (as it may have been the cause of other deadlocks we saw stack traces for). I think in the name of not ever hanging we probably won't do more inside of inspect here, but I'd certainly be interested if there is a documented solution for the "right" way to do this with multi-processing (and would add that to our docs for users looking to get better parallelism)


Add basic CI. Remove nightly feature. Update libloading.

const_fn feature is stable since Rust 1.31.

Hi, thanks for the contribution :smile:
Could you just also update the CHANGELOG.md with your changes? under the Unpublished section.

Done 😄


Update mock_call docs

closes #942

@kasperski95
Highlight that mock call works only for the interface functions
is that one good enough?


[Error] NotFoundError: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.

Page
https://registry.platformio.org/libraries/arduino-libraries/Ethernet/installation
Stack
at C (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:504857)
    at M (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:509605)
    at Suspense
    at div
    at div
    at ee (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:235281)
    at div
    at main
    at ne (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:238173)
    at C (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:504857)
    at L (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:508906)
    at L (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:664143)
    at C (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:504857)
    at M (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:509605)
    at I (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:508969)
    at p (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:497639)
    at https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:614267
    at ml (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:461645)
    at ml (https://cdn.registry.platformio.org/static/js/main.625578fb.js:2:461645)

Please press Ctrl+R in the browser.


BUG: Publishr config incorrectly moves real prod dep.

Fix publishr config. Fixes #132
Update yarn.lock and update travis config to fail on out-of-date yarn.lock
Update node versions in travis.yml

/cc @boygirl @nwalters512

@ryan-roemer LGTM. I confirmed that publishr postversion no longer removes babel-polyfill

Released in<EMAIL_ADDRESS>The publish-diff for release looks good:
$ publish-diff -o<EMAIL_ADDRESS>-n<EMAIL_ADDRESS>--filter='!dist/**'
Index: package.json
===================================================================
--- package.json<EMAIL_ADDRESS>+++ package.json<EMAIL_ADDRESS>@@ -1,7 +1,7 @@
 {
   "name": "component-playground",
-  "version": "3.2.0",
+  "version": "3.2.1",
   "description": "A component for rendering React components with editable source and live preview",
   "keywords": [
     "React",
     "playground",
@@ -62,8 +62,9 @@
     "check-cov": "npm run lint && npm run test-cov",
     "check-dev": "npm run lint && npm run test-dev"
   },
   "dependencies": {
+    "babel-polyfill": "^6.26.0",
     "babel-standalone": "^6.26.0",
     "codemirror": "^5.30.0",
     "prop-types": "^15.6.0",
     "react-codemirror2": "^5.0.0"
@@ -113,9 +114,8 @@
     "webpack-dev-server": "^1.14.0",
     "babel-cli": "^6.26.0",
     "babel-core": "^6.26.0",
     "babel-loader": "^6.4.1",
-    "babel-polyfill": "^6.26.0",
     "babel-preset-env": "^1.6.1",
     "babel-preset-react": "^6.24.1",
     "babel-preset-stage-0": "^6.24.1",
     "babel-preset-stage-1": "^6.24.1",
@@ -123,9 +123,9 @@
     "webpack": "^1.15.0"
   },
   "publishr": {
     "dependencies": [
-      "^babel-(?!standalone)",
+      "^babel-(?!(standalone|polyfill))",
       "^rimraf$",
       "^webpack$"
     ],
     "scripts": {


Autoclick after holding button

Description
Is there any chance to make that autoclik after holding a given button and stop when relase?
Or at least to change shortcuts button?
Desired Behavior
Autoclik after holding button and stop when relase
Additional Context
No response

Cool feature suggestion, I like it!
Will see what I can do. No timescales tho.


[V1.0] Assertion is added to check expected option is selected from dropdown

This assertion is need to write a Behat test for a scenario in PR https://github.com/Medology/www.healthlabs.com/pull/1026
This new assertion statement asserts whether the expected option in selected in a dropdown select menu.

Paging @BKorenek to review the back-end work in this pull request!
Paging @jose-ochoa to review the testing work in this pull request!


[tests-only][full-ci] Check the file entries' full path in REPORT response

Description
While checking the file entry in the profind response, the existing code checks with the ends with the method which results false positive outcome.
https://github.com/owncloud/ocis/blob/96e5e2e1ba3dddf965edeb51cdad2378e29414c5/tests/acceptance/features/bootstrap/WebDav.php#L5310-L5313
In this PR the entry name is checked strictly with a response from propfind result
Related Issue

Fixes https://github.com/owncloud/ocis/issues/7006
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Technical debt
[x] Tests only (no source changes)

Checklist:

[ ] Code changes
[ ] Unit tests added
[x] Acceptance tests added
[ ] Documentation ticket raised:

@nabim777  Fix the failed scenarios

This PR is currently block due to this issues https://github.com/owncloud/ocis/issues/7006

This PR is block due this issues:

https://github.com/owncloud/ocis/issues/7028
https://github.com/owncloud/ocis/issues/7092

This PR is block due this issues:

duplicate items while doing REPORT request by sharee #7028
unshared item also listed in the response while doing REPORT request by sharee #7092

do we really need to put this PR as blocked? or may be we can adjust the test code and make scenarios for the issue and put those PR in blocked?

[ ] Backport to stable-4.0 https://github.com/owncloud/ocis/pull/7280


Fix Kafka::Consumer#finalize argument error

Fix a Nil pointer argument error in Kafka::Consumer#finalize caused by referencing @topics in conditional and as an argument without a local var.
$ crystal spec
Showing last frame. Use --error-trace for full trace.

In src/kafka/consumer.cr:77:46

77 | LibKafkaC.topic_partition_list_destroy(@topics) if @topics
                                             ^------
Error: argument 'tplist' of 'LibKafkaC#topic_partition_list_destroy' must be Pointer(Void), not (Pointer(Void) | Nil)

@philipp-classen would you mind taking a look?

@agrare Apology, I did not see your pull request. Thanks for it, I'll have a look.

@agrare Your idea is sound. I tried to simplify the original code a bit further. Please have a look at https://github.com/philipp-classen/kafka.cr/pull/2
It still passes your tests. Please have a look that I did not introduce some regressions. If not I would merge that updated version.
Thanks for spotting the problem!

:+1: your change works for me thanks so much @philipp-classen
Closing in favor of #2


benchmarks do not reflect recommended usage

Several frameworks's apps are written in a manner that does not reflect the usage suggested in their docs.
For example, the FastAPI documentation suggests using File() to have files extracted from forms and injected: https://fastapi.tiangolo.com/tutorial/request-files/. But in the benchmarks the Request.form is used just like in Starlette. This is obviously going to be faster, but then it's not using any of the features the framework provides on top of Starlette. If that's what users were doing, they'd be using Starlette.
I suggest that the apps get restructured to better reflect the documented usage of each framework. That is much more useful to users (and framework developers) and would help highlight issues like https://github.com/tiangolo/fastapi/issues/4187

@klen are you open to this? I'm happy to submit PRs, but I don't want it to seem like I am unilaterally trying to hamper specific web frameworks in the benchmarks, so I won't do anything without your explicit approval.


Gesture Handler issues

I open the Pager in Fullscreen using react-native-modalize and a Portal (to hide Navigation tabs). Modalize has a feature "flick / swipe to dismiss", so when I swipe down vertically, I can pull the modal down to close it. (following the finger till threshold)
Pager seems not to bubbling up the gestures, therefore, my vertical pull never reaches the wrapping modal. Is there any chance I could stop preventing the gesture? (horizontal is fine for me, I need to bubble up the vertical one)

i'm not sure, but i think you can get something working using the panProps which takes any PanGestureHandler config available from react-native-gesture-handler likely the activeOffsetY prop in your case

Do you have a little example for me?

no, but here's a reference in their docs: https://kmagiera.github.io/react-native-gesture-handler/docs/handler-pan.html#activeoffsety

I love u, thank you very much! It actually took me a hour to figure out how this works, because it wasn't working like I wish before I also added a failOffset and the activeOffsetX.
            panProps={{
                activeOffsetY: [-0, 10],
                failOffsetY: [-50, 5],
                activeOffsetX: [-1,1]
            }}

Now it really feels absolut great and native.

awesome - glad it worked out!

Might be worth a notice in the readme maybe ?


Redefine reformat for Continuous vectors to address silent loss function bug

Fixes #152
cc @Leonardbcm Could you review please?

nightly fail looks unrelated


how to change tab inactive text color?

I have tried add css like below:
// .hyper.js
...
css: `
  #hyper .tab_tab {color: rgba(255, 255, 255, .3) !important;}
`;
...

But it did not work

@xshadowlegendx You need to drop the #hyper from the style declaration.
css: `
  .tab_tab { color: rgba(255, 255, 255, .3) !important; }
`;


Add runtime jobs and programs to IQX dashboard

@jyu00 commented on Mon Jun 07 2021

What is the expected enhancement?
The "IQX dashboard" Jupyter widget current shows the progress of a circuit job.

It should be updated to also show runtime jobs and programs (name and description). In addition, the widget should be renamed to something like "IBM Quantum dashboard" as the name IQX (IBM Quantum Experience) is no longer used.
This tutorial shows how to use the Jupyter widgets, and the code is in the jupyter directory.

Do we really want to do this?  I made this a couple of years ago before the IQX had similar functionality.  Why not just kill this and have users use the IQX?  This is what I do these days as it is easier.

Stale issue, closing


opt Remove patchelf in start.sh for meta-service

patchelf is not always available in all runtime environments, remove it from start script for ms.

run buildall


Clean up badly packaged cores.

Removes Linux style hidden files and deletes the __MACOSX directory.
This will close #72.

i just moved the cleandirectory stuff into a utility class i have, in case i ended up wanting to use it elsewhere. and i already had a directory copying method in there, too, so just switched to using that since MoveToDir was redundant.
oh and included mras in the cleanup.
lemme know if this all looks good on your end

How about something like that?  Iterate through the files once and get a list of ones that match a bad file filter.  It avoids doing multiple searches and gives the ability to easily add more checks in the future.

yup looks good to me., much cleaner


Solved error when realoding models

Hi! I have been searching about the problem that happened when reloading some models. It seems that is a current  issue of AutoTokenizers.
However, I managed to solve it using the approach  proposed in this [question] (https://stackoverflow.com/questions/62641972/hugging-face-transformers-loading-model-from-path-error). This can be checked with test/load_model.py.

Thanks @MarcosFP97! I'll check and merge your PR.


ORM related concepts influencing design of Core

@ardalis ,
As per DDD, the core has to be agnostic to databases, presentation etc. But in practice i see that most of the design of core is still influenced by EF. The BaseEntity class is best example of it.
Looking from the perspective of a Desktop application developer,  to me the dominance of POCO classes in an application seems to be influenced by RDBMS and ORMs.
For e.g. below is how a ToDoApplication would look like if were not to consider RDBMS.
    public class Person
    {
        public string Name { get; set; }

        public List<ToDoItem> ToDos { get; set; }

        public List<ToDoItem> CompletedItems { get; }

        public void MarkItemAsCompleted(ToDoItem item) { }
    }

    public class ToDoItem
    {
        public string Title { get; set; }

        public void MarkAsCompletedFor(Person user) { }

        public List<Person> Persons { get; set; }

        public List<Person> CompletedBy { get; }
    }

If you completely let go of the ORM, then probably you'll not create the mapping entity ( Person-ToDoItem ) in your core.
The case of Lists
In general, we use Lists to store ordered elements. For e.g. in the code below, as the list is ordered, we are probably going to use item index as a Serial number for the page.
    public class Book
    {
        public string Title { get; set; }

        public List<Page> Content { get; set; }
    }

    public class Page
    {
        public string Title { get; set; }

        public string Content { get; set; }
    }

It is the RDBMS that needs SNo, and Foreign key in the Page entity to link a page to a book. And that shouldn't be a concern of the Core. Right ?
Solution ( In my opinion )
I feel the design of the Core must be driven solely by the functional requirements. Meaning there must be functional classes and not entities, in the Core. Instead of having a BaseEntity in core, i feel the Database Layer must extend the Core Classes, create mapping entities if needed, do the splitting and merging or whatever is required to fit the needs of the ORM or RDBMS. In short, the Core must have the functional classes, while the Database Layer must generate the entities.

That was the first thing I noticed. I also think Core project should only have only POCOs and business rules only. Entities should be moved to infrastructure/repo project, and set up the mapping rules.

That's certainly an option, and I agree it's more pure. But it's also more effort, and I'm not sure there's much to be gained from it. I already get plenty of pushback from organizations and developers when I suggest that domain model types shouldn't be used as viewmodels or API wire format models. Now I would further need to convince them that there is good ROI involved in having a pure domain model of completely PI types that then is mapped to/from very-similar-but-not-quite-identical entity types in the Infrastructure project and also mapped to/from UI-level types?
One can certainly do that. And if it alleviates pain you're experiencing, please be my guest. This starting point is what I consider to be a pragmatic approach that follows SOLID and Separation of Concerns and DDD in a manner that has successfully solved business problems for hundreds of applications. It's not perfect and you should adapt it to suit your needs but I don't think I would have it default to having another set of types beyond what it has now.

I see a big (for me) problem here... let me explain:
For example, let's say I want to program doing a Unit test first approach. I would like to be able to do changes in my domain classes (for example adding new properties to be used in the tests), and I would like to do so without having side-effects in the infrastructure.
This is not possible if domain classes are the Entities for EF! Any change in a domain class would immediately generate a migration.... this should not be happening and all!. Also, you know how complex are working with migrations in a team with many programmers if many people are changing the model at the same time (and if the team is sharing a database for development as is quite common, things get much worse).
Similar situations can happen if I there is a team working in UI that is developing new functionalities. If they are a UI focused team, they literally cannot be generating migrations for each change the do. Of course they will finish having a viewmodel classes where they will do the changes. That was not the idea of the Onion architecture, right?


Change verification of deploy approvals and execution results to require Merkle root

Once the historical Merkle roots have been added to global state, do not make it optional to verify synced approvals and execution results
TODO[RC]: Needs more detailed description.

Fraser told me that this ticket was created when the plan was to store Merkle root hashes for deploy approvals and execution results in global state under a key specific to the individual block (e.g. "da-1", "er-1", "da-2", "er-2" for blocks at height 1 and 2). We didn't implement that in the end, instead opting for a single static key under which the current block's checksums for deploy approvals and execution results are stored in a BTreeMap with 2 entries. Given this new approach, there is no possibility to backfill historical blocks as that would require modifying historical global state.


Build pipeline refactor

XRTK - Mixed Reality Toolkit Pull Request
Overview
Especially for Android, it has become more apparent that we need to better handle post build steps that write to the Android manifest. But we'd also like to support building for a specific platform using the command line as well for our CI/CD pipeline.
Core Changes
At the moment, we kind of lump everything together, but we need to do something where each platform can extend the build window as needed to inject their platform specific options.
Platform Project Changes
Each platform will need to implement and extend the build window options and have a way to switch to the correct build platform target, if necessary, and do any pre/post build steps
Changes

Fixes: #596

Breaking Changes
Entire build pipeline has been replaced
TODO

[ ] Add a dropdown using IMixedRealityPlatforms to switch between build targets in Build Window
[ ] Clean up Build Window and split apart platform specific dependencies
[ ] Move each platform IBuildInfo to their specific repository

Submodule Changes

XRTK Azure Pipelines

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run


Rate goes up and down slowly

Is it normal for rate to go up and down automatically?

I am Using custom mindailyrate 0.1700% but it keeps going up and down on its own. Did I misconfigure something?

See the Market Analysis configuration it provides a dynamic rate.

Oh, that makes sense. And sorry for the misleading error message, I added a bit of detail to it because I like to know what the bot is thinking it is doing.
Is it mentioned anywhere and I missed it in the documentation?

Yes, yes it is, it wasn't clear to me why it was asking for mindailyrate if marketanalisys is on, maybe adding a warning in the log would be a good idea?

Can this be closed?


run-playbit.sh: failed to initialize KVM

OS: Ubuntu 20.04.6 LTS
Steps
sudo apt-get install qemu
sudo apt-get install qemu-utils qemu-system
Startup error upon running ./run-playbit.sh:
Formatting 'disk0.qcow2', fmt=qcow2 size=68719476736 cluster_size=65536 lazy_refcounts=off refcount_bits=16
Could not access KVM kernel module: No such file or directory
2024-11-14T06:43:48.772837Z qemu-system-x86_64: failed to initialize KVM: No such file or directory
I checked and

qemu-system-x86 is already the newest version (1:4.2-3ubuntu6.30)

I set up virtualisation in my BIOS, and now everything works! Thank you!


LinkedListEasy1 solutions in Java

@stormfireuttam Nice work, add links in README as well and well be good to go.

The Readme has been updated as well


Save addresses of contracts deployed with Forge #39

Automated Contract Address Update in Deployment Process
Related Issue
Closes #39
Description
This PR implements an automated process for updating contract addresses in the config file during deployment. It addresses the limitations of vm.writeJson and provides a flexible solution that can work with current and future versions of Forge.
Approach
We've chosen a functional approach that is decoupled from the Forge package. This method allows us to:

Work effectively with the current version of Forge
Easily transition to newer versions when available
Avoid dependency on the resolution of the vm.writeJson issue

This approach was selected over directly fixing vm.writeJson or using a version-specific solution to ensure long-term flexibility and ease of maintenance.
Changes Made

Created a new bash script deployer.sh to handle the deployment process
Modified the deployment script to output JSON format deployment information
Implemented JSON parsing functionality in deployer.sh to extract contract addresses
Added functionality to update config.json with new contract addresses
Updated subsequent scripts to read contract addresses from the config file
Added documentation for the new deployment process
Updated deploy scripts to handle errors properly when required addresses are not set in the config.json

How to Use

Make deployer.sh executable: chmod a+x ./deployer.sh

Set JSON_FILE to './config.json' in the script

Run the deployment using:
./deployer.sh --path  --rpc-url  --chain-id  private_key="" --gas-price <gas_price> --fork-url <fork_url> --broadcast  --etherscan-api-key <etherscan_api_key>
Example:
./deployer.sh --path src/script/DeployLineaStateBridge.s.sol:DeployLineaStateBridge --rpc-url <IP_ADDRESS>:8545 --chain-id 31337

Testing

[x] Tested deployment script with various arguments
[x] Verified correct extraction and updating of contract addresses in config.json
[x] Confirmed subsequent scripts can successfully read updated addresses
[x] Verified error handling when required addresses are not set in config.json

Additional Notes
The script is designed to be extensible, allowing for easy addition of new Forge arguments as needed.

Hi @Ugo-X
Do I understand correctly that this implementation doesn't use JSON output but parses raw text output instead?
Can you share please why you decided not to use JSON?
And also, why one more deploy script?

When explaining the vm.writeJson reason
According to this ongoing issue on Foundry:
VmJson
vm.writeJson cannot add new keys to a json file as it can only update existing keys, hence the reason why in this
Issue comment
They could only update it manually as the keys for the contract were not set.
So if the contracts keys are set in the JSON, the contract addresses will be automatically updated.

I considered three approaches for addressing the issue:

Functional Approach: This approach works effectively. It's decoupled from the Forge package, giving us the flexibility to be creative without being restricted to a specific version of Forge. This is particularly important in case breaking changes are introduced in newer versions. By using this method, we can easily switch to the latest Forge version when it’s updated or when the issue is resolved.

Fixing the Issue with vm.writejson: This approach involves fixing the underlying issue that prevents vm.writejson from adding new keys as specified. Although this is already being worked on by the Foundry team, they haven't resolved it yet. Contributing a fix could help the broader community, and submitting a public pull request would be beneficial.

**Using Suggested Approach by **: This approach will work, but it would become redundant once the issue with vm.writejson is resolved. Additionally, this approach may require switching Forge versions frequently, which could be a hassle, especially when working on different contracts that need the latest version of Forge.

I ultimately chose the first approach because it offers the flexibility to use what works now and seamlessly transition to the latest Forge version when needed. It avoids the potential complications and hassles associated with the other approaches, particularly the need to switch Forge versions frequently.

Also the Deployer script parses the logs of the Forge deploy script.
Extracting the addresses and contracts from the logs, then appends or updates the set json file.
Provided the logs are provided in the same format as written in the current deploy scripts.


Migrate windows wheels for PyPI from appveyor to github actions

We use AppVeyor to build and upload PyPI... for Linux and Mac we use Github Actions since #71 so it would be good to migrate windows as well to have everything in one place with the same syntax

Fixed in #127


Suggest using /Blame when testhost crashes

Description
We've added a Blame DataCollector that can help identify what test is crashing the testhost, but few users discover it or remember it when they need it. It'd be helpful to suggest running with /Blame in the testhost crash output.
Related to https://github.com/microsoft/vstest/issues/1125
User feedback twitter thread: https://twitter.com/archiecoder/status/1248405123929276420
AB#1587368

TBH I'm finding the /Blame feature by itself rather useless. Knowing which test ran last isn't really that helpful - especially if the crash occurs, it's usually off-thread coming from a finalizer or background thread, so it really could be any previously running test causing it. It doesn't seem to me it gives much more information than the standard output window.
The only Blame command I find useful is /Blame:CollectDump;CollectAlways=true;DumpType=full.
However this will fail once a crash occurs, telling that you need to set a PROCDUMP_PATH to the folder where procdump.exe resides, and not I have to re-run again and hope that this time I got it right. This is rather poorly documented and the tool doesn't appear to be a part of Visual Studio.
I'd prefer this tool came as part of Visual Studio and vstest.console.exe would by default pick it up.
Also when running for instance UWP unit tests, if UWP crashes all we get is information that the socket communication with the test running was severed - I'd rather by default the process was monitored and we were told a lot more info about why the process exited. In general troubleshooting crashing test runs could use some documentation and tooling love to make it easier for people to find what the problem is.

Note: upon testhost crash (or failure to launch), we want to display a message suggesting to use the blame command.

This is a new feature and won't be implemented, we are focusing on adding new features to Testing.Platform instead. https://aka.ms/testingplatform


Fixed issues when onboarding HA setup, and issues with Health Check script

I ran into the following issues when setting up 2 containers in HA mode - this PR contains fixes for all 3 issues.
Issue
health-check.ps1 logic is faulty, when setup.ps1 is accessing status-check.txt, the container shuts down
Resolution
Added new function Run-Process that uses a temporary file based on the process ID to grab the output within the function and performs cleanup. This avoids the above issue with file conflicts with setup.ps1 that was causing the issue.
Issue
Passing in HA_PORT doesn't work, as $PORT isn't being passed in correctly in code
Resolution
Changed to $PORT = if (!$HA_PORT) { "8060" } else { $HA_PORT }
Issue
Adding second container doesn't work for HA due to order of operations and incorrect remote access command
Resolution

Changed from -EnableRemoteAccess to -EnableRemoteAccessInContainer
Switched order of execution - -EnableRemoteAccessInContainer then -RegisterNewNode

I've tested running 2 containers in HA mode, it's now working with the Health Check enabled:

I think those changes were added in https://github.com/Azure/Azure-Data-Factory-Integration-Runtime-in-Windows-Container/commit/7eb565787217ee6f1e15665b360af7e0e229f5ab


Fixing Push Refresh issue

Description
Spring Boot 3 changes of https://github.com/Azure/azure-sdk-for-java/pull/35388

API change check
APIView has identified API level changes in this PR and created following API reviews.
spring-cloud-azure-appconfiguration-config


optimized rate limiter filter

@lmx1989219 Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

This is only in a sample, I should probably remove it. I definitely don't want to add guava as a dependency. Sorry for your troubles.

got it
---Original---
From: "Spencer<EMAIL_ADDRESS>Date: Fri, Sep 6, 2019 15:59 PM
To<EMAIL_ADDRESS>Cc: "Mention"<mention<EMAIL_ADDRESS>Subject: Re: [spring-cloud/spring-cloud-gateway] optimized rate limiter filter (#1286)
Closed #1286.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


Resolves cellIds missing

This updates the example to use the exact perfect shape cell ID's used within the original app.
It returns a perfect shape (s2maps.com, fill in all the ids it returns) of the surrounding area. Matching the one within the app.

That ofcourse didn't work, lol


fix unclear rule description

PR checklist

[ ] Addresses an existing issue: fixes #0000
[ ] New feature, bugfix, or enhancement

[ ] Includes tests

[x ] Documentation update

Overview of change:
Is there anything you'd like reviewers to focus on?

CHANGELOG.md entry:

Thanks for your interest in palantir/tslint, @willyboy! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.


WIP livelesson state exposure

[x] syrctl list
[ ] syrctl kill
[ ] Fix leaky state problems
[ ] move request and result handling into functions in their own file that are better organized. You could even write tests for them that way!! OMGONGOMGOPMGOMGOMGOMGOMG
[ ] Should you converge DELETE and GC operations?
[ ] Figure out how the state is currently being tracked with kubelabs. minimally, add mutexes for this like you did with livelessons, etc.
[ ] State management should be easy to find, especially in the api server. Maybe organize this better, in its own file.

Lots of successful operation 2 results??
time="2019-02-08T08:13:45Z" level=debug msg="Received result from scheduler." Operation=2 Success=true Uuid=14-jjtigg867ghr3gye
<IP_ADDRESS> - - [08/Feb/2019:08:13:45 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
<IP_ADDRESS> - - [08/Feb/2019:08:13:45 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
time="2019-02-08T08:13:46Z" level=debug msg="Performing SSH connectivity test against endpoint linux1 via <IP_ADDRESS>:22"
<IP_ADDRESS> - - [08/Feb/2019:08:13:46 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
<IP_ADDRESS> - - [08/Feb/2019:08:13:47 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
<IP_ADDRESS> - - [08/Feb/2019:08:13:47 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
<IP_ADDRESS> - - [08/Feb/2019:08:13:48 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
time="2019-02-08T08:13:48Z" level=debug msg="Livelesson 14-jjtigg867ghr3gye health check results: map[linux1:false]"
time="2019-02-08T08:13:48Z" level=debug msg="Received result from scheduler." Operation=2 Success=true Uuid=14-jjtigg867ghr3gye
<IP_ADDRESS> - - [08/Feb/2019:08:13:48 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
<IP_ADDRESS> - - [08/Feb/2019:08:13:49 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
time="2019-02-08T08:13:49Z" level=debug msg="Performing SSH connectivity test against endpoint linux1 via <IP_ADDRESS>:22"
<IP_ADDRESS> - - [08/Feb/2019:08:13:49 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
<IP_ADDRESS> - - [08/Feb/2019:08:13:50 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
<IP_ADDRESS> - - [08/Feb/2019:08:13:50 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
time="2019-02-08T08:13:51Z" level=debug msg="Livelesson 14-jjtigg867ghr3gye health check results: map[linux1:false]"
time="2019-02-08T08:13:51Z" level=debug msg="Received result from scheduler."  Operation=2 Success=true Uuid=14-jjtigg867ghr3gye
<IP_ADDRESS> - - [08/Feb/2019:08:13:54 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
<IP_ADDRESS> - - [08/Feb/2019:08:13:55 +0000] "GET /exp/livelesson/14-jjtigg867ghr3gye HTTP/1.1" 200 2291
time="2019-02-08T08:13:55Z" level=debug msg="Performing SSH connectivity test against endpoint linux1 via <IP_ADDRESS>:22"
time="2019-02-08T08:13:55Z" level=debug msg="linux1 is live at <IP_ADDRESS>:22"
time="2019-02-08T08:13:55Z" level=debug msg="Livelesson 14-jjtigg867ghr3gye health check results: map[linux1:true]"
time="2019-02-08T08:13:55Z" level=debug msg="Setting status for livelesson 14-jjtigg867ghr3gye to CONFIGURATION"
time="2019-02-08T08:13:55Z" level=debug msg="Received result from scheduler." Operation=2 Success=true Uuid=14-jjtigg867ghr3gye
time="2019-02-08T08:13:55Z" level=debug msg="Received result from scheduler." Operation=2 Success=true Uuid=14-jjtigg867ghr3gye


New Logo for the app

Description:

Make a more attractive LOGO

Existing LOGO :

PR Instruction:

Issue will be assigned on a first come first serve basis.
If you are thinking to make a pr then at first be sure to get assigned.
before pushing your PR please make sure to fetch upstream.
your pr should be pushed on the develop branch only.
try to complete your assigned task within 3 to 5 days and if you need more time then please let me know. As the program has limited time only so please try to complete as fast as you can.
With your PR try to send a screenshot or screen recording of your work

https://user-images.githubusercontent.com/78155991/135870841-b64dfbe0-3aa0-4195-87e6-df3bf1542173.png
I hope this logo is Useful for U, Thank U

Can i do this?

assign it to me i am struggling for the hacktoberfest

@Rishavgupta12345 I am assigning on a first come first serve basis. please check the recent issues I have created.

@Hussain6 you can take this issue.

@Rishavgupta12345  please join our group for discussion.
CLICK HERE TO JOIN.


File loading feeback

File loading feeback
Description

Present a loading popup while waitig for a file to load.
Present error messages if the loading fails.

Platform

Web Version [X]
Windows [X]
Linux [X]

Done for project and model loading


deploying on VS .Net 4.6

Hi and thank you for this amazing project.
I am trying to run some processing and I need OpenCvSharp.Dnn to be included in the project. I couldn't find a version other than OpenCvSharp4 <IP_ADDRESS>90108 that included this library. However I had to change the target program to :
Scripting Runtime: .NET 4.6
for the library to be included and then I could install OpenCvSharp4 <IP_ADDRESS>90108 add in:
using OpenCvSharp.Dnn
Now before I even included the new " using  OpenCvSharp.Dnn" I gave it a go on my hololens and I got the following message:
Setting up 1 worker threads for Enlighten.
Thread -> id: 24c -> priority: 1
You're integrating from APP thread, call item directly instead.
(Filename: C:\buildslave\unity\build\PlatformDependent/MetroPlayer/AppCallbacks.cpp Line: 438)
The program '[3356] HoloLensVideoCaptureExample.exe' has exited with code -2147483645 (0x80000003).
And the application for the "HololensVideoCapture" seems to be running fine. (I'm not sure if it actually uploaded or if it ran into a problem and Just rolled back to the previous version - I'm a beginner with the Hololens )
So I wanted to see if anyone has tried running this program in a runtime .Net 4.6 environment and are there any major problems I should be aware of .
Thank you for your amazing work.

Actually, I can see now that I actually can't include OpenCVSharp in the project because unity gives me an error. Any solutions ?
Thanks for your help


Compliance issue

First off like your slider a lot!
I do have one small issue with compliance you added though, according to the testing tool axe and W3C you are not allowed to put aria-selected on an element with type button.
If you use button you should use the label: aria-pressed instead.
Here is a link to the docs:
https://www.w3.org/TR/wai-aria-practices/examples/button/button.html

Thanks, will check today
Sent from ProtonMail mobile
-------- Original Message --------
On Oct 31, 2017, 11:12 PM, Mick Feller wrote:

First off like your slider a lot!
I do have one small issue with compliance you added though, according to the testing tool axe and W3C you are not allowed to put aria-selected on an element with type button.
If you use button you should use the label: aria-pressed instead.
Here is a link to the docs:
https://www.w3.org/TR/wai-aria-practices/examples/button/button.html
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Sent you a PR to save you some time ;)

Thanks @mickske

According to here, aria-pressed is for toggle button, which is not suitable for slider dots.
I will consider replace <button> with other elements.

Fair enough makes sense to me. Maybe just choose anchor elements instead of buttons. Which does support the aria-selected element.
Just afraid you will break people's implementation who will be relying on buttons through there css at the moment maybe?

Exactly!


[Identity] Support cross-tenant authentication

Support the scenario described in https://docs.microsoft.com/bs-latn-ba/azure/azure-resource-manager/authenticate-multi-tenant.
To test it, the shared image gallery scenario takes advantage of this type of authentication header: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/share-images-across-tenants

The customer that reported this is using the track 1 management SDKs so this might have to be done also in autorest-clientruntime-for-java.


Disable ssh_key_pair generation when an existing keypair is being passed in

what

If you're passing in a keypair name, don't generate one, and done try to load a local file that doesn't exist

why

You want to use an existing keypair
You don't want plan to fail.

references

https://gist.github.com/BGarber42/d2710437f649c1d8908b3f6bc602adde

In our bastion component, we use an additional ssh key enabled toggle and pass that in to explicitly enable and disable the module itself. I think we want to add that here instead.

/test all

/terratest


Add fold support on device

Ticket
Link to Github Issue
Problem description
need to have fold works on device for WH
What's changed
impl fold as a chain of transpose, reshape, pad, and slice
Checklist

[ ] Post commit CI passes
[ ] Model regression CI testing passes (if applicable)
[ ] New/Existing tests provide coverage for changes

fyi @tt-aho @mywoodstock


Split encapsulate/decapsulate functions in Ind_cca.rs

Both functions get out of memory when verifying the post-conditions, this issue is to address that problem by splitting those functions in order to get them verified.

This issue is addressed in this PR https://github.com/cryspen/libcrux/pull/559


⚠ sandbox-api.piste.gouv.fr healthcheck has degraded performance

In d7a41ad, sandbox-api.piste.gouv.fr healthcheck (https://sandbox-api.piste.gouv.fr/cassation/judilibre/v1.0/healthcheck) experienced degraded performance:

HTTP code: 200
Response time: 2848 ms

Resolved: sandbox-api.piste.gouv.fr healthcheck performance has improved in 6bc8412.