[RFC] Remove recursive aliases

Recursive aliases were introduced when we were implementing JSON parsing. We needed a type that could be Nil, Bool, Int64, Float64, String or an array of those same things, recursively, or a hash with values of those same things, recursively. So we decided that having a type that could reference itself in its definition was the way to go.
That works, but it has two disadvantages:

We can't define methods on this new type, because we can't define methods on aliases
The language already has a way to express recursive types!

For example, the current definition of JSON::Type is:
module JSON
  alias Type = Nil | Bool | Int64 | Float64 | String | Array(Type) | Hash(String, Type)
end

We can express that same thing using a struct:
module JSON
  struct Type
    @value : Nil | Bool | Int64 | Float64 | String | Array(Type) | Hash(String, Type)

    def initialize(@value)
    end
  end
end

Or simpler using the record macro:
module JSON
  record Type, value : Nil | Bool | Int64 | Float64 | String | Array(Type) | Hash(String, Type)
end

In terms of memory representation and performance it's exactly the same: a recursive alias is a union, and as such it's represented as a struct.
Now, when working with a recursive alias such as JSON::Type we can simply cast a value to an integer using json.as(Int64). With the struct approach we have to do json.value.as(Int64). But since we don't like those casts, we have JSON::Any in the standard library which wraps the JSON::Type alias. Sounds familiar? We could have simply never used a recursive alias in the first place! Just make JSON.parse return a JSON::Type that is already a struct whose value is the union of possible types (recursively). Want to get the raw value? Call value. Similar to JSON::Any.
That said, I believe we can safely remove recursive aliases from the language. They are not an essential feature, and in fact using a struct is better because we can add methods to them. And removing them will also simplify the compiler's code.

And in fact, this also solves another problem that's a source of confusion and complaint with JSON::Any. Right now we have: JSON::Any#to_a which assumes the raw value is an Array and returns it as such. But this Array is of JSON::Type, not of JSON::Any, so we can't invoke to_a on them.
Using the struct approach, the elements are themselves JSON::Type which will provide these methods. So much simpler and powerful!

Nice thinking. This looks great

At first I immediately didn't like the proposal because I use recursive type aliases a lot in a personal toy project (https://github.com/lbguilherme/rethinkdb-lite) and it will break badly. But looking carefully, this looks great. I wasn't aware that an struct could have a self-reference like this, nice!
One issue I see a lot is taking an Array(String) and turning this into, say, JSON::Type. This is what you need to do now:
x = ["a", "b"]
x.map(&.as(JSON::Type)).as(JSON::Type)

And for the future:
x = ["a", "b"]
JSON::Type.new(x.map {|e| JSON::Type.new(e) })

But JSON::Type could have a constructor taking any Array and doing the map in the constructor, so this would be reduced to just JSON::Type.new(x), which I like a lot.
+1 for this change. The refactoring will result in better code after it.

@Papierkorb @oprypin Care to share why you 👎 ? I'm honestly interested in what you have to say about this (I only used recursive aliases in JSON and YAML and in these cases I think they are not very useful, but maybe there are other use cases I'm missing).
In the meantime, I will try to refactor JSON (and probably YAML) to use this approach and see how it goes, if the API ends up being nicer.

I wasn't aware that an struct could have a self-reference like this, nice!

This is kind of guesswork, but I think the key here is in the union; IIRC without it, recursive structs wouldn't be supported, since they would take infinite memory... but it works here because the union adds a pointer indirection.

kirbyfan64: It works here because the struct isn't self-recursive, it contains itself only by way of Array or Hash intermediaries, both which of do add indirection.

There are many layered reasons I dislike this RFC.
Comments on the proposal text

in fact using a struct is better because we can add methods to them

I don't see this as advantage, actually it's a disadvantage:
I can add methods to them.  I don't have to.  The issue is that I as reader of source can't know this, and have to subsequently look it up.  Reading an alias is fast, it's only a single line with a restrictive syntax.  Reading a struct is by very definition more complex.  Thus, not being able to add a method if not needed is an advantage.

And removing them will also simplify the compiler's code.

The language serves the usual programmer, not the compiler developer.  A compiler is not the common program.  I think the presented reasoning is harmful in that it might set a dangerous precedence of throwing stuff out that doesn't make sense for only the compiler, while everyone benefits from it.
I'm also missing discussion of the bigger picture in this RFC.
The purpose of recursive union types
I think we should not discuss throwing out features at random without actually discussing what we actually were trying to achieve in the first place.  It is correct that I wasn't there right from the start, so I have to do educated guesses.
What we want is a way to store data of an union type inside a container for that very union type itself.  It's basically what JSON::Type is.
Issues with the proposed syntax
The biggest issue is that your proposal changes the whole usage semantics of recursive aliases.  The issue isn't even the struct (I regard that as implementation detail).  But that I now have to use #value to get the data out of it.  This in turn clutters the users code with .value for no gain on their end.
Possible solutions
The current solution is using an recursive alias.  You propose making the user manually write a struct instead.
Without knowing the compiler source, I see a few other solutions countering the two main issues: Compiler complexity first, then the verbose struct-as-alisa syntax second:

Allow for recursive structures using the current syntax.  The compiler can detect if it's recursive, and if so, rewrite it to a struct internally (Also with automatic #value unpacking).  Then the compiler could rely on the existing, reliable struct code emission.  Hopefully, this would reduce overall complexity, focusing this language feature in a single place instead of all-over-the-place.
If my assumption in 1. is wrong, at the very least offer a recursive-alias-struct macro, and market it as such.
Or of course, also an option, fix the existing code.

A short use-case study
So what's the use of recursive aliases?  At least for me, the following is a common pattern:
def visit_recursively(value : JSON::Type)
  case value
  when String then visit_string(value)
  when Array(JSON::Type) then visit_array(value)
  # And so on ...
end

Observations:

I assume that for many users, value is a popular (as fitting) name for the variable.  Having to write case value.value is more confusing than simple case value.
With the struct, you'd actually have to write: case v = value.value.

Another possible solution
I see one possibility of using the struct solution, while getting rid of the #value spam.  However, this would require changes to a different part of the language:

Make Object#as(T) overridable.
Make Object#===(T : Class) overridable.
No change to Object#is_a?.
Alternatively, add Object#like_a?(T), checking if #as(T) exists and if #===(T) would return true.  Does appropriate type restrictions in the following body, just like #is_a?.

The algorithm when encountering an (implicit) value type check would now be as follows:

Encounter a case condition checking for a type
Check if Object#=== returns true, and that Object#as(T) exists
Implicitly call #as(T) on the value and retype its type restriction in the inner block as is done today
Else, do all other already existing checks

If #like_a? is accepted, the algorithm would be:

Encounter a case condition checking for a type
Check if #like_a?(T) is true
Do the re-typing

This would allow the user (the stdlib) to write recursive alias-structs without spamming other code with it.  This also elevates user types to first class citizens for the compilers type deduction.
Conclusion
This is a hard topic.  "Just throw it out" is in my opinion too short-sighted and harmful.  In the end, you have to pick your poison: To diverge from what made Crystal great by keeping boilerplate to the absolute minimum, or to make the language more powerful.

@Papierkorb I understand your reasoning.
When I say "it will simplify the compiler" I also meant "it will simplify the language". Removing a feature that is essentially a duplicate of another feature (the way I see it) is better: less things to learn, less ways to do a same thing.
As far as I know, no such feature exists in other programming languages. I'm pretty sure that's because it's not needed.
I personally don't see writing json.value as something that's so terrible. Plus you can have methods to extract the value from it (in fact JSON::Any has this right now) so you can do:
if string = json.as_s?
  # string
elsif array = json.as_a?
  # array
end

and of course you can also do this, as you say:
case value = json.value
when String
  # ...
when Array
 # ...
end

