[Dicussion] An argument for upgrading to Java 8

Now, I know there's been a few issues and PRs requesting Java 7 support posted here already. Nearly all of them have been closed for various reasons, mostly related to Android and GWT compatibility. Regardless, I would like to discuss the possibility of upgrading source compatibility to Java 8 across the entire codebase.
Why?
Java 7 and 8 come with some language features that, in my opinion, could greatly improve the codebase:

Diamond operators could be used to reduce generic declaration redundancy
Default methods could be used in classes like ApplicationListener to automatically provide ApplicationAdapter functionality out of the box without creating a separate abstract class
Static interface methods could improve code organization
Listener utility interfaces could be created and used in Scene2D in conjunction with lambdas to provide much cleaner listener support, e.g. button.clicked(e -> System.out.println("Clicked!"))
Lambdas could be used instead of anonymous classes across the codebase, e.g. when posting Runnables to an application or using gdx.utils.Predicate in Arrays

But isn't Java 8 unsupported?
No, Java 8 language features are currently supported across all libGDX backends. This includes GWT, Android, Desktop and RoboVM.
What about minimum Android API levels? Will they need to be increased?
No. According to the Android documentation, default interfaces, static interface methods and lambdas work at any minimum API level, even across third party libraries.
But the new Java 7/8 API additions don't work on Android/GWT/RoboVM!
This is mostly true. java.util.stream, java.util.function and other subpackages and classes are not supported at the current libGDX minimum Android API level. However, they don't need to be. Many, many packages and classes from Java 6 are already unsupported in Android, and these new 7/8 API additions are no different. The solution is to not use any new API from Java 7 or 8. I am proposing this upgrade for the sake of the new language features, not new API.
What this means is that if you want your game to run on older phones, you don't use any new Java 7/8 API, just like you don't use java.lang.reflection.* on GWT or java.awt.geom.* on Android. This is not something that should be a problem. Most modern IDEs warn users when their code uses classes that are not compatible with their minimum API level.
Has Java 8 been tested on these backends to make sure it works?
Yes. If you're doubtful, I can personally attest to having a game that uses plenty of Java 8 lambdas and default methods, while running fine on older Android phones, iOS and HTML5.
Upgrading to Java 8 will break things!
No, it won't. The version of the Android plugin used in gdx-setup already supports desugaring Java 8 features, and the current version of GWT supports Java 8 as well. Java 8 has been out for more than 5 years now, and thus most developers should have upgraded to it already.

I don't think we would add diamond operators. We don't have redundancy because we just omit generic types on the RHS.
Of the rest that you listed, making it nicer to use lambdas for UI events is most interesting. The things that only affect the libgdx codebase (rather than using libgdx APIs) is not super exciting, since it's poking a bunch of code that works fine. libgdx is mostly in maintenance mode, so adding to that burden isn't great. Changes that improve libgdx API usage would be welcome though (within reason!).
FWIW, Spine (my software which relies on libgdx) will no longer be relying on Java 7 after early January 2019. If the rest of what you said about Java 8 support is true, I personally don't have any reasons not to do it. The only worry is if common APIs are unavailable (though I am not a big fan of the stream/function stuff anyway).

There is also the issue of overhead on most of these syntactic sugar APIs that extra synthetic accessors and methods that we really don't want to have in the core API. As well as being less performant in some cases for questionably nicer syntax.
We can upgrade our mins to java 8 in core repo, but as we wouldn't want to be using many of the nice features its pretty pointless.

libgdx is mostly in maintenance mode

You stated this twice, and it is sad to hear. libGDX is a great framework, but as time's are changing, there already is a lot of improvement potential on all backends. There are people willing to help.

It's no secret, just look at the activity and search trend. libgdx is not dead. It is still a great tool, even if it we aren't adding new features. It's a great framework and can do a lot. I use it every day working on Spine.
Personally, I'm not interested in Android apps. I might do one for fun from time to time, but I'm not going to debug Android quirks. I really don't like Apple/iOS and I'll never again work on junk that. GWT is really neat, but not super fun to work on. I'm happiest just maintaining scene2d, which is what I use the most. Other core team members have found other things to do, or they are still around, just not as much as back in the day.  We all do this for fun, after all.
There are some people who help, some a little, some a lot. The quality of their submissions vary wildly. They come and go. It's great having good issues and good PRs, and we merge PRs that are clear improvements. It doesn't make sense to merge big things and then be left doing the maintenance after the contributors have wandered off. This has happened a number of times (eg DecalBatch). libgdx is already a large project and doesn't necessarily need more stuff. One could argue that some of the "stuff" it has already crosses the boundaries of what makes sense to include. Many things make more sense as modules or separate projects that use libgdx for their foundation.
What the project really needs is maintenance help, not backend improvements. 73 PRs and 244 issues as of this writing is already way out of hand. We used to keep it to just a few, but we don't have the bandwidth anymore. If you want to help out, please consider monitoring issues and PRs.

NathanSweet: I don't think we would add diamond operators. We don't have redundancy because we just omit generic types on the RHS.

This doesn't seem to be the case. Running a check with Intellij came up with 80+ places in code with explicit types being used.