Comparing having to write value = json.value vs. adding a feature that's complex to implement and understand (maybe not for you or for me, but it is tricky), that's bug prone (for example you can define a recursive without a base type and that crashes the compiler, and I don't know yet how to detect that, plus having to repeat the logic of detecting an infinitely expanded recursive alias as a struct) and that simplifies the language (less concepts to learn), I prefer having to write that. I mean, if we remove the feature you will have to write maybe 10 more chars in an entire program. I don't think that's a reason to keep a feature.
In any case, as I said, I'll try to refactor the std to not use recursive aliases at all and see how it looks and feels like. Maybe then I'll have a better opinion on this.

As far as I know, no such feature exists in other programming languages. I'm pretty sure that's because it's not needed.
No, it's because it's not possible. If you removed union types, on the other hand, then it would not be need. And oh boy how much simpler the compiler would become!

As far as I know, no such feature exists in other programming languages. I'm pretty sure that's because it's not needed.

I don't know if any other static-typed language has this feature, or a feature like this.  I just want to point out that this may be a fallacy.  I think the type system of Crystal is kinda unique, and with that, unique solutions to problems can (and should!) evolve.

@oprypin I actually believe that removing union types from the languages would be something good. I know it's one of the things that make Crystal unique, but I now think algebraic data types are better, and probably just nullable types (not union of X and Nil). But it's probably too late to change all of that now.

Without union types, I wouldn't be using Crystal at this point.  It also is the most popular (most liked) feature when the question "What do you like the most in Crystal?" comes up every other week in the chat channel.
Functional programming is nice.  But not that nice.  Ruby showed that copying the useful parts from FP while maintaining a OOP language is not only feasible, but actually good.  Crystal simply improves upon this, and for good reason.

As far as I know, no such feature exists in other programming languages. I'm pretty sure that's because it's not needed.

Well, one alternative explanation is that it is hitting the boundaries on where the research frontier is.
http://www.cl.cam.ac.uk/~sd601/papers/mlsub-preprint.pdf made a fairly large splash when it came earlier this year and is an example of a paper that is investigating the general area of recursive typing and hindley-milner. It has an example implementation at https://github.com/sweirich/hs-inferno - see the tests for examples.

I think without recursive alias y-combinator looks quite difficult to achieve:
alias T = Int32
alias Func = T -> T
alias FuncFunc = Func -> Func
alias RecursiveFunction = RecursiveFunction -> Func

fact_improver = ->(partial : Func) {
  ->(n : T) { n.zero? ? 1 : n * partial.call(n - 1) }
}

y = ->(f : FuncFunc) {
  g = ->(r : RecursiveFunction) { f.call(->(x : T) { r.call(r).call(x) }) }
  g.call(g)
}

fact = y.call(fact_improver)
fact = fact_improver.call(fact)
pp fact.call(5) # => 120

https://carc.in/#/r/2xpy
https://stackoverflow.com/questions/45237446/recursive-proc-in-crystal
I almost got it but failed 😅
record T, value : Int32 do
  def *(other)
    self.value * other.value
  end
end
record Func, value : T -> T
record FuncFunc, value : Func -> Func
record RecursiveFunction, value : RecursiveFunction -> Func

fact_improver = ->(partial : Func) {
  ->(n : T) { n.value.zero? ? 1 : T.new(n.value) * partial.value.call(T.new(n.value - 1)) }
}

y = ->(f : FuncFunc) {
  g = ->(r : RecursiveFunction) { f.value.call(->(x : T) { r.value.call(r.value).value.call(x.value) }) }
  g.value.call(g)
}

fact = y.value.call(FuncFunc.new(fact_improver))
fact = fact_improver.value.call(Func.new(fact))
pp fact.value.call(T.new(5)) # => 120

https://carc.in/#/r/2xq3
WDYT @veelenga ?

the Y combinator can be used to formally define recursive functions in a programming language that doesn't support recursion.

So why would you write such code in crystal?

So why would you write such code in crystal?

@monouser7dig Not use case at all, just wanted to make a y-combinator 😅 and @veelenga gave me a brilliant solution using recursive alias 😉

@faustinoaq ok I thought this was supposed to be an argument for keeping rekursive aliases and that  surprised me
I have no string opinion on the recursiveness, I'd just like to have usable typeoptions instead of alias

Thinking about this, as long as performance is the same (it is in this case), I mostly don't care what happens behind the scenes. All I care about is the syntax.
I'm okay with this change:
#before
alias Type = Nil | Bool | Int64 | Float64 | String | Array(Type) | Hash(String, Type)

#after
record Type, value : Nil | Bool | Int64 | Float64 | String | Array(Type) | Hash(String, Type)

But I do not like this change:
#before
def foo(thing : Type)
  case thing
  when Float
    #do stuff
  when Bool
    #do stuff
  #etc..
  end
end
foo(123)

#after
def foo(thing : Type)
  case (t = thing.value)
  when Float
    #do stuff
  when Bool
    #do stuff
  #etc..
  end
end
foo(Type.new(123))

Is there no way to keep the same syntax while changing things behind the scenes?

Should we go forward with this? The standard library doesn't use recursive aliases anymore, and it seems others are finding wrappers like JSON::Any more useful than recursive aliases (cc @straight-shoota).
I can send a PR to remove this feature from the language.
After that, I can probably implement generic aliases (it's much easier once recursive aliases aren't possible).

If removing recursive aliases gets us generic aliases, i'm all for it.

I hope recursive alias would come back eventually. I think they are easier to think about them than the indirection of a wrapper struct.
But I understand there is no clean solution right now with recursive aliases and nested values (the now old JSON::Type vs JSON::Any in constructor issue). Since I don't see an easy way to solve that for the time being, I accept dropping recursive aliases.

Yes, actually, maybe we could keep recursive aliases but remove the JSON:Any wrapper at all. You'll have to cast the value to use it, but maybe that's more intuitive than a wrapper.
It will seem like we are going forward and back with this, but given that the concept doesn't exist in other languages, and that Crystal is an experiment, and we are not 1.0 yet, it might be acceptable.

Most strongly-typed languages I know only have a pull parser and a mapping equivalent.

I have a love-hate relationship with recursive aliases. They are actually quite elegant for parsing not-well-known JSON (YAML, etc.) structures without introducing intermediate types. So, originally we had:
module JSON
  alias Type = Bool | Int64 | Float64 | String | Array(Type) | Hash(String, Type)

  def parse(string_or_io) : Type
    # ...
  end
end

That way you could parse something and immediately get a union of all possible values. Of course you can't do much with that: if you want to work with it you probably will have to cast it. For example:
value = JSON.parse("...")
array = value.as(Array) # assert it's an array
array.each do |elem|
  # ...
end

Actually, there are a few things you can do generically with the value: compare it using == and ===:
value = JSON.parse("...")
case value
when "string" # works because of String#===(String)
end

With JSON::Any this isn't as nice because we have to reopen add String#===(JSON::Any) for that to work (remember that case exp; when value is translated to value === exp).
Now, let's say we remove JSON::Any and go back to using recursive aliases... well, actually, we can't get rid of JSON::Any, because if you want to do something like:
class MyObject
  property number : Int32
  property any : JSON::Any
end

with an any that could have any of the JSON types, we need to define any with a type that has a class method from_json: and recursive aliases can't have methods, because they are just a union type (kind of). Or, well, there's simply no syntax to reopen an alias and define methods on them (it would be a bit weird, because we could only define class methods).
So... JSON::Any is needed (at least for JSON, but I'd expect the same need for other libraries that need recursive types) , and now we have two ways to represent almost the same thing: the (recursive type) union of all JSON types, and the JSON::Any wrapper.
Thinking a bit more about the == and === case above, it might be a bit "dangerous" to compare a JSON::Any to a string. What if it's not a String at all? The comparison will silently fail, and if we don't handle it, well, it might lead to a bug. If we remove == and === from JSON::Any, the user will probably have to get the value and cast it to a String first, using, say, as_s (or, well, it could get the raw value and have the same problem, so maybe it's still "dangerous").
Another nice thing about recursive aliases is that we can do:
value = JSON.parse("...")
value.as(Array) << 1 # works

With JSON::Any we have to do:
value = JSON.parse("...")
value.as_a << JSON::Any(1) # Ugh

It's a bit tedious, but maybe this isn't needed very often. Or maybe it's good, because it reminds us we are dealing with a JSON::Any and not any kind of array?
So, I'm not sure which way is winning yet... Is there anything nice about JSON::Any? Yes! We can define [] on it, and internally check if it's an Array or Hash, so we can do this:
value = JSON.parse("...")

# We are hitting an API and we know the shape of the response, so...
value["data"]["users"][0].as_h

With just a recursive alias we'd have to do:
value = JSON.parse("...")

# We are hitting an API and we know the shape of the response, so...
value.as(Hash)["data"].as(Hash)["users"].as(Array)[0].as(Hash)

Super verbose! And I think this case is much more frequently needed then modifying the parsed JSON, because we usually parse JSON from an API or as read-only access.
...
Actually, thinking it a bit more, JSON::Any might not be needed: we can have JSON::Any.new(pull_parser) to parse and return a value whose type is the recursive alias type, not JSON::Any. But you'd have to do it like:
class MyObject
  @[JSON::Field(converter: JSON::Any)]
  property x : JSON::Type
end

Maybe that's acceptable. Then we won't have the wrapper any more, just the recursive alias... and we'd try to fix the bug surrounding it. But of course you'd have to use casting, a lot, to use it.
So... I have a local stash with changes that remove recursive aliases from the language, but I'm not sure it's totally good to remove them. We should evaluate the pros and cons, and if we decide they stay, we should remove the JSON::Any wrapper too.

I think you perfectly explained the love-hate relationship. I share it.
I prefer to use PullParser manually or automated (Serialization).
But being capable to do value["data"]["users"][0] is invaluable when overwhelmed with potential schemas (see selenium webdriver) that make creating structs or classes a very tedious task (and could slow down compilation, introducing so many types).
But then, .as_s or .as_h are meh, at best. Having [] also calls for .each, which calls for including Enumerable, adding == and === for supported types... and ugh.
I have a project at hand with aliases. I try to avoid recursive aliases, it feels kinda limiting, but it's not that bad. I think I could live without recursive aliases, thought they're nice.
About your last snippet, we could just have JSON.new(pull) : JSON::Type and totally get rid of Any... but then we lose Any[]... I guess I could live without it, too.

class method from_json: and recursive aliases can't have methods, because they are just a union type (kind of). Or, well, there's simply no syntax to reopen an alias and define methods on them (it would be a bit weird, because we could only define class methods).

But we already have Union.from_json: https://github.com/crystal-lang/crystal/blob/9ba6ba93e3cd1d53a5df0131c8aa4d272a56a6c3/src/json/from_json.cr#L192
Wouldn't JSON::Type.from_json work "out of the box" (but slow because of raise, maybe we could speed it up by trying Hash or Array first depending on token type)?
But that's missing the point: the point of JSON::Any isn't to implement from_json, it's to avoid the .as ugliness by overloading []. You can't do that without a wrapper. But then again, Go makes people just deal with the cast pain and perhaps thats a good thing. Arbitrary JSON without knowing the structure is a pain in typed languages and maybe we shouldn't hide it.

As a footnote, == and === and <=> etc. are commutative operators, yet the language doesn't treat them as such. It forces you to manually implement the commutativity by reopening classes. Perhaps thats a problem to think of a better solution to. Perhaps the compiler could automatically commute the arguments to get the most precise overload. Then again, complexity, magic, etc etc etc...

Yeah, implementing commutative operators would be nice. But at least === is not commutative.

<=> is about as far from commutative as you get. It literally is the case that x <=> y is -(y <=> x)

@yxhuvud yeah sorry, my bad.
Maybe we could just have macros do this, unfortunately it's not possible for a macro to reopen a class unless it's invoked at the top-level.

Regarding https://github.com/crystal-lang/crystal/issues/5155#issuecomment-403330684

What if it's not a String at all? The comparison will silently fail, and if we don't handle it, well, it might lead to a bug

This is the same issue why == and === can be applied in all objects and why some containers methods do not restrict arguments to the type parameter: In order to get a less pedantic and easier to be used API.
I already say I like recursive aliases, I found them intuitive to express some structures. I only acknowledge to remove them in the light of generic aliases hoping that recursive aliases will come back later.
Regarding the JSON::Any, maybe another way to go is to use recursive alias as the structure but let a macro do the navigation. It would be a bit more verbose that value["foo"][0]["bar"], but a  JSON.get(value, "foo", 0, "bar") and a JSON.get? macros could allow us to keep using the values defined as recursive alias directly.

We could possibly implement .dig from ruby to avoid the casts. Then remove JSON::Any and be done with it.
Actually, I'm thinking that that's probably by far the most sane idea.

But there's no dig for int, bool or string.

How will #.dig help me recursively parse an entire json that I have no knowledge of the schema beforehand?

.dig is just turning value.as(Hash)["data"].as(Hash)["users"].as(Array)[0].as(Hash) into value.dig("data", "users", 0).as(Hash). The only reason we introduced JSON::Any was to turn the casting mess into value["data"]["users"][0], so if we've solved that problem and solved recursive aliases, then there's no need for JSON::Any.

How would you call value.dig if it's not defined on every type in the union?

@straight-shoota exactly!
@RX14 the json any recursive alias also has bool, int and string in it, and there would be no dig for those types.

I guess you could start from the hash (as it's the most common structure returned anyway) and use #dig from there (value.as(Hash).dig("data", "users", 0))?

Probably.
I'm not sure what we are trying to solve with dig...

@asterite the same way it's implemented right now in the already-existing PR: responds_to?

The thread is about removing recursive aliases, and to weight alternatives to keep it or not in the light of the principal use case deserialization. I believe an alternative shouldn't just work, but be as nice as, or better than Any. So far, proposals seem to fail that.
Sadly, because I'm not fond of Any myself, yet I struggle to see a better alternative :disappointed:

The problem with dig as an alternative to JSON::Any (which I didn't catch on to you explaining, sorry about that) is that JSON.parse returns JSON::Type instead of Hash(String, JSON::Type) | Array(JSON::Type). Changing JSON.parse to fail when parsing a string, bool, or nil at the top level wouldn't be a huge deal. Several existing libraries do this already, and not having an array of object at the top level is rare. We could provide another method which returns JSON::Type.
For me, dig is the only concept I can think of which comes close to replacing Any#[]. So I'm trying to think up how it could work to come up with a solution and syntax which can be pitted against Any, if we all agree that we don't like Any.

@RX14 The RFCs actually explicitly allow the other types at the top, nowadays. See https://stackoverflow.com/questions/17220924/does-the-top-level-value-in-json-have-to-be-an-array-or-object
This is something that has changed over time - the first RFC on it only allowed Objects and Arrays.

I actually like the concept of JSON::Any. It wraps a value with a dynamic data type and has methods for accessing it.
While you can retrieve nested values using a series of [] calls, it would actually make sense to define a #dig method in order to avoid raising when the data is incompatible.
value["data"]["users"] # raises if value or `value["data"]` don't wrap a Hash
value.dig("data", "users") # returns `nil` if value or `value["data"]` don't wrap a Hash
# without `dig` this is ugly:
value.as_h? && (data = value["data"]?) && data.as_h? && data["users"]?

After recursive aliases where removed with JSON::Any, I also refactored Crinja::Value with the same concept. The diff (mostly in https://github.com/straight-shoota/crinja/commit/57b2fcd43dbd406fb2e790141d8fd539bc4a085c) gets rid of ugly .as(Crinja::Type) casts and in my opinion improved the code dealing with such values in many places. This wrapper type also defines a lot of helper methods for abstracting specifics of the underlying data values. Many of them are particularly useful from within the Crinja runtime, but also for external use. JSON::Any already has similar methods #[], #size and it wouldn't hurt to expand on that. #dig, #each, #first, #last could make it easier to work with JSON::Any.

I've done some experiments about finding an alternative to JSON::Any.
A draft implementation is in this gist - tell me what you think :smile:

I'm starting to think that all this wrappers around YAML and JSON's PullParser will better live outside the stdlib in their shards.
The issues are:

opinionated:  can be lots of different implementations - may I use Any, Serializable, PullParser or others?
safety: can't safely pin a version and use it with the X Crystal version
convenience: possible refactoring with each Crystal release (because of implementation's changes)

@j8r Your implementation uses a completely different approach of parsing JSON structures on demand. In contrast, JSON.parse currently parses an entire JSON document and it can be accessed in memory. Both have it's pros and cons, but for a general implementation, it doesn't make much sense to re-parse the JSON document everytime you try to access a property.

@straight-shoota But in the general case either with this implementation ot any other, it's better to store a property if we want to re-access to it, because more efficient.
This implementation is about this - parse only what you need, and do what you have to do :smile:

I'm with @straight-shoota on this, in our code base the change from JSON::Type to JSON::Any improved the code, the readability and the way we loop around it and parse.
Let's not take a step back, and instead improve upon JSON::Any

What do you think of this gist?
This merges duplicate code of JSON::Any and YAML::Any by using a macro, and add the ability to search keys:
js = JSON.parse %({"a": {"b": "c"}, "e": [{"o": "p"}, 12, 2]})

p js[["a", "r"]]?    #=> nil
puts js["e", 0, "o"] #=> p

If the community like this, I will continue for []= and delete, and then creating a PR.
Of course this lead to less efficient code, but we have no ther choice when dealing with dynamic documents - jq is a perfect example.

Recursive aliases continue to introduce bugs into Crystal code (latest example: #7567). They're buggy and should better not be used at all. We've gotten rid of using them in the stdlib already.
I'd suggest to remove them from the language. It's either that or fixing them.
If we want to try to implement JSON & co deserialization based on recursive aliases (and I don't see we're getting there), it would require fixing recursive aliases first anyway. So we don't really use anything if we remove them now and maybe decide adding a complete implementation at some point in the future. But the immediate benefits would be a simplification of the language and compiler and keeping people from running into bugs caused by recursive aliases.

I'm all for this and I could do it in under one day, after all it's just removing code. But I'd like @bcardiff and @RX14 to agree about this too.

I agree strongly with @Papierkorb's comment here and @shelvacu's comment here in favor of keeping recursive aliases and fixing their implementation. If that's not feasible, I'm with @bcardiff here in that, if they are removed, I hope we can bring them back at some point because of how much easier they make thinking about my program's types.
The struct indirection certainly has a lot of value, which has been shown in this thread, but I don't feel like the recursive alias is just a different way to do the same thing, but more that they are both great for different use cases. The struct is awkward to use in some places where a recursive type does well — this has also been shown in this thread. One thing I've noticed in building apps with Crystal is that if something feels wonky, there's probably a better abstraction you could be using.

@jgaskins Yes, the only reason to remove recursive aliases is because they're broken and there is no perspective to fix them anytime soon. This is not meant as a decision against having recursive aliases in the language.

The @asterite method using Struct doesn't work in generics. I can only get it to work in macros. This is as good as I could do this evening.
# Implementation of a pseudo-generic that contains itself without use of
# recursively-defined aliases, which are problematical and/or broken
# in the compiler.
macro recursive_hash(name, keytype, valuetype)
  struct Type_%a
    property value : {{valuetype.id}}
    def initialize(@value)
    end
  end

  class {{name.id}}
    @h = Hash({{keytype.id}}, Type_%a).new

    def []=(key, value)
      @h[key] = Type_%a.new(value)
    end
  end
end

recursive_hash(MyHash, Symbol, String|MyHash|Array(MyHash))

h = MyHash.new
h[:itself] = h
h[:array] = [MyHash.new]
p h.inspect

@BrucePerens What's your use case?

The initial implementation of a shard for generics that can contain themselves is at https://github.com/BrucePerens/recursive_generic .
It's not ready for your use yet.

I'd like simple aliases like "def foo; end; alias bar foo"!

@rubyFeedback FWIW this issue is about recursive type types, not methods.  E.g.
alias BigInt = Int64

def double(value : BigInt)
  value * 2
end

See https://crystal-lang.org/reference/syntax_and_semantics/alias.html and also https://github.com/crystal-lang/crystal/wiki/FAQ#why-are-aliases-discouraged.

Having worked with the compiler's code I can tell that recursive aliases are a pain to deal with because they are, well, recursive aliases to non-recursive types, instead of non-recursive aliases to recursive types. Proper inference for recursive types is probably needed to avoid false positives like this:
x = 1
y = pointerof(x)
x = Pointer(Int32).null
# Error: recursive pointerof expansion: Pointer(Int32), Pointer(Int32 | Pointer(Int32)), ...

I have had this rough idea where all types in Crystal are recursive during type inference, and their actual types are defined to be the least fixed point of an equivalent alias expression, formed by repeated substitution. This gives:
alias T1 = T1                # => NoReturn
alias T2 = Int32 | T2        # => Int32 | Int32 | ... = Int32
alias T3 = Int32 | Array(T3) # => Int32 | Array(Int32 | Array(...)),
                             #    *not* Int32 | Array(Int32) | Array(Int32 | Array(Int32)) | ...

Every node initially has the type alias T = T where T is unique to that node, and ASTNode#bind_to essentially adds a new type to the right hand side of the above alias as a union variant. This allows us to type the following snippet:
# x : alias T1 = Int32 | T1
x = 1

while rand < 0.5
  # y : alias T2 = Array(T1) | T2
  y = [x]

  # x : alias T3 = T2 | T3
  x = y

  # in a while loop the `x` before the loop must be merged with the last `x` inside
  # x : alias T1 = Int32 | T3 | T1
end

# we have:
#
# T2 = Array(T1) | T2
#    = Array(T1)
#
# T3 = T2 | T3
#    = T2
#    = Array(T1)
#
# T1 = Int32 | T3 | T1
#    = Int32 | T3
#    = Int32 | Array(T1)
#    = Int32 | Array(Int32 | Array(Int32 | Array(...)))

Going back to the pointer example, the type of pointerof(var) is the union of Pointer(T) for every type T ever observed by the variable var. We have:
x = 1                   # x : alias T1 = Int32 | T1
y = pointerof(x)        # y : alias T2 = Pointer(T1) | Pointer(T3) | T2
x = Pointer(Int32).null # x : alias T3 = Pointer(Int32) | T3

# T1 = Int32
# T3 = Pointer(Int32)
# T2 = Pointer(T1) | Pointer(T3) | T2
#    = Pointer(Int32) | Pointer(Pointer(Int32))

The corresponding recursive case is:
x = 1            # x : alias T1 = Int32 | T1
y = pointerof(x) # y : alias T2 = Pointer(T1) | Pointer(T3) | T2
x = y            # x : alias T3 = T2 | T3

# T1 = Int32
# T3 = T2
# T2 = Pointer(T1) | Pointer(T3) | T2
#    = Pointer(T1) | Pointer(T2)
#    = Pointer(T1) | Pointer(Pointer(T1) | Pointer(Pointer(T1) | Pointer(...)))

This requires a complete rewrite of the bind_to logic, but IMO it actually makes type inference easier to reason about, and gives us working recursive aliases at the same time.

IIUC, @HertzDevil  you're saying that every type is recursive until proven otherwise? Isn't that dangerous from the point of view of performance?


Auto merge PRs to branch-24.10 from branch-24.08 [skip ci]

As the title

build

try git commit --amend to re-generate the hashcode and force push to see if retrigger. Github action is buggy..

try git commit --amend to re-generate the hashcode and force push to see if retrigger. Github action is buggy..

Yes, should be GitHub bug , found similar issue reported : https://github.com/orgs/community/discussions/49257

try git commit --amend to re-generate the hashcode and force push to see if retrigger. Github action is buggy..

Yes, should be GitHub bug , found similar issue reported : https://github.com/orgs/community/discussions/49257

this is a different case...do you want me to force merge this one?

try git commit --amend to re-generate the hashcode and force push to see if retrigger. Github action is buggy..

Yes, should be GitHub bug , found similar issue reported : https://github.com/orgs/community/discussions/49257

this is a different case (open a PR via actions/github-script@v6)...do you want me to force merge this one?

commit --amend to upload a new hash commit ID but without file changes seems not working, either.
Yes, please help force merge it.


Unable to package application using dotnet electronize build /target win

Hi,
I guess the issue is with electron packager.
When I try to package my application using command dotnet electronize build /target win , I encountered the followings:
electron-packager . --platform=win32 --arch=x64 --out="C:[app_path]\bin\desktop" --overwrite
Packaging app for platform win32 x64 using electron v1.7.8
rcedit.exe failed with exit code 1. Fatal error: Unable to commit changes

Do you get the same error when you try to invoke the electron-packager directly (e.g. open a command prompt and execute this command)?

@robertmuehsig , when I run the electron-packager, I got:
Error: Cannot find module electron from 'C:'
at C:[path]\npm\node_modules\electron-packager\node_modules\resolve\lib\async.js
.......
at FSReqWrap.oncomplete (fs.js:152:21) code: 'MODULE_NOT_FOUND'

Hi,
I've cleanup everything, re-install again but having the same issue.
Can you try packaging it on your end?
Thanks.

Hi @ronish-potiah-cko,
which CLI version is installed?
Use this command please:
dotnet electronize version

@robertmuehsig I had to move my core development to straight Electron, so I haven't had a chance to check. That said, I spent quite a bit of time deconstructing the architecture of Electron.NET over the past couple months am convinced that the dotnetelectronize CLI app is a huge anti-pattern that just needs to be killed. It's an example of the classic "build systems are too complicated, I'll just whip up a quick C# app that execs the stuff I need and that'll be better." And then it's not enough, so there's a v.next that does more, and does it better. But it's still not enough. And then it gets more complicated. And another hack gets added onto it. Electron apps and modern front-end development live in a world of npm and webpack. Npm and webpack each have >100x more dev-years invested in them than all of Electron.NET. They aren't complicated. And they are proven to scale and solve the real world complexity problems a build system really does need to solve. dotnetelectronize has already reached a level of complexity where it's consuming real architectural time and takes real time for other devs to understand and learn, and it's already lacking the next feature the next dev to try to adopt Electron.NET is going to need.
Your coding time is incredibly valuable. Please don't waste it on a totally non-scalable C# hack to "save us" from needing to understand npm and webpack. Throw away dotnetelectronize before it burns any more of your precious-to-us time and replace it with a couple entries in the scripts section of packages.json and a bit of webpack.config.js. You'll be much happier and we'll be much happier and the community will be able to do much more much faster. Npm and webpack simply aren't hard tech to learn and they are tech any dev doing modern frontend development simply has to understand. dotnetelectronize isn't a time saver or an effort saver or a cognitive saver. It's an anti-pattern.

@yoDon Thanks for your honest answer. Electron.NET is (at least currently) just a fancy idea/experiement with some good ideas and some mayor flaws. Sticking to the "pure" electron might be a pretty logical idea IMHO, because we can't competete with the manpower behind the other Electron related projects.
"Wasting" our time is a pretty hard description. At least we are learning quite a few things about OSS, Electron and .NET Core - so - everything is good for us :)
Maybe Electron.NET is a anti-pattern, but I know a bunch of people that actually hate Electron itself and they say the same thing about Electron. There are tons of other options (e.g. use the normal Electron, or Xamarin, or some magic cross compiler). Our goal is to write cross platform .NET applications and there are some ways to achive this. Use what works for you :)

@robertmuehsig thanks for hearing my comments in I think the way they were intended, with great respect for what you're doing and a deep desire for the project to succeed.  It's just about figuring out how to get there.

Well - just TBH: We will see if we ever ship a proper v1.0, but thanks! 👍

@robertmuehsig , version is ElectronNET.CLI Version: <IP_ADDRESS>

You will need the newer version 0.0.9 for the new syntax. You need to reference the new CLI in your .csproj like this:

And run "dotnet restore" - this should update your CLI version to the most recent one.

@robertmuehsig , I've changed the CLI version but with no luck.
Unhandled Exception: System.AggregateException: One or more errors occurred. (The given key was not present in the dictionary.) ---> System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.ThrowHelper.ThrowKeyNotFoundException()
at System.Collections.Generic.Dictionary2.get_Item(TKey key)    at ElectronNET.CLI.Commands.BuildCommand.<ExecuteAsync>b__13_0()    at System.Threading.Tasks.Task1.InnerInvoke()
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
at ElectronNET.CLI.Program.Main(String[] args)

ElectronNET.CLI Version: <IP_ADDRESS>

I get the exact same error as ronosh-potiah-cko.
I am on osx and am running version <IP_ADDRESS>
steps to reproduce:
git clone https://github.com/ElectronNET/electron.net-musicplayer-sample
cd electron.net-musicplayer-sample/MyElectronMusicPlayer
dotnet add package Microsoft.AspNetCore.Mvc
dotnet add package ElectronNET.API
dotnet restore
dotnet electronize init

If I then do
dotnet electronize start

then the app starts and everything is awesome
however if I try to build
dotnet electronize build osx

Then I get the same lovley stack trace
Build Electron Application...

Unhandled Exception: System.AggregateException: One or more errors occurred. (The given key was not present in the dictionary.) ---> System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
   at System.ThrowHelper.ThrowKeyNotFoundException()
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at ElectronNET.CLI.Commands.BuildCommand.<ExecuteAsync>b__13_0()
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
   at ElectronNET.CLI.Program.Main(String[] args)

try this
dotnet electronize build /target win


Support AWS resource: aws_iam_group_policy

Description
Add AWS support for aws_iam_group_policy  (TF)

This issue has been referenced in the v0.27.0 release.


Button "Add Folder" missing in Firefox for "batch_uploads" page

When attempting to create a batch upload, the "Add Folder" button does not get rendered in Firefox v59.0.2, however it does get rendered in Chromium & Chrome v65.0.3325.181 under the Fedora operating system.
Source for Firefox (@xpath //*[@id="fileupload"]/div[2]/div[1]):

    <input type="file" name="files[]" id="inputfiles" class="inputfile" multiple=""/>
    Add files
    <input type="file" name="files[]" id="inputfolder" class="inputfile" multiple="" directory="" webkitdirectory=""\>
    Add folder

Source for Chromium (@xpath /html/body/div[1]/div/form/div/div[1]/div/div[1]/div/div/div[2]/div[1]):

    <input name="files[]" id="inputfiles" class="inputfile" multiple="" type="file"/>
    Add files

I believe this is a known bug with the jQuery uploader plugin. We should investigate and decide how to report results to users for future reference.

https://github.com/silverstripe/silverstripe-framework/issues/5417

Add some a help message on the upload page that states Folder Upload is available when using Chrome (if you are not in chrome)


module name does not match file path by any convention

expected: guard/jekyll_plus{.rb,/**{ and module Guard::JekyllPlus
actual: guard/jekyll-plus{.rb,/**} and module Guard::Jekyllplus
acceptable alternative: guard/jekyllplus{.rb,/**} and module Guard::Jekyllplus
Problem: mostly with the template (guard init), although both Guard and plugins should adopt a single convention (and deprecate everything else).
Reference: http://guides.rubygems.org/name-your-gem/
It's up to you to decide whether you want to change the module name or the file names - if you make the changes and commit to master, I'll make sure they work in Guard.

Thanks for your help with this. If I rename the module, doesn't that also mean I'd have to rename the gem? Last time I remember trying to get Guard to find the files, I remember it being troublesome to get the Gem and Guard to both to read the correct folder.

Thanks for your help with this.

No prob - Guard doesn't give a good error message when this fails, so it's about time I cleaned up this confusion.

If I rename the module, doesn't that also mean I'd have to rename the gem?

Well, ideally yes e.g. guard-jekyll_plus or guard-jekyllplus) - but that's only to match the Rubygems convention.
Guard doesn't care about the gem name (AFAIK), because that's the Gemfile's responsibility, not Guard's.
The current gem name suggests the module Guard::Jekyll::Plus exists - so it's up to you if you want to fix that or not. (There's RuboCop which uses 'rubocop' instead of 'rubo_cop').
I currently just want to get requiring the plugin and template generating to work in a single "recommended" way (and document it).
So I basically care just about the file names matching the module name (at this point at least).

Last time I remember trying to get Guard to find the files, I remember it being troublesome to get the Gem and Guard to both to read the correct folder.

Yeah - I can see why, and I saw that you made changes in the past. I want to clean this up, because the mess was cause by Guard::LiveReload ( which uses 'livereload.rb') and Guard::JekyllPlus took the hit ...
I'm also not sure about the guard name, e.g.:

guard :jekyll-plus won't work (subtraction)
guard 'jekyll-plus' should be fine
guard ':jekyll_plus' could work too
guard ':jekyllplus' would be ok (if you use Jekyllplus)

Anyway, I just want to give you a heads up - I don't want to cause any disruption, and if you get the modulename and files matching Rubygems convention, let me know and I'll make sure it works (and let you know for a release).
If you have any suggestions, let me know. (Overall it's "cleaner" for guard to remove dashes and underscores inside filenames instead of adding them - so even JekylPlus with 'jekyllplus.rb' is fine with me).

This is related: https://github.com/guard/guard/issues/721
In a nutshell, you should:

decide on a "human friendly" project name ("Jekyll Plus" or "JekyllPlus" or "Jekyll::Plus" or whatever)
decide on a module name (Jekyllplus or JekyllPlus or Jekyll::Plus) which fits best
fix the paths to match the RubyGems convention for the module name
optionally change the gem name (I don't care - because people specify it through bundler)

It's your project, so you have to decide on 1 and you have to pick something "reasonable" for 2.
(I can't help you until you decide on those)

Thanks for all the explanation! I'll work on fixing this up tomorrow.

:+1:


Coq namespace should be optional in README.md template

Currently, omitting namespace in meta.yml results in a nonsensical generated README.md which lists a line with an empty Coq namespace. We should make namespace optional, so the README.md template can be used in non-Coq projects, like proviola.

Another option, I guess, would be to introduce a project type selector and not consider namespace for non-Coq projects. WDYT? Would it complicate things too much?

Given that this was the only "non-optional" field for the README.md, having this kind of configurability seems a bit premature. I'm happy to revisit the decision further on when we have more non-Coq projects using the templates, though.

Makes sense, thank you.


updated adapter name in component_info.json

Signed-off-by: asubedy<EMAIL_ADDRESS>Description
Updated adapter name in component_info.json for uniformity in the naming of components.
This PR fixes #
Notes for Reviewers
Signed commits

[X] Yes, I signed my commits.

@asubedy making your rounds.... good!


Fix utils.js and allow setting initial country from back-end

Utils.js reference, was printing as ./utils.js into the template via Requirements::javascriptTemplate meaning the browser was searching in the site root. Have updated this to use the ModuleResourceLoader to print the valid URL.
Some devs will already be using a geolocation service to obtain a user's country on the back-end, or already have it saved into a member's record, etc. I've made a small update to the field that allows devs to set the initial country on init of an instance of the field, and then passing this through to the JS. When it is present (i.e. initialCountry not 'auto' or undefined) the front-end geo call is skipped.

Sorry @xini , don't merge this immediately. The uglify compression is buggering up the intl-phone-number-field.js. Will have a fix.

The above keeps the uglify, but removes the compression. I wasn't able to determine the compress option value to switch this afternoon. I'm not sure you'll want the lack of compression... but this does resolve the bug mentioned originally and add the initialCountry back-end setting. I'll dig for the correct gulp/uglify/compress option to toggle at next chance.

Hi Luke, can you please try with
uglify({mangle: false, compress: { dead_code: false }})

see https://github.com/mishoo/UglifyJS2#compress-options
Thanks.


update examples to cuda native architecture

Description

updated examples to cuda-native version
structured examples for a nice overview
added some more simple flow examples
moved BC definitions into lt.Flow to handle only flow._mask in main
made reporters use simulation in call
made observables use simulation and optional observable_parameters in call -> no information required in init

closes #209
closes #201
closes #199
closes #198
closes #184
closes #162
closes #135
TODO

[x] Fix AntiBounceBackOutlet (add collision to flow so that AntiBounceBackOutlet can use it to stabilize)
[x] fix EquilibriumOutletP (einsum issue #111 )
[x] decide on stable outlet boundary for lt.Obstacle
[x] adapt tests to define boundary in flow
[x] include boundaries property in all flows
[x] adapt all lt.Reporter subclasses to use simulation instead of flow
[x] adapt all lt.Observable subclasses to use simulation instead of f, and only in call, not in init
[x] check all tests still run well

[x] test_equilibrium_boundary_pu_algorithm throws assertion error

Checklist

[x] This pull request is associated to an issue
[x] This PR contains a description
[x] Add someone else as reviewer and wait for approval before merging.

Hello @PhiSpel! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file lettuce/ext/_collision/trt_collision.py:

Line 9:80: E501 line too long (83 > 79 characters)

In the file lettuce/ext/_equilibrium/quadratic_equilibrium_less_memory.py:

Line 10:80: E501 line too long (138 > 79 characters)

In the file lettuce/ext/_flows/decayingturbulence.py:

Line 32:80: E501 line too long (115 > 79 characters)
Line 38:80: E501 line too long (87 > 79 characters)
Line 65:80: E501 line too long (86 > 79 characters)
Line 81:80: E501 line too long (101 > 79 characters)
Line 83:80: E501 line too long (101 > 79 characters)
Line 92:80: E501 line too long (98 > 79 characters)
Line 110:80: E501 line too long (94 > 79 characters)
Line 123:80: E501 line too long (113 > 79 characters)

In the file lettuce/ext/_flows/obstacle.py:

Line 20:80: E501 line too long (91 > 79 characters)
Line 110:80: E501 line too long (82 > 79 characters)

In the file lettuce/ext/_reporter/observable_reporter.py:

Line 35:80: E501 line too long (112 > 79 characters)
Line 88:80: E501 line too long (121 > 79 characters)
Line 118:13: E124 closing bracket does not match visual indentation
Line 178:80: E501 line too long (90 > 79 characters)

In the file lettuce/ext/_reporter/vtk_reporter.py:

Line 37:80: E501 line too long (107 > 79 characters)
Line 39:80: E501 line too long (86 > 79 characters)
Line 41:80: E501 line too long (101 > 79 characters)

In the file lettuce/util/moments.py:

Line 73:80: E501 line too long (82 > 79 characters)
Line 76:80: E501 line too long (93 > 79 characters)
Line 77:80: E501 line too long (95 > 79 characters)
Line 155:80: E501 line too long (96 > 79 characters)
Line 213:80: E501 line too long (96 > 79 characters)

In the file old_tests/conftest.py:

Line 51:80: E501 line too long (100 > 79 characters)
Line 69:80: E501 line too long (100 > 79 characters)

In the file tests/boundary/test_equilibrium_outlet_p.py:

Line 8:80: E501 line too long (118 > 79 characters)
Line 9:80: E501 line too long (98 > 79 characters)
Line 26:80: E501 line too long (82 > 79 characters)

In the file tests/boundary/test_equilibrium_pu.py:

Line 36:80: E501 line too long (109 > 79 characters)
Line 37:80: E501 line too long (98 > 79 characters)

Convergence issue is most likely due to

[ ] ErrorReporter,
[ ] BGKCollision, or
[ ] TGVFlow.

Will check this when I get back to it.

@McBs, have fun! :)

edit: making TorchStencil private appears to be not so simple, so I reveretd it and will deal with it separately


0.8.1 doesn't work

Really excited to try the new fixits feature, but having some difficulty with the new version of the action: build log & PR

Thanks for the bug report! It looks like --export-fixes doesn't create a file if there are no suggestions. When testing, it seems I hadn't considered the case when there's nothing to report.
Should be a pretty easy fix

@vadi2 Does #28 work for you?
I really need to work out how to get CI working for this!

The action worked well - https://github.com/Mudlet/Mudlet/runs/5124404130?check_suite_focus=true
clang-tidy isn't picking up a couple of fixits that it should be - digging into that, but that is a separate problem. Thanks for the quick fix!

Thanks! 0.8.1 now released


Improve visibility of build failures on Windows

What
We'd like a better way to detect that our build fails for Windows. Currently the Windows actions are only set up to be run manually due to the slowness in restoring caches. This means we only see them failing if we go and look (like recently with #3584).
There are other routes we could take to get more visibility:

~Run the workflow on a schedule, rather than manually, to get more frequent feedback~
Run the workflow on each PR, like our regular workflows for even more frequent feedback:
a. As is, accepting that they'll be a bit slower
b. Turning off caching on Windows (hypothesising that npm install will be quicker)
c. Limiting the installation to the workspaces that are necessary
d. Using a different way of caching (for example, uploading/downloading artifacts)

We may also want to consider whether to run macOS workflows if we start running thing more automatically.
Update: Removed scheduled approach as we've decided against it
Why
Some contributors may be working on Windows and this would give us more certainty that our build would work for them.
Who needs to work on this
Developers
Who needs to review this
Developers
Done when

[x] We've investigated the cost (engineering, maintainance...) and benefits of the different options
[x] We've decided on which way to go
[x] We've implemented the chosen option

GitHub Actions "Tests" workflow now includes Windows in:

https://github.com/alphagov/govuk-frontend/pull/3955


New release?

Looking on https://github.com/richgel999/miniz/compare/2.2.0...master I think that it would be good to make the new release.
Any chance to to do that soon? 🤔

I also think that a new release would be great. For example, in the changelog for version 3.0.0, the improvement "Use wfopen on windows" would be very important in order to properly support Unicode paths on Windows. Of course, alternatively, this trick that sets the locale in my application to UTF-8 also works on Windows 10 1903/19H1 or newer and on Windows Server 2022 and newer, but not on older versions.
Of course it would be possible to simply use the latest commit from the master branch, but I would prefer using a version marked as "stable".
Thank you for making this great library! 😃

Done.

Thank you 👍

Perfect, thanks! 😄


Retire LRU dependency

The LRU dependency API surface has changed signficnatly between v6 and v7, is it worth migrating to a new version or should we try to implement similar behavior ourselves?
https://github.com/googleapis/google-auth-library-nodejs/pull/1359

Opted to roll our own LRU cache:

https://github.com/googleapis/google-auth-library-nodejs/pull/1659


All files & folders collapsed in Explorer view on start-up

Issue Type: Bug
Whenever I restart VS Code, all files and folders are collapsed in the Explorer view.

I think this started happening in the latest release.
I seem to remember something like this happening in the past.

VS Code version: Code 1.68.1 (30d9c6cd9483b2cc586687151bcbcd635f373630, 2022-06-14T12:48:58.283Z)
OS version: Windows_NT x64 10.0.22000
Restricted Mode: No
Remote OS version: Linux x64 <IP_ADDRESS>-microsoft-standard-WSL2

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz (6 x 2904)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
31.92GB (17.87GB free)

Process Argv
--folder-uri vscode-remote://wsl%2Bdebian/home/glen/development-environment/projects/ApiNext --crash-reporter-id 0da054fe-3726-474a-bc0d-7fe4a5e5fb13

Screen Reader
no

VM
0%

Item
Value

Remote
WSL: Debian

OS
Linux x64 <IP_ADDRESS>-microsoft-standard-WSL2

CPUs
Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz (6 x 2904)

Memory (System)
15.59GB (12.09GB free)

VM
0%

Extensions (31)

Extension
Author (truncated)
Version

auto-close-tag
for
0.5.14

eml
lei
0.4.0

dotenv
mik
1.0.1

remote-wsl
ms-
0.66.3

JavaScriptSnippets
xab
1.8.0

toggle-hidden
adr
1.0.2

vscode-intelephense-client
bme
1.8.2

vscode-svgviewer
css
2.0.0

vscode-eslint
dba
2.2.2

EditorConfig
Edi
0.16.4

vscode-npm-script
eg2
0.3.25

prettier-vscode
esb
9.5.0

vscode-highlight
fab
1.6.0

auto-close-tag
for
0.5.14

psalm-vscode-plugin
get
2.6.0

todo-tree
Gru
0.0.215

eml
lei
0.4.0

dotenv
mik
1.0.1

csharp
ms-
1.25.0

vscode-jest
Ort
4.6.0

vscode-commons
red
0.0.6

vscode-xml
red
0.20.0

vscode-yaml
red
1.8.0

vscode-sort-json
ric
1.20.0

trailing-spaces
sha
0.3.1

code-spell-checker
str
2.2.5

vscode-stylelint
sty
1.2.2

vscode-phpsab
val
0.0.15

gitblame
wad
8.2.3

change-case
wma
1.0.0

JavaScriptSnippets
xab
1.8.0

(2 theme extensions excluded)

No, I think it only happens with WSL folders, but it doesn't seem to affect a workspace in WSL.
I've tried with --disable-extensions and that doesn't seem to help.

No, I think it only happens with WSL folders, but it doesn't seem to affect a workspace in WSL.

So it only happens when you open a folder that is mounted in WSL? You aren't connected to the WSL instance via the remote WSL extension?

Is there some kind of UI cache that can be reset?

you can try code --user-data-dir some/folder  --extensions-dir some/folder  just to see if a fresh install of vs code with none of your user state could reproduce this

$ code --user-data-dir vsctmp --extensions-dir vsctmp projects/ApiNext/
Ignoring option 'user-data-dir': not supported for code.
Ignoring option 'extensions-dir': not supported for code.

Was able to reproduce this. Will investigate

@lramos15 Any update on this? It's really quite annoying.


Original rancher.password reintroduced after upgrade.

RancherOS Version: (ros os version)
v1.1.0
Where are you running RancherOS? (docker-machine, AWS, GCE, baremetal, etc.)
VMware ESXi 5.5, installed to disk after booting from iso.
Steps to reproduce:
Boot from rancher.iso (I was using v1.1.0)
Install to disk using the following command:
sudo ros install -f -d /dev/sda --append "rancher.password=original"

ssh to rancheros as user "rancher", set new password to "newpass" using command:
(edit password in vi)
sudo ros config syslinux
sudo reboot

ssh to rancheros as "rancher", password "newpass".
-success
Upgrade to v1.1.0, (happens to be the same version as running version)
sudo ros os upgrade -f -i rancher/os:v1.1.0

System reboots with new rancheros.
ssh to rancheros as "rancher", password "newpass".
-fails!
ssh to rancheros as "rancher", password "original".
-success! (??)
View global.cfg:
sudo system-docker run --rm -it -v /:/host alpine cat /host/boot/global.cfg

File has original content.
TL;DR
The original rancher.password is kept somewhere, and re-introduced when upgrading.

"rancher.password" is also reset to the original when upgrading from RancherOS v1.0.4 to v1.1.0 .
Since the "sudo ros config syslinux" command does not exist in v1.0.4 , you can instead edit the password using:
sudo system-docker run --rm -it -v /:/host alpine vi /host/boot/global.cfg

Yeah, rancher.password is a kernel parameter, It will always be effective.
Recommend you to use ssh key.
Close it.
If you still have doubts, please reopen it and let me know.

This is about the persistence of kernel parameters, not the effect of them. An upgrade effectively overwrites a reconfigured installation, not with defaults, but with parameters passed when originally installing to disk.
More details:
Parameters passed to the kernel is stored in host file /boot/global.cfg.
The parameter provided to the installation script is thus written to that file.
/boot/global.cfg is effectively overwritten when upgrading, with the content of the parameters passed on the commandline when originally installing.
I also tried adding "rancher.autologin=tty1" to /boot/global.cfg in a running system, a quite common secure parameter for management through console where a ssh key cannot be passed.
An upgrade removed the autologin configuration.
Issue still valid in v1.1.1 and even reproducible "upgrading" v1.1.1 -> v1.1.1
Please re-open (I cannot).

I encountered the same thing now. from 1.5.2 to 1.5.3
I've installed rancheros or maybe I've activated a password a long time ago because ssh keys was not practical in my network setup. Then a few upgrades later I've changed this password to something stronger by editing kernel parameters as described there: doc
and now after each upgrade I need to refresh the password. So where is this data stored to be restored at each upgrade?
there is not trace of it in/var/lib/rancher/conf/cloud-config.ymlnor /var/lib/rancher/conf/cloud-config.d/*.*


Fix Missing Template Warning

On every startup we get warned about missing templates
WARN 3143484 --- [           main] o.s.b.a.m.MustacheAutoConfiguration      : Cannot find template location: classpath:/templates/ (please add some templates, check your Mustache configuration, or set spring.mustache.check-template-location=false)

This appears only when running tests, as the jmustache dependency comes in via org.mock-server:mockserver-junit-jupiter.


Add git.TestLastCommitSha() and test

This PR adds a new function to the git package to retrieve
the last commit SHA in the current repository position.
It also adds a test for the new function.
/assign ~@Verolop~ ~@palnabarun~ @justaugustus
/cc @kubernetes-sigs/release-engineering
Signed-off-by: Adolfo García Veytia (Puerco<EMAIL_ADDRESS>

Dropping Nabarun and Veronica from reviewers as the OWNERS file is not up-to-date
/unassign @Verolop @palnabarun
Fix: https://github.com/kubernetes-sigs/release-sdk/pull/7

Hmmmmmm, GitHub approval doesn't add the lgtm...
/lgtm


readme - version in setup part

$ sudo pip3 install dataserv-client==1.1.0
is this the right version?
or should it be 1.3.0?

It depends what are you trying to do.
If you're installing 1.1.0, then that is the right version.

@beulemann it should be version 1.3.0

The version should not be specified in the readme (so it gets the latest). I have changed this and it will be fixed in the next release.


Thread problem is BACK!

QThread: Destroyed while thread is still running
make: *** [run] Segmentation fault: 11
As before.  Sigh.

I've totally rewritten the thread handling.  All threads just stop and the 'standard' PyQy5 'finished' signal is connected to.
Keypresses get the users response during Copy testing, as before.
In the Send tab, the thread that listens for and recognizes the morse is passed a Queue object which it places the recognized character into.  The parent thread waits for the 'finished' signal and then looks in the queue.
Works so far.  Still getting duplicate/excess chars in the upper line (issue #16).


[Service Bus] Throw error when entityPath in connection string does not match input to client methods

Resolves #10553
This PR throws error when entityPath in connection string does not match input to methods that create senders and receivers

cc @JoshLove-msft


Plugin non-functional (Firefox Dev editon 118.0b3)

Description
I have recently noticed (though I can't remember the specific version when this started) that my github pages are back to their vanilla view, so today I decided to go through the setting one by one again. Since there's no save button button, I switched to the Details tab and back to Options tab. All checkboxes were missing again, and no changes on github pages (even after refresh). That's when I noticed a couple of more issues:
Import and Export buttons do nothing
The Start process to identify feature... and the Clear cache buttons as well as pressing enter in the Find features search box open the Options tab in a new browser tab. Repeating these actions on said tab opens another one.
How to replicate the issue + URL
Go to Options and try to change any settings.
Extension version
23.8.24
Browser(s) used
Firefox Dev editon 118.0b3

If not even the options page works, I don’t think it's Refined GitHub's fault. Did you disable JavaScript? Anything in the console on GitHub.com?
Either way, it should be reported to Firefox instead.

The console shows  2 error (on this very page):
Error: An unexpected error occurred refined-github.js:2180:52
if (chrome.runtime.lastError) reject(new Error(chrome.runtime.lastError.message)); else resolve(result);

Error: Promised response from onMessage listener went out of scope ExtensionMessagingService.js:89:34
chrome.runtime.onMessage.addListener

Related bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1643186

Happy to report that it works for me. 😅 I wonder if reinstalling the extension fixes it for you

I wonder if reinstalling the extension fixes it for you

It did... I don't understand new Firefox


Supported primitive descriptors list is empty for node when using sample model

Hello,
I met a problem when I ran code blow using python api:
plugin = IEPlugin(device=DEVICE, plugin_dirs=PLUGIN_DIR)
if CPU_EXTENSION and 'CPU' in DEVICE:
    plugin.add_cpu_extension(CPU_EXTENSION)
net = IENetwork.from_ir(model=model_xml, weights=model_bin)
inputs = net.inputs
outputs = net.outputs
exec_net = plugin.load(network=net)

The error is:
Supported primitive descriptors list is empty for node: bottleneck1_1/dim_red/conv
The model is person-detection-retail-0013 which is one sample SSD model from installation package.
The problem comes from the last line exec_net = plugin.load(network=net) , but I have no idea how to solve it.
Thank you for your help.
Best,
dcgao

Hello!
Could you please provide information about what CPU did you use to run the model?

Hello!
Could you please provide information about what CPU did you use to run the model?

Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz

Hi,
I also ran into this error. I was writing a custom layer in c++ and it's solved by adding layer config code:
std::vector<DataConfigurator> inps;             for (const auto &in : layer->insData)                 inps.emplace_back(ConfLayout::PLN);             addConfig(layer, inps, {DataConfigurator(ConfLayout::PLN)});
at end of the of the ext_customlayer.cpp (this code is for multiple inputs but should work for single as well).
Not sure if this is exactly the same case but hope help.

@wiibrew saved me hours of debugging. Why this is not in the documentation, I'll never know.


Update architect-orb to 2.1.0

Update architect-orb to 2.1.0 which will use giantswarm.github.io as catalog base url.
Towards giantswarm/giantswarm#15898

Merging with ping @giantswarm/team-firecracker


PA105: Change meetup/thread FAB to stateless widget

FAB for creating meetup and thread has been changed from stateful to stateless

@nicole mind reviewing this?


Strategy loses the params on its way

Hi,
I had an issue with chaining the hooks, standard stuff (authenticate, restrictToOwner) and I realized that the params not arriving to the next hook from time to time.
The next line:
https://github.com/feathersjs/feathers-authentication-jwt/blob/master/src/verifier.js#L30
Shouldn't be like
this.service.get(id, req.params).then(function (entity) {

At least for me fixed the issue (after hours of debugging).
Thanks,
Paul

Looks like didn't worked as expected even for me :)
Instead this works:
    let {provider, ...params} = req.params;
    this.service.get(id, params).then(function (entity) {


Handle undefined correctly

Hi!
I suppose that undefined must be treated as falsy value. For now, exception is thrown when undefined is passed.

@mad-gooze I disagree. This function doesn't need to handle undefined. The first thing that the README says is

Convert strings to boolean.

Whatever calls this function needs to make sure it is giving a string.
For example:
toBoolean(v ?? '')

or
v !== undefined ? toBoolean(v) : false


Rename before_filter -> before_action

before_filter will be removed in Rails 5.1. Fixing this removes a large number of deprecation warnings from our logs.

+1


Resource doesn't support the specified HTTP verb

BlueFeather\EloquentFileMaker\Exceptions\FileMakerDataApiException
Resource doesn't support the specified HTTP verb
it's not working with laravel 8 and FM19. It's showing above given error

What call are you making which is throwing this error?

What call are you making which is throwing this error?

I am just going through the installation process documents as mentioned. Can you tell me if any other changes required out of the documentation

Yes, but there's a function or method you're using which is causing an exception. Can you describe what you're doing or show the line which is causing the exception? Please also post your full stack trace.

Just following up on this. Please post your stack trace so I can see which features and functions are being used, and what is triggering the error.

No response. Closing ticket.


very slow metric sources

🚀 Deployed on https://6705a3292c10bc63aa1a3641--cozy-fox-0defec.netlify.app


Fix the dropping packets in the receive thread (actually this time)

Closes #868
I was re-testing this morning and realized even with #869 I was still seeing
May 01 23:04:18.146 [WARN] monitor: Dropped 58542 packets in the last second, (58554 total dropped (pcap: 58554 + iface: 0))
So reverting the PR that decreased the timeout on pcap wasn't the fix (should have caught that yesterday, I was too quick to assume and didn't validate sufficiently).
It seems the PR right after (#858 ), where we added TCP options parsing to the synscan_process_packet was the real culprit. Upon reverting that, everything works.
I will open an Issue to re-add TCP options parsing, might be some small tweaks we can do to that PR to speed it up so the callback can run fast enough to not bog down the receive thread.


Clangd (Language Server) throws error for __integer_pack at pack.hpp

I've built the hpx from source (using master from Jun 2023) using a gcc 13.1.1 compiler. My Ide for development is sometimes clion and also nvim that both use clangd language server.
When going trough examples from the hpx I instantly get errors from the language server: Use  of undeclared identifier __integer_pack in pack.hpp:49. I know this is a placeholder for the gcc compiler but when running this with clangd it is pretty nerving sometimes...
Should pack.hpp use something in the direction of this:
#if __has_builtin(__make_integer_seq)
      template<typename, size_t... _Indices>
	using _IdxTuple = _Index_tuple<_Indices...>;

      // Clang defines __make_integer_seq for this purpose.
      using __type = __make_integer_seq<_IdxTuple, size_t, _Num>;
#else
      // For GCC and other compilers, use __integer_pack instead.
      using __type = _Index_tuple<__integer_pack(_Num)...>;
#endif

(this is basically taken from this)
In order to reproduce this just run:
clangd --check=main.cpp

Where main.cpp include
#include <hpx/hpx_main.hpp>
#include <hpx/iostream.hpp>

int main()
{
    // Say hello to the world!
    hpx::cout << "Hello World!\n" << std::flush;
    return 0;
}

One other option I tried was using clangd with --query-driver to query the gcc driver for the necessary system headers but this didn't fix the problem.
Is there any solution to make the language server work with the source code of hpx ... ?
I'm not sure if clangd language server is a high priority now ... but I thought I mention this. If needed I could try to make a pull request.

On further checking the cmake building process I discovered this:
  # Check the availability of certain C++ builtins
  hpx_check_for_builtin_integer_pack(DEFINITIONS HPX_HAVE_BUILTIN_INTEGER_PACK)

  hpx_check_for_builtin_make_integer_seq(
    DEFINITIONS HPX_HAVE_BUILTIN_MAKE_INTEGER_SEQ
  )

So basically if building the source with clang ... I can avoid the macro HPX_HAVE_BUILTIN_INTEGER_PACK ... and have HPX_HAVE_BUILTIN_MAKE_INTEGER_SEQ.
I still believe this is not something good ... because there are for sure many people that want to compile everything with gcc but still use the clangd language server ... (so basically use clion)

I'm not sure if anybody I know uses clangd for their work, so I wouldn't know whom to ask. This is probably caused by HPX being configured by one compiler (gcc) and being used with another one (clangd). The decision of what is supported is being made at configuration time, so that later on clangd sees things to be used that it doesn't support.
I'd very much appreciate it if you had the time and interest to come up with a possible fix (PR) for this.

I had reported that issue to jetbrains years ago.
https://youtrack.jetbrains.com/issue/CPP-29030/False-positive-systax-error-highlighting-for-hpx

Let's not close this issue. We've had similar reports in other contexts. I believe this can be fixed.

Yeah! I think you're right! As a feedback after using hpx there a lot of problems with the clangd lanaguge server, which is a real pity, because I think it is nowadays the most used one (it' s also open source). It would be nice if some efforts would be directed in this direction.


Can't edit NumberInput using keyboard

I can select the text, can move the cursor, and can add the numbers after the coma, but can't remove or edit the value further.
On the screenshot, for example, I entered a float number, by adding the dot and number after it. But then I can't remove it using the delete/backspace button.

where you doing this from a Mac?

Why did you close it?

you never replied back. Also I did make some changes in Main to allow entering the Decimal and - without the need for Text. I can reopen it if it is still an issue within the main branch.

Just tested it and now I can edit the number as described. But now it’s sometimes impossible to enter dot/comma. For example, if you run the example for the number input, try to enter three digit and then type dot/comma. Or sometimes it happens with a single digit. In overall, you can now edit a float after it entered, but it has issues entering it.
For your question about where I’m running it: it’s the latest macOS and the number input example.

yeah I am trying to solve this issue right now with the enter issue. It has to do with Text Versus the Value not wanting to accept each other and keep the .

that seems to be the one thing I can not figure out the best way to Fix ATM. the reason seems to be when the Value is converted to a String if its a 0.0 or a 1.0 it somehow becomes a 1 or 0 as it gets rid of the .0. Not sure how to Deal with this atm.


UPSTREAM: : collapse with extensions-apiserver udpates

What type of PR is this?
/kind bug

What this PR does / why we need it:
The OpenAPI models are used by the ServerSideApply feature.
The models can be nil when the feature is disabled or when the OpenAPIV3Schema is empty.
This PR changes the code to handle this case.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

/assign @stevekuznetsov @sttts


Hide error info tooltip while intellisense is active

I don't think that I have lot of control over it - it's behavior of both 2 different plugins used - autocomplete and linter. I just provide service for both their plugins and don't have direct control over it.

That's very sad to hear :( If it's completely impossible to fix, I don't mind if you close this issue.

Well, it's just JS, CSS and HTML under the hood so everything is possible. But I don't see any "stable" way of doing it right now, so I'll close it.
Maybe will come back to it in the future


[BESM4eExtras] v1.8.4 - Bugfix/Sheet Performance Enhancement

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

Changes / Description

v1.8.4

Reduced attribute cache ~35%-40% by removing all falsey assigned attributes and hardcoding default falsey values.  Such as when an attribute (Roll20) returns undefined then a default value of 0 will be assigned for an integer-based attribute.  Only attributes with non-falsey values will be written to cache.  The smaller cache size increased sheet performance.

Character Sheet Info Roll20 Internal Use only.

Thank you, Miguel!
John
From: Miguel Peres @.>
Sent: Tuesday, June 7, 2022 4:28 PM
To: Roll20/roll20-character-sheets @.>
Cc: John Davis (johndav2) @.>; Author @.>
Subject: Re: [Roll20/roll20-character-sheets] [BESM4eExtras] v1.8.4 - Bugfix/Sheet Performance Enhancement (PR #10656)
Merged #10656https://github.com/Roll20/roll20-character-sheets/pull/10656 into master.
—
Reply to this email directly, view it on GitHubhttps://github.com/Roll20/roll20-character-sheets/pull/10656#event-6765369615, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKRYTPLHKRTXWM3W42GCK53VN7LG5ANCNFSM5X4QSFZQ.
You are receiving this because you authored the thread.Message ID: @.***>


On more online compiler - Comeau

Comeau: http://www.comeaucomputing.com/tryitout/

Personally, I have a hard time seeing what benefit this one can offer over the other online compilers in the list - it looks more of a sales lead generation form than a tool to help developers. Moreover, the current compiler version was not updated since October 2008 according to Wikipedia. What makes this one "awesome"?


Add Chinese in ui-text.yml

Would it be welcomed to add a Chinese (simplified) version in ui-text.yml? I'd be interested in doing that.

This is definitely something that can be done, but the big barrier is going to be finding someone that can supply the correct translations.

In the pull request #2144, I finished the Chinese translation of ui-text.yml (both simplified and traditional). Hope it can help!


updated hash syntax

updated hash syntax to Ruby 1.9

I actually use the hash rockets on purpose. I sort of just like them better, /shrug, if anyone feels strongly about it to convince me otherwise, I'm all ears.

The most logical reason is that it makes the syntax uniform with JSON.

However I get that that is somewhat aesthetic so by all means let me know if you don't want it. I just know that is why it was introduced.

I think the main thing for me is that the 1.9 syntax is pretty much a sugar on top of the hash-rocket that is less versatile. I'm not entirely sure, but I'm pretty sure it only works for symbols. And it's just kinda weird IMO, because they don't look like symbols, they just looks like JSON.
So this wouldn't work, for example
{
   "value": 1
}

but this would
{
   "value" => 1
}

Normally, I just go with whatever the app I'm working in is using, because I prefer consistency over all. But, when I get to start a new app and make the choice for myself, I'll always go with hash-rockets because I feel like they are less limiting and more true to what's actually happening.

Fair enough. Should I close it?

If that's okay with you :), I can


PCA takes too long on large dataset

Need to optimize PCA speed. Same dataset takes 4-5 sec to align and PCA in R (either geomorph or Morpho).

fixed.


The submodules

git submodule add https://github.com/chaconinc/DbConnector
results
(nerfstudio) rover@rover-Precision-3571:~$ git submodule add https://github.com/chaconinc/DbConnector
fatal: not a git repository (or any of the parent directories): .git

Could you elaborate on your problem? This seems like a git error, and unrelated to a NerfBridge issue.

Apologies, for the slow reply. I am currently in the process of migrating to ROS2, but don't have everything finished yet.
I haven't actually used these, but I think your best bet would be one of these three options:

https://docs.openvins.com/
https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_visual_slam
https://github.com/open-shade/orbslam3

Please let me know if you have success with any of these. I will be looking into ISAAC ROS VSLAM sometime in September.

I have problems witth the dependency. I already have the images streaming. But I want to have the repo working

Which dependency? Also, to be clear, this repository does not work with ROS2.

I am having issues getting the node for the orb_slam2. When will you able to get the ros2 up

It won’t run effectively but I want to see if I use docker but I am new to docker and it’s taking too much time

Sorry, ROS can definitely be challenging. Unfortunately, I can't help you trouble shoot your SLAM implementation. I would encourage you to reach out to the maintainers of the SLAM package that you plan to use about issues with their packages.

My camera is realsense camera and I have been able to stream images. I can switch to ros1 and see if it will work. Did you use orb-slam2 or orb-slam3. Can you please tell me the actual orb-slam repo you ran.

The setup that I use is outlined in the README: https://github.com/javieryu/nerf_bridge#our-testing-setup .

If I switch to Ros 1 and use real sense camera d415 will it work

@eiyike123 Have you worked it out? I guess it will work because d415 may support ros1 (according to the legacy branch: https://github.com/IntelRealSense/realsense-ros/tree/ros1-legacy)

I've been using the https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_visual_slam package with the d455, and it's been working great. I haven't tried it with NerfBridge yet, but I hope to try it soon, so if you're looking for a ROS2 option then that package may work well.

I've been using the https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_visual_slam package with the d455, and it's been working great. I haven't tried it with NerfBridge yet, but I hope to try it soon. If you're looking for a ROS2 option then that package may work well.
I want to try it on ROS noetic can you please give the proocess on how to do that.

Sorry, I don't know if they support Noetic. Maybe OpenVINS would be a better option if you're using ROS1? I think they support realsense out of the box.

I dont have issues with the realsense camera it is has a camera node already. Your repository says i should have ROS Noetic.
Thank you

@eiyike123 so you have run this repo successfully with realsense camera and ROS neotic right?

Yes I have done that. I have orb_slam but it’s not showing me he topics

I am going to close this issue since it seems to have gone a bit off track.
@eiyike123 If you're still having trouble running NerfBridge please open a new issue with a clear description of your problem.
@elenacliu WRT functionality with RealSense, I have a working implementation of NerfBridge that works with the D455 and ROS2 Humble on the ros2 branch in this repo. I'm planning on merging this branch to main in a few days once I tackle a few other issues.


Revise the app crd doc

Revise the whole doc site and updated App CRD doc.

I left several TBD in the app crd doc which needs e2e sample instead of long narrative. /cc @wonderflow


Stand up FastFetch on MacOS

This PR ports FastFetch to .NET Core and in doing so, stands up our first .NET Core project on Windows.
The platform specific dependencies have been pulled out into GVFSPlatform and have been largely unmodified. Future cleanup to the native code dependencies in LibGit2Repo can be done as a separate work item.
I've attempted to make the commits individually removable as this review was getting large.

Splits out the platform specific native code into Windows and implements the counterpart in the Mac platform. Converts FastFetch to a .NET Core SDK style project and makes it build on MacOS.
Fixes a bug that I introduced when porting our codebase to .NET Core. In RestorePacakges.bat, we only restored two of our .NET Standard projects. This results in these projects being restored into the user's home folder/.nuget.  Since FastFetch was .NET Framework up until now, we never had issues with LibGit2Sharp not being present for Windows builds to consume. Once it was removed, we no longer had a place to consume the native .dll from. Now we properly restore that entire .sln and point it at the VFSForGit packages directory, not the default home folder location.
Remove build dependency in .NET Framework projects on FastFetch (which breaks the build)
Changes to make FastFetch 'dotnet publish'-able on Windows as part of our build script. Attempting to publish the entire .sln results in a lot of issues with the vcxproj and .NET Framework projects in our .sln so we'll settle for just FastFetch now. We can't run stylecop in the .NET Core environment and we need to ensure all dependencies of FastFetch are targeting the same RunTime.
Changes to make the functional tests run on Windows (and pass) and some cleanup.
Changes needed to make the functional tests less dependent on Windows specific idioms.
Changes needed to track the mode of a file that is being hydrated through DiffTree so that we can create files with the proper modes when FastFetch-ing.

There are two more functional tests that warrant further investigation on the Git/Windows behavior side before I make a change to fix them, but this is hopefully reviewable as is.
Things out of the scope of this PR that should be considered:

We have a self contained version of FastFetch now that we can have the build definition publish as an artifact.
FastFetch.dll/.exe is no longer signed by GVFS.SignFiles. Can we sign .NET Core executables in the same way we sign Framework? Can we retarget SignFiles to be Standard if so? (A Framework project can't take a dependency on a Core/Standard project)
Should we add a Mac only test to validate the symlink behavior in FastFetch?

Removing the WIP tag as this is ready for an initial review (more changes are needed for functional tests, but I hope they're relatively minor versus the changes here.)


fix: remove unnecessary build tags

closes #35
the filename suffix (_unix and _windows) already do this, no need to specify in build tags too afaik...

I don't think "unix" is a valid keyword here. Only specific OS names like "linux" or "windows" are supported.

oh, indeed, https://github.com/golang/go/issues/20322
in my head this was already implemented for some reason...
closing


Feature Request: trakt_watched_weekly filter by genre

Is your feature request related to a problem? Please describe.
It is currently a pain to use mdblist to do something that can be filtered with the trakt api.
Describe the solution you'd like
If we could add filtering by most watched in time period + genre, we would be able to more robustly define netflix-esque collections.
Describe alternatives you've considered
Using MDBList to get close.
Additional context
Discord Conversation: https://discord.com/channels/822460010649878528/822460010649878531/950110843482279987

Trakt Goals with links for later use

Add sort_by to trakt_list and trakt_watchlist
Add trakt_watched_personal and rename trakt_collection to trakt_collected_personal
Add all Filters to trakt_trending, trakt_popular, trakt_recommended_*, trakt_watched_*, trakt_collected_*


net: Introduce a maximum size for locators

Removes a DoS vector for nodes on long chain tip forks by setting a maximum amount of entries for locator messages.
Cherry-picked from: e254ff5
I had to rewrite the test from fa85c98 because we lack a lot of the test framework automation that got introduced between 0.14 and 0.17.
Fixes item 8 in #2744
Note to testers: It would be good to double check that libdohj does not send more than 100 locator entries per message, as the reason for setting the limit to 101 on Bitcoin Core was bitcoinj behavior spotted in the wild.

Works, need to test against libdohj still

will leave you to decide if you want to merge now or wait for libdohj tests (Wednesday?)

Let's wait and make sure.

Adding do-not-merge until we have some results against libdohj.


Demo Exercise #1

Attached is a zip file containing the texts of Shakespeare’s plays. All non-dialogue text has been removed from them. Also attached is a csv with the full title and genre of each play.
I would like to do an exercise in which we use word frequencies to measure textual similarity among these plays. There have been several prominent demonstrations recently in which unsupervised methods have “discovered” the genre of Shakespearean plays: comedies, histories, and tragedies each tend to cluster together on the basis of word frequencies. Ultimately, I would like to produce some kind of visualization of those clusters. (NOTE: In these demonstrations, the clusters are not perfect — which can be meaningful too.)
I’m not married to any particular measurement of similarity —  correlation, cosine, etc. — although it might be useful to calculate similarity a couple different ways to show how the findings differ. Similarly, I am open to different modes of visualization — dendrogram, multi-dimensional scaling, etc. Whatever methods are most compatible with the content of the main course should be fine.
Thank you very much for this. I look forward to seeing the notebook. If you have any questions, please send them my way.

No longer implementing this toy example.


Worker

related https://github.com/mozilla-tw/FirefoxLite/issues/4659

new revision will not stop the cp

Hi @wangchunyang
I'll merge this first for the UAT release this week.
Please give us a post-code-review after this PR is merged. Thank you!

Hi @wangchunyang
I'll merge this first for the UAT release this week.
Please give us a post-code-review after this PR is merged. Thank you!

Sure, go ahead please.


[SIN] Pre-process the iris dataset and implement different Machine Learning algorithms

Preprocess and perform EDA on the iris dataset.
Implement ML algorithms like
A few example solutions:

Logistic Regression

Random Forest Classifier

SVM Classifier

Decision Tree

K-Means

Gradient Boosting (XGBoost, CatBoost)

Neural networks

Other

@AjayKhalsa I would like to work on this issue.

@Trimankaur Go ahead feel free to make  PR when you're ready


Contribute Blockchain Projects

👋 Hello everyone,
Looking for content related to blockchain projects

Hey, I want to contribute to the Blockchain project as I am Developer Relation at a Web3 startup called Blotic. I will help in providing all the best resources to be a Blockchain Developer or web3 developer and currently, I have started doing the same. So it will be a pleasure to be part of it. Thank you!!
@AkashSingh3031

Hey, I want to contribute to the Blockchain project as I am Developer Relation at a Web3 startup called Blotic. I will help in providing all the best resources to be a Blockchain Developer or web3 developer and currently, I have started doing the same. So it will be a pleasure to be part of it. Thank you!!
@AkashSingh3031

You are welcome to contribute your work in this repo

I am new to open source. Can you please help me?

I am new to open source. Can you please help me?

Check this Contributing Document  for the contribution to your work in this repo


boards/Board.mk: Allow boards context to be extended just by providing a double colon target

Summary
This allows boards to extend the context target just by providing a context:: instead of conditionally relaying on a definition of a variable.
Impact
Testing

LGTM.


Fix ENV Set Method

Github changed the method of setting environment variables in an action.
https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

Similar to https://github.com/puppetlabs/action-litmus_parallel/pull/67 the question here is why the announced (and published) changes by github of the @actions/core API have not addressed this without any changes on our side necessary?

@DavidS Ok, it took me a little while, but I think I understand the question you're asking and I may know the issue. I think dependabot updated the packages.json file to reflect the new version of @actions/core, but dependabot doesn't know that you then also have to re-vendor all of the packages. When I look at the source code of the actions core library in this repo it doesn't reflect 1.26 and the new method of setting environment variables.
I'm going to update the package and re-push and see if the issue is fixed with no changes at all to our action code.

Ok. So I don't know what weird garbage jest was doing that broke everything, but this version here gets the spec tests running just by updating dependencies with no changes to the action code itself.

@DavidS @michaeltlombardi I have split this PR into 3 distinct commits not to help with review.


Upgrade All Packages to Latest Version

what

update _VERSION envs to point to the latest version of all apps

why

We have quite a few packages here that are pretty out of date

I am open to suggestions of how we can improve this process (automated).

https://github.com/cloudposse/packages/pull/22


feat: update user-id method

WIP...

I think you could reuse the modify user API rather than open a new one. For example, add a new field for the new user ID.

You have to rename feedbacks in the feedback table as well. All caches for this user will be invalid then.

hmm, I need to ask few more questions as we have some different use cases
which I am trying to implement, can I contact you through any other means
like email or something else?
thanks .
On Wed, 19 Jul 2023, 13:47 zhenghaoz, @.***> wrote:

You have to rename feedbacks in the feedback table as well. All caches for
this user will be invalid then.
—
Reply to this email directly, view it on GitHub
https://github.com/gorse-io/gorse/pull/736#issuecomment-1641637373, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AR2NVP2ROZY4WSX6QHKGIIDXQ6JYVANCNFSM6AAAAAA2PO6P3I
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

You can contact me in Discord. However, I am not always online. Just leave messages to me.