(Mind you, this is after some manual cleanup, so the actual number may be much higher. I realize that there isn't much of a need to fix this since all it does is waste a few characters of space, but I thought it was worth pointing out.)

Tom-Ski: As well as being less performant in some cases for questionably nicer syntax.

In which cases are default / lambdas / diamond operators less performant than Java 6 equivalents? Looking it up, I only find a stackoverflow post that claims lambdas are faster than anonymous classes, and a question talking about default interface performance without any conclusive results. Diamond operators don't seem to change performance either.

I suppose you're right about not touching code that's perfectly functional. However, I'm not necessarily proposing that old code be rewritten to be 'cleaner' with java 8 API. Even if old code is not changed, updating to Java 8 opens up the possibility of new contributions making use of the new language features.
(sorry for changing the topic; I just wanted to address some points that Nate and Tom-Ski made)

Likely most of those situations where <>  would be useful could also be changed to not use generics at all. Eg, in Array, I assume the 2 "warnings" are:
static public <T> Array<T> of (Class<T> arrayType) {
	return new Array<T>(arrayType);
}
static public <T> Array<T> of (boolean ordered, int capacity, Class<T> arrayType) {
	return new Array<T>(ordered, capacity, arrayType);
}

I would prefer changing both of these to new Array(, which is even fewer characters than <>. I really don't care about the "usage of a raw type" warning. I happily use raw types to have less typing and less code. I usually do this in my contributions, others may like having duplicate generics on the RHS (eg because they are terrible people).
As for performance, probably Tom-Ski was referring to the stream API stuff or similar, which may allocate (I don't personally use it, goddamn kids with all their fancy new features!).
Putting aside there are few new additions to libgdx, I don't feel it's super important to use Java 8 for new additions since avoiding it is very easy.

@NathanSweet Thanks for your friendly answer. However, I disagree on some points.
Is libGDX in maintainance mode because there is general lower interest in it, or is lower interest in it because it is in maintainance mode? They casuality may be exactly in the opposite direction as you suggest. If I were a new interested user, I would probably not decide to use libGDX for my game after taking a look at libGDX homepage, the recent release count and the forum threads.

we merge PRs that are clear improvements

Unfortunately, that is not true. There's PR #4265 still open for two years for a faster GWT bootstrap process. That's a clear imrpovement. Unfortunately, it cannot be merged any more and the committer is not active any more. If you say this is a more complicated PR - which is true - than take #4137 as an example of a clear improvement that was not merged for two years.
What about #3457? It is also a clear improvement because core libGDX scene2d lacks focusable support. But I doubt you will approve it, so please at least make a statement and reject it.

What the project really needs is maintenance help, not backend improvements. 73 PRs and 244 issues as of this writing is already way out of hand. We used to keep it to just a few, but we don't have the bandwidth anymore. If you want to help out, please consider monitoring issues and PRs.

I do that for the last 12 month, and it is neither help nor satisfying. I can comment on issues, that's all I can do. I can't merge PRs that I think are good, I can't deny ones that I think are not. I cannot discuss with others about the PRs to get things done: Where is the libGDX decision board to address if this issue - upgrading to Java 8 - is rejected or accepted? Same for #5482, I stated my opinion there and it is likely that this PR will never get merged nor rejected. So why should anyone invest a lot of time in testing some other, more complicated PRs or issues if the invested time leads to nothing? You need help from developers, and for the invested time developers don't want to just support the status quo, but want to have a voice and improve things.
Just to make it clear, I heavily respect the work you and others did here. But in my opinion the project deserves and needs more efforts than it gets the last 12 months. I will end the discussion on this issue now because Anuken is right, it is off topic here. But there was a need to say it.

libgdx usage has waned at about the same time the core developers' interest in spending a lot of time on it has waned. I seriously doubt there is a causal relationship.
Sometimes a PR simply gets overlooked. Sometimes a PR is too big or has too much impact on current API users. Sometimes a PR does fit with the other things that libgdx is doing, but could be implemented separately -- we aren't excited about taking on even more responsibilities. Sometimes the core developers interested in that part of libgdx don't have time -- I won't generally merge PRs in areas I don't use myself, as that makes me responsible for that to work correctly.
FWIW, that some PRs get neglected doesn't mean we don't merge PRs.
Focus for scene2d.ui is a reasonably complex problem that affects most widgets. That PR is incomplete, as a full solution would do focus traversal for all widgets in some nice way and include rendering focus indicators (both extensible for custom widgets). Even a PR doing that means a lot of changes. I'm not sure I would like to add so much complexity since part of scene2d.ui's charm is simplicity, especially when the need is not super large, IMHO. While it would be nice to have, Spine is probably the largest scene2d app and it gets by pretty OK without special focus support at all. Since I don't have a personal need for it and at least simple focus traversal can be done on top of scene2d.ui, I am not able to find the time for a project of that size. The PR can stay since it represents the feature and contains implementation ideas.
I'm more of loner than others, so I've never been charge of who gets promoted to be able to merge PRs, etc. Probably if you jump on IRC you could fight for such a promotion so you can do more.
You're not wrong that the core developers are less active and less interested in spending their time on libgdx, and of course that makes the library suffer. We each have our own reasons for the reduced interest. We could hand the keys over to the next generation, but while our interest may be less, it isn't zero. We have apps that rely on it and we don't want to see our baby made a mess of, taken in unwanted directions, become unstable, etc.

I think it is time for a fork
libGDX want to remain compatible with old Android so exit new Java features that exists, and that will exist tomorow (amber/valhalla/metropolis)

I learned how to program Android games with libgdx a long time ago. I haven't published any games but I learned a lot and it's a very good framework and in java.
It's a pity that it's only in maintenance, because it will end up dying in that case.
In this world, software that doesn't evolve ends up being surpassed by others.
Java 8 would be a good leap forward and adding some tools to the ones that already exist (hiero, fbx-conv ...) would also be good.
I don't know if kotlin will end up replacing java (in Android at least) or is a Google strategy to pressure Oracle, for my part I prefer to continue java but who knows.

In this world, software that doesn't evolve ends up being surpassed by others.

Perhaps. I have not thought of this as an actual problem though because who makes fun features for games, I do not libgdx.
Keeping up on software versions is important though. However Java 9-11 are not better solution for most. As it stand a lot of stalled libraries use Unsafe Direct Buffer reading which was removed in 10 or 11. Using direct buffer is not the same read speed, networking and disk IO primarily are jacked.
There are pros to future java beyond 13 if they add the actual awaited for features for generics and specialization.

Late to the party!
This is a library, so for compatibility's sake, let's keep it at a low Java source version. Some stuff might not work (Android doesn't fully support Java 8). Upgrading to Java 8 might also be less performing as others pointed out. Personally I think, Java 6 is easier to read than someone's Lambda code block but I am just getting old.
Now, keeping libGDX at Java 6 doesn't really stop anyone from using Java 13 or whatever their choice is. Changing the codebase to Java 8/13/etc. compatibility doesn't make it either (a) faster nor (b) does it change any of the public methods you can call. It's going to look the same and perform the same.

Well, it's 2021 now. Many project membership additions happened last year, and I wouldn't consider libGDX to be in the same maintenance mode it had back in 2018. I believe libGDX uses Java 7 internally now, possibly because major build tools (Maven and to some extent Gradle) aren't supporting Java 6 any more. I'm not sure if I could download a Java 7 JDK today and have it even build libGDX, because of the handful of vendors who still offer JDK 7, I don't even know if they've patched those JDKs to support Maven Central's requirements for security on downloads. Java 8, though, remains in wide use; see last year's JetBrains developer survey that showed 75% of surveyed Java developers used Java 8, compared to 7% still using Java 7 and 3% still using Java 6. Android continues to improve Java 8 support and bring it back to older OS versions; see the Android documentation for this. RoboVM, last I heard, was working on updating to the newest Android core, but it isn't fully ready yet, to my knowledge. RoboVM has supported Java 8 language level features for a long time via RetroLambda or other tooling. GWT has released version 2.9.0, though libGDX doesn't currently use it; this GWT version allows language level 11 features, and has the same JDK 8 API support as 2.8.2 (language level 8 is already supported by 2.8.2).
@noblemaster :

Upgrading to Java 8 might also be less performing as others pointed out.
Are you referring to https://github.com/libgdx/libgdx/issues/5487#issuecomment-449524222 , which noted the exact opposite? Unless you have a benchmark, "might also be less performing" is meaningless and only spreads FUD.
Changing the codebase to Java 8/13/etc. compatibility doesn't make it either (a) faster nor (b) does it change any of the public methods you can call.
It absolutely allows libGDX more power in how it can be structured. I don't know if you've used default methods in interfaces, but they are great for writing code in one place, DRY, and having it apply to all implementations. Callbacks in UI code can use lambdas, and lambdas with the same type signature are interchangeable thanks to the FunctionalInterface annotation. Java was late at adding lambdas in 2014; C# has had something similar or better for a while, and even C++ code is using first-class functions these days. I wouldn't recommend the Stream APIs for libGDX because I don't know how much they allocate, but they aren't required to make use of language level 8 features.

I would rather not be stuck in 2011, with Java 7, or 2006, with Java 6, for the rest of libGDX's lifespan. In any case, our tooling will be making this decision with or without us involved, and at some point Java 6/7 support will be fully removed from Maven and Gradle. Gradle itself requires Java 8 or higher to run, though at this point it can still compile Java 6 applications (but not Java 5). At that point we could seek shelter in an older Gradle version, which inevitably wouldn't support a freshly-downloaded newest-version JDK, and watch as the world continues to move ahead without us. That is when I would consider libGDX a dead project.
I would rather not hasten this project towards its grave. I think that whenever RoboVM has a release that supports language level 8 and preferably some APIs from that version, we should update to Java 8 for libGDX itself, probably restricting usage to language level 8 and not APIs drawn wildly from that version. Users can continue to use libGDX 1.9.13 or earlier for existing projects or new ones that need to support very old devices. 1.9.13 works pretty much as well as you could ask for, especially if seeking a stable island amidst API changes. To mark a backwards-incompatible change, this could be delayed until libGDX 2.0.0, or could be previewed like the 0.99.x releases before libGDX 1.0.0 . I don't think there's much need to update to Java 11 or newer in libGDX; there's some conveniences like var and Collections builders, but not much else. Java 9 is considered by Oracle and the OpenJDK teams to be the last major release in Java for the foreseeable future (major meaning breaking backwards compatibility), and since Java 8 added lots of features where Java 9 didn't, there shouldn't be any serious need to update past Java 8. The exception would be if something really big and relevant to games is released (like Project Valhalla, for value types), and becomes widely available across all of libGDX's target platforms.
This issue/discussion is still open 2 years later, and things in the ecosystem have changed and continue to change. I sincerely hope libGDX will be able to change with that ecosystem.

I agree, as soon as MobiVM supports Java 8, we no longer have any justifiable argument against Java 8 in libgdx.

We should probably also thing about the user of libGDX. By users I mean other developers that use libGDX. They can use Java 8, 11, or whatever they like. It's no a problem at all.
I don't think there is a problem going to Java 8 for mobile (Android & iOS). However, it's another story on desktop. Not too long ago, I was using a Debian distribution for my servers that didn't provide a Java 8+ JVM. Switching to Java 8, would mean I would probably be forced to update all my Debian distributions and hope everything will go fine with the databases etc. Although I am on newer servers now with Java 8, I can see it cause problems for others.
Not too long ago I used Java 7 for my Java client distributions that auto-update via getdown. Although the latest binaries are using Java 8 too, some players probably still use the old client with Java 7. If things are suddenly switched to Java 8, their game installs would stop working and I would have to deal with a incoming stream of user inquiries.
No developer that uses libGDX is limited by libGDX using Java 7. However, forcing Java 8 on everyone might cause some headaches for some. Are we doing to rewrite libGDX with lambdas just for the sake of it? I think the needs of the many is greater than the needs of the few.

The only still supported debian build that doesn't include openjdk8 is jessie, which is Extended Long Term Support and only offered as a commercial option. I would be amazed if anyone was running such an old release as a daily driver laptop. And even if they were, they could simply grab a java 8 openjdk jre.
If libgdx developers don't want to force users on very fringe cases to upgrade, they an always opt to not update libgdx to the latest version.

Are we doing to rewrite libGDX with lambdas just for the sake of it?

I really do think there are many benefits of using Java 8 over 7, and tommyettinger mentioned most of the big ones. Pretty soon it will become actually difficult to get libgdx to build due java 7 compilation no longer being supported on older java. Functional interfaces are very nice, and would add a lot of quality of life changes to APIs. Default interfaces will help clean up the projects load of duplicated code between backends.

All I am saying, we should probably ask the developers that use libGDX if there are any concerns. We are forcing an update that might cause problems for some.

It's about time. Reasons have been mentioned so this is just a +1 for moving on.

How about we make a news announcement with the pros & cons on libgdx.com? We should make sure to post it on Twitter too to get some feedback? I am mostly against it, but if there are no major concerns, I'll give in too. Here are my points:
AGAINST Java 8:

Porting, as in cross-compiling to Switch, XBox & PlayStation is potentially hard if we have Lambda & default interfaces in the code. In addition, using Java 8 features such as the stream APIs might be harder to port also. But maybe it will never come to it anyways.
Compatibiliy: people that only have Java 7 available (e.g. on a server or client) will not be able to use it.

PRO Java 8:

Duplicate Code: in addition to what's already used, we have default interfaces/Lambda in Java 8.
Building Java 7: it might not be possible to build a project for Java 7 with never JVMs. Do we have a date?

The only still supported debian build that doesn't include openjdk8 is jessie, which is Extended Long Term Support and only offered as a commercial option. I would be amazed if anyone was running such an old release as a daily driver laptop. And even if they were, they could simply grab a java 8 openjdk jre.

Maybe in a perfect world. When I tried OpenJDK 8 on my old Debian server, it tended to crash after 1h running or so. It was some sort of file access problem that ended in a crashes JVM (the bad kind). The Oracle JDK 8 worked, but I didn't want to go forward due to potential licensing issues.

I just want to point out, java 8 is almost 7 years old. To my knowledge, there is no maintained openjdk-7 distribution that includes security patches.
As for linux distributions, all of the main distributions currently offering free security updates have support for java 8 out of the box.

Ubuntu 16.04
Debian Stretch
CentOS 6

If you're running a system older than these, you likely have bigger problems than a missing libgdx update. We only compile linux natives on 16.04, previous releases will likely have linking issues.

How about we make a news announcement with the pros & cons on libgdx.com? We should make sure to post it on Twitter too to get some feedback? I am mostly against it, but if there are no major concerns, I'll give in too. Here are my points:

I've posted to Discord, which is one of the larger communities. I don't know who runs the libGDX Twitter.

AGAINST Java 8:

Porting, as in cross-compiling to Switch, XBox & PlayStation is potentially hard if we have Lambda & default interfaces in the code. In addition, using Java 8 features such as the stream APIs might be harder to port also. But maybe it will never come to it anyways.

No one has even come close to making libGDX, as Java, run on those consoles. Do you know if they even have a JRE available for their architectures? When Slay the Spire was ported to consoles, it involved a source rewrite to C# and MonoGame, which, naturally, supports what are effectively the same as lambdas. Default interfaces could probably be filled in by one of several C# features, like extension methods. But, whoever it is who has the Java-to-C# translator has not made it open source and we are in no way obligated to work around its hypothetical defects.

Compatibiliy: people that only have Java 7 available (e.g. on a server or client) will not be able to use it.

People that only own a toaster running Bell Labs UNIX can't use it either. Most game distribution packages a JRE these days, and having Java 7 available to for the whole system to use is a huge security flaw because Java 7 isn't getting security updates and has numerous known vulnerabilities.

PRO Java 8:

Duplicate Code: in addition to what's already used, we have default interfaces/Lambda in Java 8.

I think we probably wouldn't see much benefit from the Stream API, and language level 8 is better supported than JDK 8 APIs anyway. We could consolidate some of the DIY functional features in libGDX's utils package, too.

Building Java 7: it might not be possible to build a project for Java 7 with never JVMs. Do we have a date?

Nope, Gradle has tended not to announce this type of thing far ahead of time. Especially with that JetBrains survey showing only 7% of Java developers even use Java 7 (not even as a primary version, at all), I doubt supporting 7 is a major priority.

The only still supported debian build that doesn't include openjdk8 is jessie, which is Extended Long Term Support and only offered as a commercial option. I would be amazed if anyone was running such an old release as a daily driver laptop. And even if they were, they could simply grab a java 8 openjdk jre.

Maybe in a perfect world. When I tried OpenJDK 8 on my old Debian server, it tended to crash after 1h running or so. It was some sort of file access problem that ended in a crashes JVM (the bad kind). The Oracle JDK 8 worked, but I didn't want to go forward due to potential licensing issues.

This is the type of thing you probably shouldn't announce to the world... It sounds like this isn't some especially important server though, holding payment info or something. I hope that it's just a testing server kind of thing. I think Java 7 for Linux also didn't have much support for applets, which are the main vulnerable entry point in that version. The reason for a crash could just be that your old server is... old. Doesn't necessarily mean OpenJDK 8 is broken. What type of Java is your 7, a pre-license-change Oracle 7?

No one has even come close to making libGDX, as Java, run on those consoles.

Orangepascal has managed to automate it for Switch. I believe he cross-compiles to C# first then to Mono Game but I don't have the details. I think he had to made some code-changes to make the automation possible. Once it's cross-compiled to C#/Mono Game, XBox and PlayStation are in the reach of possibilities.

This is the type of thing you probably shouldn't announce to the world.

Not everyone has the time, or choice, or means to upgrade to the latest version that's out every time. Servers aren't free either, neither is switching or upgrading. And just because it's not the latest version doesn't mean it's not secure.
 At least, let's have a honest discussion. We aren't talking about Applets. A JDK bundled locally with a client is not a vulnerability entry point. Nor is an older JVM that's not exposed.

No one has even come close to making libGDX, as Java, run on those consoles.

Orangepascal has managed to automate it for Switch. I believe he cross-compiles to C# first then to Mono Game but I don't have the details. I think he had to made some code-changes to make the automation possible. Once it's cross-compiled to C#/Mono Game, XBox and PlayStation are in the reach of possibilities.

Yeah, that's precisely what I said. No one has made libGDX, as Java, run on those consoles. If the cross-compiler were part of the libGDX project, then we could make changes with it in mind, but it is not.

This is the type of thing you probably shouldn't announce to the world.

Not everyone has the time, or choice, or means to upgrade to the latest version that's out every time. Servers aren't free either, neither is switching or upgrading. And just because it's not the latest version doesn't mean it's not secure.

https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19116/version_id-121887/Oracle-JDK-1.7.0.html , if you want to spend the time going through which of those 213 might be a problem. If you choose to use a version that no longer receives security updates, that is a risk you are taking. Risks aren't free either; there are whole industries built around assessing the cost of risks. I say you shouldn't announce that your server is running an un-update-able version of Java just because it invites unwanted attention from bad actors on the Internet, though you can choose to live with those risks, and if your server isn't connected to the Internet then there's no concern.

 At least, let's have a honest discussion. We aren't talking about Applets or a toaster running Bell Labs UNIX. A JDK bundled locally with a client is not a vulnerability entry point. Nor is an older JVM that's not exposed.

If you're on board with bundling a JVM locally with a client, great! We can all use Java 8 then, as soon as RoboVM supports it. I think Steam requires a JVM to be bundled with an app for you to sell it on their platform, but I'm not sure -- this may be a restriction only for MacOS, which definitely doesn't allow a system JVM to be used by Mac Store purchases. I agree with PokeMMO that if distributing a JVM with a game, there are no desktop operating systems (especially ones that can play graphical games) currently in wide use that can use Java 7 but not Java 8.

If the cross-compiler were part of the libGDX project, then we could make changes with it in mind, but it is not.

They were. https://www.badlogicgames.com/wordpress/?p=2450

I say you shouldn't announce that your server is running an un-update-able version of Java

If you read my post, you would be aware that I am not using Java 7 anymore.

Apart from the much newer jdks, the core library version does not restrict you in what jdk you bundle your game with, so I dont see what that is relevant to this discussion.
I sit on the side of keeping everything as compatible with the most things as possible as long as we aren't breaking for the majority of users to support a very tiny subset. So that tends to keeping the lowest versions possible, and this is consistent throughout libgdx in terms of versioning and devices supported.
With regards to API not being available, I think the gwt case is a little comparable, this is just a lot worse. There will just be a lot more headaches for people trying to use something that they don't have any idea is not compatible. People aren't going to look for the library of what parts of the jdk are supported before hitting a problem. I dont think that's avoidable, so essentially I think a moot point, we will just have more people struggling here when they try to use things that aren't supported. That is for docs to handle.
My largest concern here is that the language features and new apis creep into the core library for nothing other than aesthetic or naïve overall benefit. As discussed in the other threads, this can be less performant, especially in terms of garbage. I agree with @tommyettinger and @PokeMMO s sentiments that they can improve the codebase structure, readability but with that we must be more diligent to make sure that we don't regress for one of the core principles that we use in libgdx, specifically 0 gc.
@noblemaster 's comment on supporting those cross compilation is valid. We have new stuff in robovm from new apis, and it will break, and we lose ios deployment, which is a deal breaker.

@Tom-Ski I don't think anyone wants to rush this process in a way that breaks MobiVM. dkimitsa mentioned updating MobiVM's Android core to a much newer version last year, but I don't know how far off that is. Language level 8 should already be supported on all platforms, via RetroLambda if needed (I think MobiVM uses RetroLambda now?). There are a lot of new Java 8 APIs and the platforms support them to different extents (obviously no Thread on GWT, so no Java 8 parallel stuff there either, for instance); Android Studio and I think also IDEA can be configured to use an Android version of the JDK that only has the methods that are Android-compatible to the specified version. I think if needed, we could update to language level 8 right now, and not break anything as long as the appropriate versions are kept up-to-date. This means no sudden additions of Java 8 APIs, but default methods and lambdas should be supported on all platforms, and if some platform isn't (like very old Android), there's RetroLambda.
I don't think cross-compilation to consoles can be considered until someone on the libGDX team has at least tried it. We don't have any idea what some mystery closed-source cross-compiler can do, or what it would have problems with, and it isn't our job to fix code that we can't even see.
As for 0 GC, any place that would have created a new anonymous inner class before was allocating, and as I understand it, lambdas are similar to anonymous inner classes that get special performance treatment from Java 8 (I think if you would have created two anonymous inner classes with the same environment and the same contents, a lambda would only be created once and shared, but I'm not 100% sure on this). Creating lambdas where they aren't appropriate could be a problem. Default methods in interfaces shouldn't have any impact on GC.

I'm equating your comments on cross compilation to MobiVM , since its very much the same rough procedure as what would need to be done for targeting consoles.  Even though MobiVM is outside of the libgdx project, it is our job to make sure we are still compatible in order for us to still deploy there. I'm not saying we need to not update anything in case some closed source compiler breaks, I'm specifically talking about Mobivm here and how its important that we don't make any api or language level changes in the internal api just for the sake of it when it has many consequences, this being one of them that many will overlook.
These discussions often end up just being kind of fruitless because we are talking in such broad terms and not about a specific example with specific solution. Since you brought that example up we can talk to that:
Making an anonymous class for a click listener and a lambda have roughly the same allocate cost in cpu and memory. There will be differences in the generated bytecode and one will be better than the other no doubt, but in this case we don't care since the difference isn't big enough for the general user use case, and this is a one time allocation that would have happened anyway.
I'm talking about critical code that has the potential to be called hundreds/thousands of times a frame.  Core update loop code, render logic, utilities and collections etc. So for a simple example instead for an indexed for loop to iterate over runnables, we used the stream api. Someone makes an interface now return from some functional api instead of a public field, and now we have implicit allocations happening everywhere that was called.

Orangepascal has managed to automate it for Switch. I believe he cross-compiles to C# first then to Mono Game but I don't have the details.

I just asked him on Discord, and (at least for his needs) the usage of Java 8 language features shouldn't be much of a problem for porting.

AGAINST Java 8: [...] people that only have Java 7 available (e.g. on a server or client) will not be able to use it.

AFAIK LWJGL 3's source level is already Java 8, so this can only pose a problem for people still using LWJGL 2. And those should think about upgrading anyway, considering that there is no support for the new Mac ARM architecture.

MobiVM is currently limiting the option of upgrading to Java 8 and, even if progess is being made, it will probably take a while until it's stable and the Java 8 language features well tested across the board.
On the other hand we seem to forget that libGDX is actually on Java 6 (some people believe it's on Java 7 due to Gradle config but libGDX is still being built with Maven).
Can we agree on upgrading to Java 7 and make Gradle and Maven builds consistent? (I keep using the diamond operator when working on the IDE to see it breaking when I run Maven).
Even upgrading to Java 7 and fully supporting its language features may have some risks (see https://github.com/libgdx/libgdx/issues/5839#issuecomment-553766606_) but we are starting to lose forward compatibility and we can't be stuck on Java 6 forever.
@Tom-Ski What do you think?
There's already a PR ready to be merged https://github.com/libgdx/libgdx/pull/5839
I don't want to hijack the thread, responses to this should probably be made on the Java 7 PR.

May as well give my own two cents on the matter now instead of never. If libGDX were to require Java 8 tomorrow, I could not care less.
At least, in regards to desktop. It is possible, though not officially supported, to get Java 8 installed on operating systems as old as Windows 2000 (caveat: Oracle only from what I could find and not the latest updates). LWJGL3 libGDX games can be built from and run fine under Java 8 on Windows XP. Haven't tested on Windows 2000 - installing it on my computer would be problematic. So in my opinion there's no need to avoid moving on from Java 7 in regards to compatibility.
In regards to Linux, I'll focus solely on Ubuntu, because it's the most popular and also what I use. As of Ubuntu 16.04 (April 2016) Java 7 is no longer available in the repositories. 14.04's support ended April 2019. So it's been challenging to test with Java 7 on Ubuntu for three LTS versions now, and using the final version with it in the repositories isn't advisable.
I also agree that Java 8 doesn't seem to affect mobile/web compatibility, though I have less evidence to back this claim up than OP! And the macOS situation is likely similar to Windows/Linux as discussed above.
So in conclusion, I see basically no reason against bumping the requirement up to Java 8 if it's necessary. I'm a little against changing it for the sake of changing it, but if doing so is beneficial for development of libGDX then go right ahead. And really only a little, as the number of people this would negatively impact is surely fractional.
HOWEVER, a very important point I've only thought of after spending too long writing the above five paragraphs is that LWJGL3 does not work on Java 7, as crykn mentioned. Recently #6463 was merged, which means new libGDX projects use LWJGL3 unless the developer goes out of their way use LWJGL2 instead. Running my level 7 LWJGL3 game on Java 7 results in Exception in thread "main" java.lang.UnsupportedClassVersionError: com/badlogic/gdx/backends/lwjgl3/Lwjgl3ApplicationConfiguration : Unsupported major.minor version 52.0. If someone's still using Java 7, they won't have a good time in the next version of libGDX.

As of https://github.com/libgdx/libgdx.github.io/commit/307791b9e2af9a55ee91175e49c64426d71b4009, users are only provided with the nightly version of gdx-setup, which uses LWJGL3. LWJGL3 requires Java 8. Codebase aside, isn't it time we at least had sourceCompatibility raised for the core and iOS backends in projects, if not the codebase itself, seeing as new projects don't work on JRE 7 anyway unless you go out of your way to make them work? My only reluctance is I have no first-hand experience of the state of things on iOS.

We certainly continue to jump through hoops specifically for iOS support. The last I heard of iOS support for Java 8 was in 2020, and it would be really nice if we could use a Java version that is supported everywhere else...

Latest news regarding MobiVM after asking Demyan (dkimitsa) is that:
hi, its question of several months to have MVP that can be used.  There is nothing blocking technically but mostly its matter of time.  also there was a legal moment of mixing Apache and GPL2 code but this might be handled by splitting into separate libraries/jars
This means that there's nothing actually preventing this to happen except from the time it'd take to do it.
Because afaik he's the only person capable of doing this I think we have 2 options going forward:

Wait until libcore10 is done (which might be several months but could be longer)
Define and limit very specifically which Java 8 language features and APIs we allow on libGDX that must be supported by MobiVM.

What do you think?

I'm honestly in favor of 2.

Define and limit very specifically which Java 8 language features and APIs we allow on libGDX that must be supported by MobiVM (can this be automated with some code analysis tool?).

I think we can actually mostly rely on android tooling to detect this? IntelliJ will e.g. hand out warnings like:
Call requires API level 24 (current min is 21): java.util.ArrayList#forEach.
We could also backport some of the java 8 API and make it equal to what android currently provides: https://github.com/google/desugar_jdk_libs/releases/tag/1.1.5

I've already been doing Option 2 with jdkgdxds, it isn't too hard. A potential issue would be the missing functional interface types such as Function<T, R> and IntConsumer; though these aren't hard to add, no one wants an identical functional interface declared 10 times throughout a codebase. My solution to that is the funderby library of mostly primitive iterators, which are mostly automatically-generated. Other solutions are surely out there. Another issue would be anything that relies on default methods declared in Java 8 but not available in Java 7 sources; because libGDX doesn't use interfaces much, this might not be an issue with the existing data structures.
An automated tool would definitely be welcome. Probably a Gradle plugin, checking compatibility at compile-time?
The desugaring library might be a good way to add Java 8 APIs, for sure.

An automated tool would definitely be welcome. Probably a Gradle plugin, checking compatibility at compile-time?

Regarding verification, that sounds promising, right?
https://www.mojohaus.org/animal-sniffer/
https://openjdk.org/jeps/247

JEP 247 is just the --release flag, I'm not sure it does anything differently from what we already knew that did... but animal-sniffer says it's a replacement for their tool. We absolutely could use --release to target Java 8 from newer JDKs (and only newer ones; it was added in Java 9). We haven't been able to target Java 7 with --release for a full year's worth of releases; support was removed in Java 20, I believe.

JEP 247 is just the --release flag, I'm not sure it does anything differently from what we already knew that did...

I'm not sure, doesn't the release flag check full API/binary compatibility, which is what we need? Or do I miss something?

(and only newer ones; it was added in Java 9)

I'm aware, but can't we just enforce a newer JDK version for building libGDX from source? (e.g. through the toolchains, even if they are seemingly controversial?)

I'm not sure exactly what the issue with toolchains is; they can ensure you build with a JDK that matches the target. That JDK is going to be older in our case, and some people like the features in newer JDKs.
I think we can soft-enforce a newer JDK version by just specifying what JDK GH Actions uses to build, and using the --release flag if it is between 9 and 24 or so. To build libGDX would only require that you have a somewhat modern JDK available (9 or newer, and 17 is required for Android anyway).

I think we can soft-enforce a newer JDK version by just specifying what JDK GH Actions uses to build, and using the --release flag if it is between 9 and 24 or so.

Yeah, I think we could even go further and bail out on compilation, if no java 9+ JDK is used to build. It would just reduce contributor annoyance when testing locally vs building on GHA.

We probably are using Java 17 JDKs to build the Android parts already... Although I was able to build with Java 8, I didn't change any Android-related variables, and I think those use 17 with current Android Gradle Plugin settings. I'm not sure I even can test building with Java 7; I know it would fail at LWJGL3.


added cses problemsets for coding challenges

The CSES Problem Set contains a collection of algorithm programming practice problems

@DhanushNehru Can you please review the pr?

@Swpn0neel please review the pr

@DhanushNehru , @Swpn0neel please add hacktoberfest label if possible


Update to new version of Identity

Hello, there is some new improvements to Identity, please update your project use to the latest version of the identity.

Hello, if you're talking about version 2.0.0-preview1 then I don't have any immediate plans to support that (might do that if there are enough requests). I do plan on supporting the final release though.

Hello, Final release is out. Any plan of porting this to support netstandard20?

Hello. I plan on doing that very soon.

My bad, I forgot there is a DBContext in there. Thought it was just pocos.

In theory, I can target netstandard2.0 using the new compatibility feature of .net 2.0. But it won't have much benefit since the consumer will need to target full .net for EF6 to work anyway.

Might be helpful in case they plan on adding support for netstandard in 6.3
Have a look here
Though I have my doubts it'll ever happen

Ah interesting. I also doubt it'll happen, seeing that EF6 remained completely without a dotnet tool for a few months when .net core was first released, while pushing people to use EFCore. I don't think they'll ever plan on giving EF6 more space than what it occupies now.

I totally agree. Offtopic but does ef6 have a tool now? other than the Migrator tool that you very kindly developed?

Nope, there isn't. Whether it is because Migrator.EF6 had filled that gap or they just didn't plan on creating one for EF6, not sure. I think you can use "migrator.exe" directly.. but who would want to do that. When this all started it was said that the new project system (after project.json) will work with the EF6 powershell tools. Haven't had to time to check, but I really prefer the handy dotnet ef much more anyway.

Yup dotnet ef is great if youre using ef core. But there are still some serious issues with EF core, which is why many people (including me) still prefer to use EF6.
I've opened so many issues (re. ef core) and they propose the silliest of workarounds. Long way for ef core to go before it catches up with EF6.

Indeed. I've long since lost hope for EFCore. At its current stage, it's perfect for small scale packages (ex IdentityServer), but not at all for enterprise level apps. In the future? Maybe.

Please try v3.0.0 and let me know if you face any problems. Haven't had enough time to test it thoroughly.


Tracking issue for yamux protocol breaking update

I'm opening this issue in parallel of https://github.com/paritytech/yamux/issues/92 to keep note, within Substrate, of this update.

I think that Substrate does not necessarily need to go through all those upgrade steps but can fast-forward to the end. The issue is about the initial window update. Since https://github.com/paritytech/substrate/pull/4892 the lazy_open yamux option is active in Substrate and the default receive window size was always the default, which means that no initial window update is ever sent by nodes which have #4892 applied. The new version will also only send initial window updates if the receive window is configured to be larger than the default.

It may just happen that, due to other changes in libp2p, substrate goes through these steps anyway but in any case there does not need to be a delayed rollout between such versions, as no "migration" should be necessary for substrate nodes.

Since #4892 the lazy_open yamux option is active in Substrate [...]

So just to confirm: Substrate versions v2.0.0-alpha.1 (tagging date: 2020-02-25) and later contain this setting. This means Polkadot v0.7.21 (tagging date: 2020-03-05) and later use it as well AFAICS, but versions prior to that do not and are thus not compatible with the changes to Yamux and will produce errors at runtime. Is this okay? In https://telemetry.polkadot.io/#list/Polkadot I see no version number less than 0.8.2, but https://telemetry.polkadot.io/#list/Kusama has some 0.7.0 instances, however they do not look healthy.

Any node that is not on a recent update, probably fails to sync anyway because of some missing functionality or similar for the runtime.

We've purposefully broken compatibility with versions 0.7.x recently.
0.8.0 is the version where Polkadot was released.

Let's close this, since the update is already fully done and working.


feat: add Aiken grammar

https://aiken-lang.org/
Sample taken from https://github.com/aiken-lang/aiken/blob/main/examples/hello_world/validators/hello_world.ak

I am sorry we couldn't include every single new language. Aiken seems to be fairly new and does not have a lot adoption yet, I'd suggest you provide custom theme object to use for now. If later that language is supported by GitHub we could bring this up again. Thanks.

No problem, @antfu. Thank you for the quick response!
Linking the pr just for the sake of connecting the issues: https://github.com/github-linguist/linguist/pull/6520


backport: enable guest_hook_path in remote config

@snir911 please cherry-pick this https://github.com/openshift/sandboxed-containers-operator/commit/440680a7cf57b799aa2309eb4cd2dd2670fcbdfe
Use git cherry-pick -sx


das: add test for DASer

Adds a test for the DASer.

@renaynay, pls fix lint issues and we can merge it.


Repository service provider not found

Hi @nikolas,
I have installed laravel-modules in my project. Everything is working fine except for the issue which is highlighted below.
I have implemented a repository layer inside of each module and loaded it in the app.php file. whenever I use to switch another branch of the git and execute the command composer dump-autoload I am getting the error message which is attached in Screenshot, don't know from where it gets the injected provided. I have deleted the vendor folder as well but the error remains as it was.  :(
Can you please help me out maybe I am doing something wrong?

hi,
Did you add the required lines in the composer json file?

Hi Nicolas,
Sorry I didn't see your email. nope, I just added in my app.php file
where providers are loading.
On Sat, Oct 3, 2020 at 7:59 PM Nicolas Widart<EMAIL_ADDRESS>wrote:

hi,
Did you add the required lines in the composer json file?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/nWidart/laravel-modules/issues/1069#issuecomment-703116684,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJK6KXHKH5ZHBZYRQLO5IBLSI435XANCNFSM4R24MI5Q
.

--
Best Regards :
Waqar Ali.
Software Engineer at The Vision spark.

hi,
Did you add the required lines in the composer json file?

Hello,
Nope, I just added in app.php file.

You also need to have that provider in your module.json file.


Add unit test for framework

What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Release note:

Codecov Report

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

@@            Coverage Diff             @@
##           master       #2      +/-   ##
==========================================
- Coverage   29.19%   28.63%   -0.56%
==========================================
  Files          61       57       -4
  Lines        3919     3737     -182
  Branches      441      427      -14
==========================================
- Hits         1144     1070      -74
+ Misses       2758     2658     -100
+ Partials       17        9       -8

Impacted Files
Coverage Δ

dolphin/api/v1/storages.py
30.08% <0.00%> (-10.57%)
:arrow_down:

dolphin/exception.py
81.70% <0.00%> (-5.49%)
:arrow_down:

dolphin/drivers/manager.py
39.21% <0.00%> (-3.93%)
:arrow_down:

dolphin/drivers/api.py
35.29% <0.00%> (-1.97%)
:arrow_down:

dolphin/utils.py
25.28% <0.00%> (-0.87%)
:arrow_down:

dolphin/db/sqlalchemy/api.py
22.92% <0.00%> (-0.25%)
:arrow_down:

dolphin/api/common/wsgi.py
23.49% <0.00%> (-0.21%)
:arrow_down:

dolphin/drivers/dell_emc/vmax/client.py

dolphin/drivers/dell_emc/vmax/alert_mapper.py

dolphin/drivers/dell_emc/vmax/vmax.py

... and 3 more


Upgrading qs:~6.5.2 dependency to use version: 6.5.3

Relates to https://github.com/ManageIQ/manageiq-ui-service/pull/1817
Using yarn why <package-name> I was able to track down which packages had qs as a dependancy
"angular-patternfly": "~5.0.3",
"coveralls": "~3.1.0",
"karma": "~6.3.14",
"mocha": "~8.2.1",
"sass": "~1.34.0",
"webpack-dev-server": "~3.11.0",

"angular-patternfly": "~5.0.3", and "coveralls": "~3.1.0", specifically depend on qs: ~6.5.2.
To simplify the PR I've split up the qs upgrade into two, this one focuses on taking qs from ~6.5.2 to 6.5.3. To do this I've bumped coveralls to ~3.1.1 (as this is the latest available) and bumped all of angular-patternfly's dependencies (to do this I had to remove angular-patternfly and then re-add it).
https://github.com/ManageIQ/manageiq-ui-service/pull/1821 will focus on upgrading qs from 6.7.0 to 6.11.0.
@miq-bot add_reviewer @jeffibm
@miq-bot add_reviewer @Fryguy
@miq-bot assign @Fryguy
@miq-bot add-label security fix

Can you rebase?  I merged #1823 and it conflicts now.


fix(gcs): gracefully handle invalid gcs client case

by default ignore default client credential errors until the accessor.client prop is referenced.
this allows you to call use_fs after the initial module import

:tada: This PR is included in version 0.0.7 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


KEY_OVER_1024_CHARS error with large indented blocks of comments

Describe the bug
If there's a large block of comments hanging indented under a key, that can trigger an error suggesting that the next key indicator is too far away.
To Reproduce
const comment = `# Test comment
owners:
  # Test comment
  business:
    - email<EMAIL_ADDRESS>      name: Moogly
    - distributionList<EMAIL_ADDRESS>
  # Another comment, large block of text, large block of text, large block of text
  # Another comment, large block of text, large block of text, large block of text
  # Another comment, large block of text, large block of text, large block of text
  # Another comment, large block of text, large block of text, large block of text
  # Another comment, large block of text, large block of text, large block of text

# Large block of text, large block of text, large block of text, large block of text, large block of text,
# large block of text, large block of text, large block of text, large block of text, large block of text,
# large block of text, large block of text, large block of text, large block of text, large block of text,
# large block of text, large block of text, large block of text, large block of text, large block of text,
# large block of text, large block of text, large block of text, large block of text, large block of text,
# large block of text, large block of text, large block of text, large block of text, large block of text,
# large block of text, large block of text, large block of text, large block of text, large block of text,
stage: one
`;

console.log(yaml.parse(comment));

The script produces the error:
YAMLParseError: The : indicator must be at most 1024 chars after the start of an implicit block mapping key at line 22, column 1:

# large block of text, large block of text, large block of text, large block of…
stage: one
^^^^^

Removing the indent from the first block of comments works around the error.
Expected behaviour
The text is valid YAML, it should be parsed, no matter how many comments there are or whether they're indented.
Versions (please complete the following information):

Environment: Node.js 16.15.1
yaml: 2.1.1

There was a bug in updating the offset during composition for empty mapping values with trailing comments. Thank you for reporting this!
Fixed version released as v2.1.2.

Might check it against my sample again. I don't think the main bug has been fixed yet.

Bother; you're right. I'd found first a minimal example that appeared to trigger the same error, and solved against that only.

New fix released as 2.1.3.
@fluggo Please let me know if that actually fixes this?

Closing as presumably fixed.


Add datasource to table and map panels.

This is a bit of a niche case - I integrate TeslaMate with an existing Grafana installation, which has a different datasource as the default. With the most recent release the table panels just displayed "No Data", and the map panels just displayed the world.
It took a while to debug, but I think it came down to the datasource not being specified correctly, and using the default - if that's not the default TeslaMate connection then you get no data.
Grafana don't specify their panel json format, so it's hard to know what the correct fix is. This change is pretty minimal and fixes the issue for me, so I wanted to submit in case it's useful to others. I've not tested it in a more standard installation, but I presume it will work ok.

In Grafana 7 (and according to my testing also in version 8) the dashboards use the datasource named "TeslaMate", regardless of whether it is set as default. Have you tried if it works if you add or rename your datasource?
I suspect it would break many installations if the dashboards always used the default datasource.

I can confirm this fixes my issue (described here https://github.com/adriankumpf/teslamate/discussions/2407) as well!

Hi,
I'm not sure what you mean by rename the datasource - do you mean rename the TeslaMate datasource? I'm not sure what that would do...
Most panels work fine, it's just the new map and tables panel that didn't work for me. #2407 is definitely the same problem that I was seeing.
Thanks,
Andrew

Confirming the same experience here and the fix @andrewjw arrived at fixes the issue.
I don't think it would be obvious that this is an issue if you are running Grafana with the TeslaMate datasource as the default, as @andrewjw says.
TL;DR: please merge this! 😉


Train

Thank you for your open source code! If I want to train on MOT20 and MOT15, how can I generate the detection file? Could you help me?


Video playback causes the device to crash

Device crashes when playing youtube videos. Is this a GPU memory issues?

Device crashes when playing youtube videos. Is this a GPU memory issues?

Do you have an example URL?


customization player

is there any way I can customize this player as in, adding logo, showing subtitles etc. Kindly let me know. thinking to use it in our current app.
Thanks,
Amir

@amirpervaiz086   Hi, You can see the example in the project.


Make Router.routes public

R: @philipwalton
CC: @westonruter
This takes a private property and exposes it publicly, as part of v4. There's going to be a (small) hit in bundle size, since that property name can't be mangled anymore.

+1 on making it public, but I'm split between whether or not we should use a getter or just not use the underscore.
I do think we should be consistent though, and currently we're not. In the workbox.routing.Route class we have the public match, handler, and method properties. But in the workbox.backgroundSync.Queue class we have get name(), which returns this._name.
From a minification perspective, I'm not sure there's a obvious winner either because, on the one hand not writing a getter method makes the class definition smaller, but on the other hand being able to minify all internal instances of ._routes also makes it smaller.
WDYT?

I guess, for something like this, we might as well go for whatever produces the smallest minified bundle?

Currently, in v3, workbox-routing.prod.js is 3252 bytes.
With this PR (making the property public), workbox-routing.prod.js is 3292 bytes.
With a getter, workbox-routing.prod.js is 3279 bytes.

I'll switch to the getter and save 13 bytes (before gzip).


Transport correct close

Codecov Report

Merging #19 into hotfix/raven-sender will decrease coverage by 0.16%.
The diff coverage is 50%.

@@                   Coverage Diff                   @@
##           hotfix/raven-sender      #19      +/-   ##
=======================================================
- Coverage                84.55%   84.39%   -0.17%
=======================================================
  Files                       14       14
  Lines                      518      519       +1
  Branches                    59       59
=======================================================
  Hits                       438      438
- Misses                      66       67       +1
  Partials                    14       14

Impacted Files
Coverage Δ

aiomisc/service/raven.py
61.53% <50%> (-1.21%)
:arrow_down:

Continue to review full report at Codecov.

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

Pull Request Test Coverage Report for Build 157

2 of 4 (50.0%)  changed or added relevant lines in 1 file are covered.
2 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.6%) to 85.714%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

aiomisc/service/raven.py
2
4
50.0%

Files with Coverage Reduction
New Missed Lines
%

aiomisc/utils.py
1
94.03%

aiomisc/service/raven.py
1
61.54%

Totals

Change from base Build 156:
-0.6%

Covered Lines:
451

Relevant Lines:
519

💛  - Coveralls


Pullp 1.0.2 Linux AppImage Does Not Start

When using the Linux AppImage release (retrieved from the release page of this repo), the AppImage does not start due to an bootstrapping error (see image under Current Behavior).
However, when building and running an un-packed version (built from src), the application runs as expected.
Thanks for creating this app. Been wanting a tool for managing PRs and review requests for some time now. Keep up the good work!
Your Version of Pullp
1.0.2
Your OS
Ubuntu 16.04 LTS
Expected Behavior
To launch normally (i.e when building and using unpacked version)
Current Behavior

Steps to Reproduce (for bugs)

Download pullp-1.0.2-x86_64.AppImage or build packed version
Allow executing
Run from command line (./pullp-1.0.2-x86_64.AppImage)

Console Errors
None, see image under current behavior

I had the exactly same error.

@N0taN3rd Thanks for reporting the issue. I run the app myself on Ubuntu 16.04 without any problems, including v1.0.2. Have you tried double clicking it in the Files GUI rather than executing via the command line? (Would be strange if this made a difference but worth trying).
Let me know if this sorts it for you, otherwise I'll have to dig a bit deeper. Unfortunately I'm on holiday all of next week so bear with me if I am slow to reply.

@N0taN3rd Hey man - thanks for reporting the issue! It seems there is a bug in the latest version of electron-builder. Am trying a downgrade...

@N0taN3rd I've released a new version https://github.com/rkclark/pullp/releases/tag/1.0.4 Please give this a go! It works on my Ubuntu 16.04 machine. Cheers!

Worked for me!

@rkclark the new version tag/1.0.4 works and closes this issue!
Thank you for creating pullp!
Best


CI test fails on travis-ci

Every thing works fine on my local MacOS box(using QT 5.5) but CI test fails on travis-ci.
Here is travis-ci build result: https://travis-ci.org/rainchen/react-rails-img/builds/150243935
it stopped at:
$ xvfb-run bundle exec rake
xvfb-run: error: Xvfb failed to start

and here is the content of .travis.yml:
language: ruby
rvm:
  - 2.2.2
env:
  global:
    - JAVASCRIPT_DRIVER=webkit_debug
before_script:
  - export DISPLAY=:99.0
  - sh -e /etc/init.d/xvfb start
  - sleep 3 # give xvfb some time to start
script: xvfb-run bundle exec rake

Tried several times but all failed:
https://travis-ci.org/rainchen/react-rails-img/builds/150224839
https://travis-ci.org/rainchen/react-rails-img/builds/150222985
https://travis-ci.org/rainchen/react-rails-img/builds/150221369
https://travis-ci.org/rainchen/react-rails-img/builds/150220253

Use either xvfb-run OR an init script, not both.

@mhoran
already tried, all failed, see those travis-ci results.
only using xvfb start in before_script:
https://travis-ci.org/rainchen/react-rails-img/builds/150224839
0.00s$ export DISPLAY=:99.0
before_script.2
0.01s$ sh -e /etc/init.d/xvfb start
Starting virtual X frame buffer: Xvfb.
before_script.3
3.01s$ sleep 3
17.20s$ bundle exec rake

only using xvfb-run:
https://travis-ci.org/rainchen/react-rails-img/builds/150220253
91.51s$ bundle install --jobs=3 --retry=3
19.10s$ xvfb-run bundle exec rake

WARNING: The next major version of capybara-webkit will require at least version 5.0 of Qt. You're using version 4.8.1.

I think I need a guide for how to config .travis.yml to use qt5 in travis-ci.

I finally got test passed on travis-ci, using following .travis.yml config:
# to get capybara-webkit work with qt5
# refs:
# - http://stackoverflow.com/questions/37201085/unable-to-locate-package-libqt5webkit5-dev
# - https://docs.travis-ci.com/user/trusty-ci-environment#tl%3Bdr---Using-Trusty
sudo: required
dist: trusty
addons:
  apt:
    sources:
      - ubuntu-sdk-team
    packages:
      - libqt5webkit5-dev
      - qtdeclarative5-dev
script: xvfb-run bundle exec rake

Thanks a lot!
To make it work, I needed to add:
before_install:
- export QMAKE=/usr/lib/x86_64-linux-gnu/qt5/bin/qmake

You probably already had that.


bosh scp cleans ssh artifacts before file is copied

Processing deployment manifest
------------------------------
Target deployment is `xxx'

Setting up ssh artifacts

Director task 13

Task 13 done

Cleaning up ssh artifacts

Director task 14

Task 14 done
/home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-scp-1.1.2/lib/net/scp.rb:359:in `block (3 levels) in start_command': SCP did not finish successfully (1) (Net::SCP::Error)
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.9.1/lib/net/ssh/connection/channel.rb:591:in `call'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.9.1/lib/net/ssh/connection/channel.rb:591:in `do_close'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:586:in `channel_close'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:465:in `dispatch_incoming_packets'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:221:in `preprocess'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:205:in `process'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:169:in `block in loop'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:169:in `loop'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:169:in `loop'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.9.1/lib/net/ssh/connection/channel.rb:269:in `wait'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-scp-1.1.2/lib/net/scp.rb:316:in `download!'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/lib/cli/commands/ssh.rb:220:in `block (3 levels) in perform_operation'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/lib/cli/commands/ssh.rb:263:in `block in with_ssh'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.9.1/lib/net/ssh.rb:210:in `start'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/lib/cli/commands/ssh.rb:263:in `with_ssh'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/lib/cli/commands/ssh.rb:209:in `block (2 levels) in perform_operation'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/lib/cli/commands/ssh.rb:204:in `each'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/lib/cli/commands/ssh.rb:204:in `block in perform_operation'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/lib/cli/commands/ssh.rb:153:in `setup_ssh'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/lib/cli/commands/ssh.rb:203:in `perform_operation'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/lib/cli/commands/ssh.rb:64:in `scp'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/lib/cli/command_handler.rb:57:in `run'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/lib/cli/runner.rb:56:in `run'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/lib/cli/runner.rb:16:in `run'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/gems/bosh_cli-1.2789.0/bin/bosh:7:in `<top (required)>'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/bin/bosh:23:in `load'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/bin/bosh:23:in `<main>'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/bin/ruby_executable_hooks:15:in `eval'
    from /home/ubuntu/.rvm/gems/ruby-1.9.3-p551/bin/ruby_executable_hooks:15:in `<main>'

BOSH 1.2789.0

This can error can happen when you try to download a file, but specify a destination file path instead of a destination directory. CLI generates the actual file name in that destination directory based on the job name where the file came from (useful when downloading from multiple instances). When passing a path, scp fails because it ends up trying to do /tmp/myfile.tgz/sourcefilename.ext.job_index.
I don't think it is actually cleaning up the ssh artifacts before scp'ing, just that error occurred and it waits to dump out the error until everything is cleaned up.

Closing this due to inactivity. The bosh cli has been rewritten in golang and has changed the scp/ssh behavior quite a lot. Feel free to create a new issue on the repository if you are still seeing this issue.


Include note for Cross Cloud Anonymous Join for the Teams endpoint section

Teams in DoD supports Cross-Cloud Anonymous Join, which means a DoD Teams user/client can join WW or GCCH hosted meetings. This has caused some confusion/lead to customers raising cases because they have whitelisted for DoD, but not for the other clouds. It is currently only implied that if they want to be able to connect to GCCH/WW meetings, that they have to whitelist for those endpoints.
Could we please include a warning/notification under the Teams subsection that for Cross-Cloud Join to properly work, they must whitelist the endpoints for the cloud of the target meeting? Also add links to the other cloud endpoint pages.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 13e07b8c-58ce-5d96-14cd-535b6d9c542c
Version Independent ID: 13e07b8c-58ce-5d96-14cd-535b6d9c542c
Content: Office 365 US Government DOD endpoints - Microsoft 365 Enterprise
Content Source: microsoft-365/enterprise/microsoft-365-u-s-government-dod-endpoints.md
Service: microsoft-365-enterprise
GitHub Login: @kelleyvice-msft
Microsoft Alias: kvice

@bradbrill Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/12131
Once the author approves, the changes will be live.
Thanks
Sri


Display a warning if multisig suffix paths don't match

Thanks. So with Jade we opted to be quite strict in this regard - in order to use multisig the user first needs to register the setup on Jade - ie. as a separate registration step the user inspects/confirms:
* all co-signer xpubs (the hw checks that at least one belongs the Jade)

* threshold

* script type

* (and now) whether bip67 key sorting applies

Once that has been confirmed, future requests to get receive addresses or change addresses will use the registered setup - the only additional data passed per request is the bip32 path suffixes. The full key derivation paths are validated against bip45/48/87, and that the final element is within a reasonable range. If this validation fails, a warning is displayed and the user must explicitly check/confirm the path.
We believe this should cover the known attack scenarios - but obviously are happy to hear if you think otherwise! ;-)

I think I thought of a scenario.
I noticed that to get an address, the computer sends the following to the Jade:
INFO:jade:Sending: {'method': 'get_receive_address', 'id': '468131', 'params': {'network': 'mainnet', 'paths': [[0, 2], [0, 2], [0, 2]], 'multisig_name': 'hwi'}} as cbor of size 108

However, I see that the Jade accepts paths that don't match like:
INFO:jade:Sending: {'method': 'get_receive_address', 'id': '865589', 'params': {'network': 'mainnet', 'paths': [[0, 1], [0, 2], [0, 3]], 'multisig_name': 'hwi'}} as cbor of size 108

which I think is non-standard in most companion wallets.
Could an attacker pass something like [[0, 2333], [0,3999], [0,4383]] and perform a type of ransomware attack on get_address or sign_tx, where they will only reveal the paths in return for some BTC?
I saw that there's actually some validation on paths here: https://github.com/Blockstream/Jade/blob/34a1814bbde5486e08600de701619fb7779b5455/main/wallet.c#L343 , but I don't think this case is covered. I think this wouldn't be a problem for 2 of 3 multisig, as the victim could easily brute force the paths because there's a check on MAX_PATH_PTR of 10000, so 10000^3=10^12 combinations to try (for comparison, bitcoin network hashrate is in the order of 10^20 Hashes/second), but this might be a problem for larger multisigs (I see up to 8 signers are supported). Should we be checking that the paths are all equal to each other for multisig wallets?
Originally posted by @Georgantas in https://github.com/Blockstream/Jade/issues/22#issuecomment-1002841897

Yes, it might be a good idea.
I initially decided against baking in the 'all paths (suffixes) must be the same' (hence passing one path suffix per signer, rather than just one common suffix) but I agree the combination of many signers may be difficult to brute-force.
Maybe display a warning if path suffixes are not identical ?

Yeah, I think a warning is a good idea to still allow users the flexibility.

I'll add this into the next fw version.  Thanks.

Warning as described added to fw version 0.1.33.
Many thanks for the review/suggestion.

Thank you!


Add safe transaction indexing section

Add blockchain indexing section

Closes https://github.com/safe-global/safe-transaction-service/issues/1655


Added github action to run tests on PRs

This PR adds support to run the library test suite against new pull requests to ensure the quality keeps consistent (Issue #33 )

@ChristianNavolskyi feel free to add your thoughts on when exactly the test suite should run.
It can also be extended to run on every push if desired.
It is also possible to add a build step to the CI, but I don't know how this would work for iOS (Mac) in terms of pricing.
Just to give you some basic ideas on how this could be improved/extended

Looks good I would say with my untrained eyes 😄
When the 2000 Github Actions minutes/month are only for private repositories we could also add a test run after every commit I guess.
I am not sure if the build is necessary, since this is only a package and not a standalone app.
Users usually would include in in their pubspec.yaml and get it from pub.dev.
Or what do you think?

I've just checked it and we should be good to go with the 2000 Minutes included in the free plan (given the fact that this is, for now, the only package which will use GitHub Actions).
Regarding the build step, I absolutely agree with you, it's not really necessary (and I think we would also only be able to run the android library build as I don't know if you can build on mac-os with the free plan).
If we want to run the tests on every push we should keep in mind that this also includes pushes on feature branches (which might consume quite a few minutes if you have someone pushing every commit separately).
I would say the decision is up to you if we include the pushes or not 🙂


Fix the UT - TestBroadcastVariablesInWorker

The test of assertMessage should be postponed after worker exit.

Current coverage is 76.63%

Merging #361 into master will increase coverage by +1.16% as of 10885d1

@@            master    #361   diff @@
======================================
  Files           45      45
  Stmts         4673    4674     +1
  Branches       418     416     -2
  Methods
======================================
+ Hit           3527    3582    +55
  Partial        180     180
+ Missed         966     912    -54

Review entire Coverage Diff as of 10885d1

Powered by Codecov. Updated on successful CI builds.

LGTM


fix missing events in "follow" mode

Better deployment error handling.
Better deployment error message.
Implement output filtering

Cool. In this PR, We will let you harness and improve the tailer over the next few days, in case there are others fixes. Beginning of next week, we will merge this PR (basically avoiding opening/merging to many PRs for subsequent changes)

@simcap I think I'm done with fixes and improvements, it can be merged now.

@fxaguessy done

Thanks for the work. Merging.


Add track_path option

An approach to: https://github.com/chocolatey/chocolatey-cookbook/issues/67
Added an attribute to the chocolatey resource to update the ENV['PATH'] during the chef install run so that choc packages that make changes to the path can be run in the same recipe as those that depend on the path reflecting the changes.

Chocolatey installs a file RevreshEnv.cmd in its bin that performs this same functionality. Its been a while since I have used it, but I'd suggest running it instead of your library code since it "ships" with chocolatey then see if you get the same results.
Also, we might consider just making this the default behavior rather than triggering it with a new attribute. The downside is potentially breaking people (more like a show stopper than a "down side"). When an installer adjusts your path, it seems like the right thing to do is to honor that path immediately. You see any issues there?

@mwrock - I wasn't aware of that, it's this script here?  https://github.com/chocolatey/choco/blob/master/src/chocolatey.resources/redirects/RefreshEnv.cmd
I agree that refreshing (or maybe merging) all the env vars, not just the path, seems like a useful thing to do. Most java stuff won't work if the JAVA_HOME env var is not set, for example.
Looking at the script though, I can't see how I could leverage it. It would need to run in a cmd.exe spawned by the chef run. The changes would be applied in the cmd subprocess rather than modifying the chef process ENV itself -- the next choco.exe that gets launched would not inherit the changes. Did you have another approach?
Personally, I think making this the default behaviour would be good. I tried to consider changes to ENV['PATH'] (via ruby blocks in cookbooks) and to both the USER and MACHINE paths and merge them in a way that would not drop anything. But... it does not always preserve the ordering and so could be a breaking change. I figured to default it false now and then flip to true on a major version change so that people with  "~> 1.5" would not get a nasty surprise.
If people are comfortable with merging this in, I'm happy to take direction on using RefreshEnv and applying it to environment variables more generally.
Thanks,
Rob

Yeah you are right. Heh I don't know what I was thinking - it has to be done in Ruby. While doing a complete refresh may be the ideal, I think PATH is the most important and a good start.
Do you mind just making this the default and removing the attribute?
I'll do some testing before merging that.
Also, this would warrant a 0.6.0 bump I think.
Thanks!

I checked against RefreshEnv and I think the patch does not use the right order.  The code, as is, does local + user + machine and it should do local + machine + user.
Seems bizarre to me that one would put the machine path before the per-user overrides, but that's what RefreshEnv does and it matches the windows default behaviour.
I'll fix that, flip the default behaviour and update the PR tonight.

@mwrock, modified as discussed.

I think we should remove the attribute too.

That's pushed and ready to go.
Removing the attribute means that tracking the path is always on. Anyone dependent on the previous behavior will have to modify their code or they won't be able to take the release.
I've left it to you to bump up the sem-ver appropriately.


Scoping

This Approach:

✅ Fixes half baked scoping with the single state case
⚠ Partial scoping is impossible given &mut Ui, &mut ViewStateIWantToScope

Multiple state generics: https://github.com/ejjonny/backer/tree/multistate

✅ Compiles without workarounds
✅ Enables partial scoping given &mut Ui, &mut ViewStateIWantToScope
⚠ Really doesn't scale, maybe that's fine
⚠ Noisy API to account for the single generic use case

Trait based scoping: https://github.com/ejjonny/backer/tree/trait-scoping

✅ Eliminates the need for AnyNode & related lifetime trouble
⚠ Actually conforming to Scopable as a user seems to be complex or error prone due to some recursive conformance checks? I can't even get the partial scoping test to compile..
❌ Requires manual drop as a workaround for this issue
❌ Causes clippy eternal lint issue

Closed in favor of #55


Code quality issue in SHA3: useless division

Reported by @karthikbhargavan
https://github.com/hacl-star/hacl-star/blob/main/dist/gcc-compatible/Hacl_Hash_SHA3.c#L307 could be 1 instead of a division

Permanent link for the code mentioned above: https://github.com/hacl-star/hacl-star/blob/8bc5b21f26917ab27cce93cab29270259524ff7b/dist/gcc-compatible/Hacl_Hash_SHA3.c#L307

Relevant F* code:
The call to update_multi in the generic functor implementation: https://github.com/hacl-star/hacl-star/blob/90a3b50041511871b607ae13025bb8738d83c78e/code/streaming/Hacl.Streaming.Functor.fst#L1361
The update_multi instantiation for Keccak: https://github.com/hacl-star/hacl-star/blob/37f0d971631736481b27010368ae29a5eb7cd425/code/streaming/Hacl.Streaming.Keccak.fst#L177


Update security-governance-and-compliance.md

add "," to have a unified typo

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

I'll leave this open for @BrianBlanchard to review, but it looks like "security" modifies "governance and compliance"; that is, it's an article about the governance and compliance of security. So, no comma would appear to be correct.

#sign-off

Hi @BrianBlanchard - Adding a comma, per the PR, introduces an inconsistency and ambiguity in meaning:

Does the phrase refer to three items, security, governance, and compliance, or does it refer to governance and compliance as it relates to security (security governance and compliance)? In either case, adding a single comma, as the PR does, wouldn't appear to be correct . . .


Cow: Watch cossouq.com

Cow requests the watch of the watch_keyword cossouq\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

cossouq\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by VLAZ in Charcoal HQ


InferenceAPI: sleep and loop if wait_for_model=True

if wait_for_model=True and server returns "model loading try again later", we should sleep and try again later (and still hang for the user). At the moment an error is raised.
Originally requested by @sgugger on slack.

EDIT: actually it might be worth sending wait_for_model=False and looping so that we can log to the user that it's loading.

if wait_for_model=True and server returns "model loading try again later", we should sleep and try again later (and still hang for the user). At the moment an error is raised.

This sounds like a bug. If wait_for_model=True, then the server should not respond until the model is loaded. Docs from API

(Default: false) Boolean. If the model is not ready, wait for it instead of receiving 503. It limits the number of requests required to get your inference done. It is advised to only set this flag to true after receiving a 503 error as it will limit hanging in your application to known places.

In the JS widgets on the Hub, we do a first request with wait_for_model=False, and if we get a model loading error (503), we do a second request with wait_for_model=True.

This sounds like a bug. If wait_for_model=True, then the server should not respond until the model is loaded. Docs from API

This was happening all day yesteday and has been fixed now. Depending on how often that bug can happen, I think it doesn't hurt if InferenceApi adds a layer of safety on top of the actual inference API.

No the response was immediate with "Model loading, try again in 20s" (or something like that).

Oh that must mean the query was not properly issued, or something dropped the information somewhere (if the thing is passed through headers, maybe some component could drop it).
Anyway I could reproduce simply ?

This was happening all day yesteday and has been fixed now.

We didn't make any change.... this is peculiar...

Probably won't fix as InferenceClient is now replacing InferenceAPI as the preferred client in huggingface_hub. Regarding timeouts and retries, it's handled differently now (including client-side retries) and should solves this issue (though we don't have a reproducible example).
See timeout docs for some details.

Newbie getting started, The deploy server less Inference button on upper right of model page,  produces the below code snippets which replies with "model loading" as below. it doesn't respect the "wait_for_model": True parameter in the JSON. which led me to this thread here. would be great to have the getting started code accessible from the deploy "server less" button
{'error': 'Model microsoft/Phi-3-mini-128k-instruct is currently loading', 'estimated_time':<PHONE_NUMBER>496094}
import requests
API_URL = "https://api-inference.huggingface.co/models/microsoft/Phi-3-mini-128k-instruct"
headers = {"Authorization": "Bearer xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}
def query(payload):
response = requests.post(API_URL, headers=headers, json=payload)
return response.json()
output = query({
"inputs": "Can you please let us know more details about your ",
})


German datetime

@hactar did an awesome job at starting the support of datetime in duckling and explained very well the current issue. We would love to get some help from the community here to complete it
https://github.com/wit-ai/wit/issues/212

I've updated https://github.com/hactar/duckling to 0.4.0-alpha and moved the german files to the corresponding new folders so that it can be pulled in easily. The issues of https://github.com/wit-ai/wit/issues/212 still persist so I haven't submitted a pull request.

I ran into the same problem in my branch.
I would love to help out and crack this one together

For partial work, you can prepend the files that don't work with an underscore (_), submit a PR, and open an issue with the help wanted tag (this one).

@petr-tik if you can solve the issues then yes please, I'll pull in any solutions you have.
@patapizza so in this case i would prepend all files in de/rules or also the files in corpus?

@hactar The ones that don't work, both in rules and in corpus.

I think I got this to work, using the sort of regex I wouldn't like my mother to know I've used: https://github.com/hactar/duckling/pull/2

Hey @hactar @jimregan @petr-tik thanks for your contributions! I'm the original author of Duckling and even if I used to speak some German, I didn't really take this kind of situation into account.
Your regex option is not that horrible, but it won't scale beautifully for larger number because everything will need to be in one big regex. Now, you could argue that very few people will write numbers in the millions in full letters, so we might live with the regex.
The best long term solution would be to add an option on some rules to tell them NOT to worry about whitespace. The way it works now, rules try to match their individual parts, and THEN check that what's in between can be considered whitespace. See this function. That's not super hard to do, but the rules DSL would become a little bit less clean (to support the option).
Please let me know if the regex route is good enough for now. And thanks again!

My opinion is that, for now, the regex solution is sufficient, as long as we could get it running for up to 999, the currently supports up to 99. I'd love to write a function for
#"(?i)(ein|zwei|drei|vier|fünf|sechs|sieben|acht|neun)hundert(ein|zwei|drei|vier|fünf|sechs|sieben|acht|neun)und(zwanzig|dreissig|vierzig|fünfzig|sechzig|siebzig|achtzig|neunzig)"
but I cant figure out how that would work (for starters I guess I'd need ":groups third" and that doesn't exist?
That said, https://github.com/hactar/duckling is pretty much ready to pull except for the last 2 test fails (the other 318 pass, yeay!):
0 FAIL "25.4. um 4"     Expected {:start #object[org.joda.time.DateTime 0x7b6eed5e "2013-04-25T16:00:00.000-02:00"], :grain :minute}     Got      25     Got      4     Got      4     Got      25     Got      4     Got      {:start #object[org.joda.time.DateTime 0x4115329b "2013-04-25T04:00:00.000-02:00"], :grain :hour} 1 FAIL "morgen um 3"     Expected {:start #object[org.joda.time.DateTime 0x16f83065 "2013-02-13T15:00:00.000-02:00"], :grain :hour}     Got      3     Got      {:start #object[org.joda.time.DateTime 0x68c04973 "2013-02-13T03:00:00.000-02:00"], :grain :hour} :de$core: 320 examples, 2 failed.
The issue is the 12 vs 24 hour thing. When a user says "um 3" he probably means 15:00, and this works. But when linked with "morgen um 3" (tomorrow at 3), the rules currently prefer the next day at 3:00 am. The same goes for the second failure (4 should be primarily identified as 16:00 and not 4 in the morning). I can't figure out how to adjust the rules to reflect this.
Playing does contain the correct value as one of the subvalues, but not as the main value:
`duckling.core=> (play :de$core "morgen um 3")
W -----------   7 | time      | intersect                 | P = -11.8421 | tomorrow + at <time-
----   6 | time      | at           | P = -3.3219 |  + time-of-day (late
-   5 | null      | number (as relative minutes) | P = -1.1324 | integer (numeric)
-   4 | time      | time-of-day (latent)      | P = -0.6062 | integer (numeric)
-   3 | time      | year (latent)             | P = -0.8918 | integer (numeric)
------        2 | time      | tomorrow                  | P = -0.2513 |
W           -   1 | number    | integer (numeric)         | P = -0.1187 |
morgen um 3
2 winners:
number                    {:type "value", :value 3} {:integer true}
time                      {:type "value", :value "2013-02-13T03:00:00.000-02:00", :grain :hour, :values ({:type "value", :value "2013-02-13T03:00:00.000-02:00", :grain :hour} {:type "value", :value "2013-02-13T15:00:00.000-02:00", :grain :hour})} {:direction nil}
For further info: (details idx) where 1 <= idx <= 7`
If someone could fix these final two tests then number and datetime in German is good to go.

I've been playing with it a little more, and the last version of the regex I'd had looked like this:
(?i)(((ein|zwei|drei|vier|fünf|sechs|sieben|acht|neun)?hundert)?((ein|zwei|drei|vier|fünf|sechs|sieben|acht|neun)und)?((zwanzig|dreissig|vierzig|fünfzig|sechszig|sibzig|achtzig|neunzig|dreizehn|vierzehn|fünfzehn|sechzehn|siebzehn|achtzehn|neunzehn|eins?|zwei|drei|vier|fünf|sechs|sieben|acht|neun|zehn|elf|zwölf)?tausend)?((ein|zwei|drei|vier|fünf|sechs|sieben|acht|neun)?hundert)?((ein|zwei|drei|vier|fünf|sechs|sieben|acht|neun)und)?(zwanzig|dreissig|vierzig|fünfzig|sechszig|sibzig|achtzig|neunzig|dreizehn|vierzehn|fünfzehn|sechzehn|siebzehn|achtzehn|neunzehn|eins?|zwei|drei|vier|fünf|sechs|sieben|acht|neun|zehn|elf|zwölf)?)

...and that still systematically misses some pieces, that I'm looking at now
":groups third" would be nice, but not necessary, because you can just use a cascade of regexes and build up the number in stages.

@jimregan looks like fun ;) I was actually thinking of simply splitting it into 3 rules, < 100, 111-129, and 101-110/121-999 but yours might be cleaner. Send me a PR when you're done.

I was thinking of going as far as 999,999 :)
There's something I want to try, but I've got overdue assignments to finish first.

hey any updates on this topic? i need datetime in a project so it would be really helpful to get this to work :)

As there's been no movement here for weeks, I've created a pull request because while it isn't perfect, I would say its good enough and better than nothing :).

We just released it on Wit... Thanks a lot for your contributions @hactar @petr-tik  and @helgetan
Would love to tweet about it and mention you if you have a twitter handle

Great to hear!! Twitter handle: Petr_tik
Cheers

Yeay! Looks like its working :) Im "PatrickWolowicz" on twitter.

Great! I'm 'jimregan' on Twitter


Finalize custom data support

Meta issue for custom data.
Will try to move html.experimental.customData and css.experimental.customData to html.customData and css.customData.

[ ] ~~https://github.com/microsoft/vscode/issues/63955~~
[x] https://github.com/microsoft/vscode/issues/67742
[x] ~~https://github.com/microsoft/vscode/issues/66307~~
[x] https://github.com/microsoft/vscode-html-languageservice/issues/57
[x] https://github.com/microsoft/vscode-html-languageservice/issues/56
[x] https://github.com/microsoft/vscode/issues/78068
[x] https://github.com/microsoft/vscode-docs/issues/2919

Update. We plan to include some sort of link protection. #78125 will need to be fixed before everything else could go in.

Started working on docs. Nothing to do in vscode repo -> closing.


[NEW ALGORITHM] Kahn's Algorithm in Graph Algorithms

Description:
I want to add Kahn's Algorithm under the graph section as it is one of most important algorithms while studying graph theory
Checklist:
Checklist:

[x] Contributor in GSSoC-ext
[x] Want to work on it
[x] Part of hacktober-fest

Additional Information:
I will write the program file in c and it will have detailed explanation of every line of code and I want to start contributing through this so please assign this to me.

@iking07 you can start