Make the CLI more usable

The CLI currently does not conform to the expected user interface. Specific concerns:

Installing the library should be one command
Bundling files into a torrent should be a separate command

One of the primary goals of the CLI should be as usable as possible. It's not immediately obvious to me how splitting up the functionality into separate commands makes it more usable, can you explain?

I think the typical interface pattern of CLIs is to have subcommands for each type of action that can be made. Thus, the flags are unique to each type of subcommand, not global. Subcommands for the Planktos CLI:
planktos install-lib => copies the library files
planktos bundle => bundles the website files to torrent

After looking at the CLI I now see that you can perform both of those actions in one command; however, in the setup section of the readme the instructions are to install the library only and then bundle the files into a torrent. This seems to make more sense to me, since you may want to update the library or torrent files without updating the other.

The reason there is a lib-only option is because the first time planktos is installed, the html needs to include the lib's script file before the torrent is created so the updated html is included in the torrent. All subsequent uses of the tool should both copy the lib and create the torrent. The first use is the only time I that I think of that someone would just want to copy the lib files. It makes more sense to me to perform both functions by default since that is what is wanted most of the time and leave the first time as the edge case. Thoughts?

It just seems unnecessary to me and complicates things slightly. If you think it's a good fix then go for it

It's just that the first time planktos is installed requires manually modifying some of the website's files to include the planktos lib script. But the lib script doesn't exist until it's copied over with --lib-only, and it's important to manually include the script in the html before the torrent is created so the modified html is in the torrent.
It is possible to update the library without updating the torrent with --lib-only. The library that is copied over is identical to the previous one that was copied over and will only differ if planktos is explicitly updated through npm.
I do agree that initial install is complicated and we should find a way to simplify things, but I don't think making sub-commands will achieve.

The simplest and must usable CLI are ones that do one thing and do it well. We should strive for that when making our CLI. I think the current CLI does one thing well, but the initial install requires doing half of that one thing (--lib-only). The main reason I'm against splitting the cli into multiple sub commands is that we are exposing a more complicated interface than the 'do one thing and do it well'

I do want to make the CLI more usable, and I think the best place to start that is eliminating the edge case for the initial install. If that's eliminated then the CLI will only do one thing and do it well. There will no longer be a need for doing just half, for a one time exception.

Getting rid of the exception seems like the best solution to me. Can you elaborate on how that would be accomplished?

One simple way would be to improve the docs. See #21

@georgeaf99 with the updated readme merged in, is this still an issue?

I guess not now. We should look for feedback on this though.


fix(action.yml): remove group workflow commands

Closes https://github.com/w3c/spec-prod/issues/1

Before
After

looks like support isn't good enough yet


Mapping from KB entity id to the text

Hello, thanks a lot for releasing the code for the paper. It is very helpful. I am wondering where can I find the mapping between the kb entity (e.g. "m.16jpgj") to a real text. I believe it is needed to obtain glove embeddings of KB entities, which are part of the released preprocessed data, but I don't see that code in preprocessing folder.
I have looked at several different sources and it looks like people have been using the Freebase from FastRDFStore Package. I have downloaded Freebase dump from this repo, but it looks like 17% of KB entities in your preprocessed data are missing.
I would really appreciate if you can provide a pointer to the public data with the mapping, or release that mapping for WebQSP. Thanks!

The preprocessing details are here. http://curtis.ml.cmu.edu/kbir/
Thanks,
Haitian

Hi @OceanskySun, thank you for your answer, but I don't think the textual forms of entities are in the preprocessing data. I see dictionaries with key entity_id and text, but text is always the same as entity_id. So textual forms of entities are still missing.

Okay. Can you try this one? http://curtis.ml.cmu.edu/datasets/graftnet/entity_names.txt


[Event Request] codeunit 6500 "Item Tracking Management"  OnBeforeTempHandlingSpecificationModify

Hello,
Hello,
Is it possible to add the following event.
        TempHandlingSpecification."Qty. to Handle" :=
                      TempHandlingSpecification."Qty. to Handle (Base)" / ReservEntry."Qty. per Unit of Measure";
                    TempHandlingSpecification."Qty. to Invoice" :=
                      TempHandlingSpecification."Qty. to Invoice (Base)" / ReservEntry."Qty. per Unit of Measure";
                    if not ReservEntry.IsReservationOrTracking() then // Late Binding
                        TempHandlingSpecification."Buffer Value1" += TempHandlingSpecification."Qty. to Handle (Base)";
                    **// DINNL <<
                    OnBeforeTempHandlingSpecificationModify(TempHandlingSpecification, ReservEntry);
                    // DINNL >>**
                    TempHandlingSpecification.Modify();
                end else begin
                    TempHandlingSpecification.Init();
                    TempHandlingSpecification.TransferFields(ReservEntry);
                    NextEntryNo += 1;
                    TempHandlingSpecification."Entry No." := NextEntryNo;
                    TempHandlingSpecification."Qty. to Handle" :=
                      TempHandlingSpecification."Qty. to Handle (Base)" / ReservEntry."Qty. per Unit of Measure";
                    TempHandlingSpecification."Qty. to Invoice" :=

[IntegrationEvent(false, false)]
local procedure OnBeforeTempHandlingSpecificationModify(var TempTrackingSpecification: Record "Tracking Specification" temporary; ReservationEntry: Record "Reservation Entry")
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Bot firmware

[x] Test networking
[x] Setup networking with WiFi router
[x] Create proposal for firmware.
[x] Create bot test server.
[x] Test and debug robot firmware code.

Today i have tested and verified the that my firmware work on the robots.  If you constantly feed the robots with small UDP packages. They will happily follow your command but if you slack of for more than 0.25 seconds they will stop in their tracks. I will go to vacation now for 2 weeks when i come back i hope to have a full end 2 end test of robot system with camera tracking and server control.


null-ls format panic when apply path PR#983

Description
when I upgrade gitsigns to the latest version, then formatter supplied by none-ls was broken
Neovim version
NVIM v0.9.5 Build type: Release LuaJIT 2.1.1703358377
Operating system and version
macos 14.2.1 (23C71)
Expected behavior
No response
Actual behavior

Minimal config
for name, url in pairs{
  gitsigns = 'https://github.com/lewis6991/gitsigns.nvim',
  -- ADD OTHER PLUGINS _NECESSARY_ TO REPRODUCE THE ISSUE
} do
  local install_path = vim.fn.fnamemodify('gitsigns_issue/'..name, ':p')
  if vim.fn.isdirectory(install_path) == 0 then
    vim.fn.system { 'git', 'clone', '--depth=1', url, install_path }
  end
  vim.opt.runtimepath:append(install_path)
end

require('gitsigns').setup{
  debug_mode = true, -- You must add this to enable debug messages
  -- ADD GITSIGNS CONFIG THAT IS _NECESSARY_ FOR REPRODUCING THE ISSUE
}

-- ADD INIT.LUA SETTINGS THAT IS _NECESSARY_ FOR REPRODUCING THE ISSUE

Steps to reproduce

nvim --clean -u minimal.lua
...

Gitsigns debug messages
No response

got the same issue

Same issue here.

dropping back to that commit fixed it for me too


Training without batch labels

I am trying to implement scVI on a single-cell dataset and although I do not have the batch annotations for it, through the literature I am aware that it consists of 2 batches. While training using the VAE command, I specified the number of batches as 2. Would this still mean that the mean and standard deviation parameters of the size factors will be a vector of size 2?
In other words, does specifying only the number of batches without explicitly giving the annotations automatically predict the probable batch index of each cell?
Also, is there a function to get the size factors from the trained model?

If I'm understanding your question correctly, then no, it's not possible for scVI to automatically infer which batch a cell came from, as scVI assumes that the batch annotations are given. The Posterior function .get_stats() returns the size factor. It will always be a scalar. When there are multiple batches, the prior distribution is set empirically per batch.

Yes, that was my question, thanks!

If there is a batch effect, perhaps you could separate cells based on PC1 or PC2 and try to assign a batch label that way.


Fix issues with inferred Scala classpath configurations

Context
This pull request fixes the following issues:

https://github.com/gradle/gradle/issues/27226
https://github.com/gradle/gradle/issues/27309
https://github.com/gradle/gradle/issues/18435

As a side improvement, it also makes the Task interface extend Named, similar to the recent improvement to the Configuration interface.
Contributor Checklist

[x] Review Contribution Guidelines.
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team.
[ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective.
[x] Provide unit tests (under <subproject>/src/test) to verify logic.
[x] Update User Guide, DSL Reference, and Javadoc for public-facing changes.
[x] Ensure that tests pass sanity check: ./gradlew :scala:sanityCheck.
[x] Ensure that unit tests pass locally: ./gradlew :scala:test.
[x] Ensure that tests pass locally: ./gradlew :scala:quickTest.

Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

I built Gradle locally including my changes, and using this version resolved the issues in my earlier reproductions. 🙂
Ready for review.
Should I add any integration tests specifically for these issues, or would the existing ones and the unit tests be enough?

Could these fixes still make their way into the 8.7 release? If so, should I be targeting this PR at a different branch, e.g. release?

Rebased my changes on the release branch and switched the PR's target to that too.

@jvandort I rebased my changes on the release branch and switched the PR's target to that too, based on how https://github.com/gradle/gradle/pull/28267 got merged into the 8.7 RC2 milestone.

Thank you for your contribution!
Please, move out your changes related to Task interface as they are not scala-specific and would require a separate consideration since it's a change in the core API.

Should I add any integration tests specifically for these issues, or would the existing ones + new unit tests be enough?

Will answer to that later, after the review from the community.

Could these fixes still make their way into the 8.7 release? If so, should I be targeting this PR at a different branch, e.g. release?

No. The release window for 8.7 is closed. This PR can land in 8.8 if it's merged before April.

@ijuma @tgodzik @dubinsky @SheliakLyr If you have time, can you take a look at this PR? As you know, we are counting on the Scala Community to help improve Gradle Scala Plugin.

@ov7a

The release window for 8.7 is closed. This PR can land in 8.8 if it's merged before April.

Ah, too bad. I was hoping that bug fixes can still get included in the next 8.7 release candidate.
I'll rebase everything back on top of master then, switch the PR back to target master, and update the @since in my Javadocs to 8.8.

Please, move out your changes related to Task interface as they are not scala-specific and would require a separate consideration since it's a change in the core API.

Will do, but some of the code in this PR depends on that change. How should I represent this, so that the PR remains buildable? The idea I have:

Rebase commit b05254bfcdff1a011366f7dd8705a951425b8ec0 on top of master, and move it to a separate branch and PR targeting master
Rebase the commits remaining in this PR on top of that new branch, and keep targeting master

Is this the correct approach? I believe that the commit related to the changes in Task would still show up here initially, but disappear once that PR gets merged.
Thanks!

Will do, but some of the code in this PR depends on that change. How should I represent this, so that the PR remains buildable?

Please make this PR buildable without that change. You can create a separate PR for the Task changes, but please keep them independent. I understand this can result in some complications to this PR, but since the Task change is a core API change, it may be rejected or postponed until 9.0.

@ov7a

Please make this PR buildable without that change. You can create a separate PR for the Task changes, but please keep them independent. I understand this can result in some complications to this PR, but since the Task change is a core API change, it may be rejected or postponed until 9.0.

I have high hopes that it will be accepted quickly, given that it's based on a very similar recent change, and it's completely backwards-compatible. I just submitted the separate PR, if someone could take a quick glance at it (max. 2 minutes), that'd be much appreciated: https://github.com/gradle/gradle/pull/28282
With that said, I understand your concern. I can make this PR independent without a lot of effort, it's just that the error reporting won't be as descriptive without that core API improvement.

I updated the code to avoid relying on https://github.com/gradle/gradle/pull/28282, and created a separate scala-plugin-cleanup branch in my fork to demonstrate the envisioned end state after the other PR is merged: https://github.com/pantherdd/gradle/compare/scala-plugin...scala-plugin-cleanup

@ov7a The CI build you started failed with this error:
Gradle could not start your build.
> Could not create service of type BuildCacheController using .createBuildCacheController().
   > Cannot use Gradle Enterprise build cache client without specifying Gradle Enterprise server address.

It was the same yesterday; I thought that maybe it was just a one-off, but it seems like it isn't. My guess is that this is unrelated my changes, and it's likely some central issue with the CI setup, but just to make sure: is there anything I can/need to do to fix this?

@pantherdd
Yes, this is a known CI problem; it's unrelated to your changes, and you can ignore it.
It is fixed in the master already, so you can rebase your PR, but this action is optional.

@ov7a No worries, I'm happy to do such small chores to have a successful CI run. But unfortunately rebasing the changes on current master did not fix the issue.

@pantherdd whoops. Sorry about that. I've notified the responsible team.

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test this

Sorry but I'm afraid you're not allowed to do this.

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

Most of the failures are fixed now, there are only 2 remaining:

GradleBuildSanityCheckConfigurationCacheSmokeTest, which seems unrelated
:architecture-test:test shows that I broke 5 rules

ConfigurationCreationTest > configurations_are_created_with_role_based_api
ProviderMigrationArchitectureTest > public_api_task_properties_are_providers
ProviderMigrationArchitectureTest > public_api_task_file_properties_are_configurable_file_collections
PublicApiCorrectnessTest > public_api_methods_do_not_reference_internal_types_as_parameters
PublicApiCorrectnessTest > public_api_classes_do_not_extend_internal_types

How strictly are these rules enforced, do I have to find a way to abide by all of them or is there a way to get an exception? For example:

The Configurations registered by ScalaRuntime would have to use the ConfigurationRoles.RESOLVABLE_DEPENDENCY_SCOPE as far as I understand, but there does not seem to be a way to register such a Configuration
ScalaTask.getConventionMapping() does not return a Provider, and I can't really change that because I'm inheriting that method from IConventionAware, but have to declare it myself too only to add an @Internal annotation on it
ScalaTask extends IConventionAware, yes, but if that's a no-go, what should it do instead?
The other method declarations of ScalaTask are copied from ScalaCompile and ScalaDoc, I can't change their signature either
ScalaJar.inspect returns a Stream, which is not allowed, but what is the proper alternative that allows short-circuited filtering? Or should I throw the optimization aspect away and just return a Collection (or something similar)?

If you have time, can you take a look at this PR? As you know, we are counting on the Scala Community to help improve Gradle Scala Plugin.

This pull request is, in my opinion, very helpful and well executed; I hope it gets accepted soon.

Rebased on latest master now that https://github.com/gradle/gradle/pull/28282 is merged
We can now remove the redundant extends from ScalaTask (since now Task itself extends Named).

It's only the :architecture-test:test rules now that are causing PR check failures, but I'd need some advice from the maintainers on what I should do about those. Detailed questions are in my earlier comment.

@pantherdd In general, new code should obey the architecture rules. There might be exceptions, but you need a solid reason to get an exception for the rule. For the Scala plugin, it might be something like "it was that way before, it is already in the exception list, and it's hard to change", but it's up to the @gradle/bt-jvm team to decide.

there does not seem to be a way to register such a Configuration

Please look at ConfigurationContainer.resovable and ConfigurationContainer.dependencyScope

The other method declarations of ScalaTask are copied from ScalaCompile and ScalaDoc, I can't change their signature either

getScalaClasspath() and similar are in the exclusion list, so it's up to JVM team to decide.

ScalaTask extends IConventionAware, yes, but if that's a no-go, what should it do instead?

Potentially you can avoid this problem by extending SourceTask - both ScalaDoc and ScalaCompile extend it already.

ScalaJar.inspect returns a Stream, which is not allowed, but what is the proper alternative

You can use Iterable or Collection, yes.

@ov7a Thanks for the guidance, I was able to modify my code in a way that it now passes the architecture-test checks too. 👍
Notes:

The code is still calling project.configurations.register, so no idea why configurations_are_created_with_role_based_api doesn't fail anymore. 😮

I can't switch to using ConfigurationContainer.resovable / ConfigurationContainer.dependencyScope because I need both roles here (if I understand them correctly).
I could create such a configuration using RoleBasedConfigurationContainerInternal.resolvableDependencyScopeUnlocked, but is there a way to register one instead?

ScalaTask can't extend SourceTask because the latter is an abstract class, and ScalaTask needs to be an interface to keep the class inheritance tree of ScalaCompile and ScalaDoc intact. The solution I came up with was to use a runtime check whether a given ScalaTask instance implements IConventionAware, and only register a scalaClasspath convention if it does. This allows users to implement their own ScalaTask classes without the convention.
I added ScalaTask's FileCollection properties to the exception list (provider-task-file-collection.txt), pending approval of course.
ScalaJar.inspect now returns an Iterable instead of a Stream. It's a bit more clunky to use, but it follows the rules. Same for the VersionNumber property.

@pantherdd Thanks! For the remaining issues - it's up to @gradle/bt-jvm team.

For the remaining issues - it's up to @gradle/bt-jvm team.

@ov7a The @gradle/bt-jvm tagging doesn't seem to get recognized by Github (at least it's not clickable) – does that team need to be notified about this in some way, or do they see that their assistance is required here through some task board? Thanks 🙂

@ov7a The @gradle/bt-jvm tagging doesn't seem to get recognized by Github (at least it's not clickable) – does that team need to be notified about this in some way, or do they see that their assistance is required here e.g. through a task board? Thanks 🙂

This is a private group. It's on their board, don't worry. However, this may take time for them to get to it due to other priorities. Sorry for the delay.

Sorry it has taken so long for me to review this one and thank you for going through the effort of enhancing the Scala infrastructure. We certainly need improvements in this area.
Unfortunately, this is the opposite direction we want to go in. The main issue is that this PR doubles-down on inferring scala versions from the classpath and this is a behavior we want to move away from.
In general, we want the user to be explicit. There should be a field on the scala extension where the user declares the version of scala they want to use. This would then translate to us adding the scala dependency for the user, similar to how test suites adds test framework dependencies for the user.
As it exists, we need to go through all this complicated and error-prone work to parse through the scala jar and inspect its contents. None of this should be required. The existing logic to parse file names and extract jars should all go.
Another thing we want to avoid is exposing low-level wiring to users. Much of the public methods in ScalaRuntime.java, even if they were merged in, should not be exposed and accessible to the user. These are not the sorts of utilities that should be accessible from buildscripts.
I am closing this PR since we do not want to go in this direction. Instead, we should discuss a solution more in-line with our goals on https://github.com/gradle/gradle/issues/18435, which hints at the core problem that there is no way to declare the scala version.
In general, we would want to end up with a solution that looks something like below, with no inference at all:
plugins {
    id("scala")
}

scala {
    runtimeVersion = "foo"
}

@jvandort @ljacomet I understand that you do not want to focus on this because a full rewrite is expected in later major version of Gradle, but as far as I can tell @pantherdd's PR keeps everything backward compatible.
Would it be possible to use this PR as a temporary fix for an already broken behavior in a backward compatible way before you get a chance to completely rewrite it in newer versions?

This PR introduces several new APIs and deprecates several others. We want to avoid API churn like this, especially if those APIs will be replaced again in the short to medium term. Any new APIs introduced should move towards explicitly declaring the scala version.
If classpath inspection can be improved without changing the API, we would consider merging that code. Otherwise effort should be focused on a solution where the version is declared.

@jvandort Thanks for the explanation of what the actual blocker is. If I understand correctly, it's the methods that are marked with @Incubating, as they create new public APIs that may not mature but will have to be thrown away. Based on your reply, we can get back to discussing potential solutions.

Before I even started working on these changes, I was told that "Scala Plugin is out of the team's focus for now and it's unlikely that the related issues will be addressed in the near future". Has this changed? Are there plans now for implementing the set of (breaking) changes that you described as the long-term solution? What is the planned version of Gradle that such changes could be included in?
According to the docs, @Incubating means that "the feature is currently a work-in-progress and may change at any time". Is it a problem if such an API gets dropped after a few minor versions, before it could become stable?
What changes would I need to make for this backwards-compatible changeset to become acceptable?

I could remove the @Deprecated annotation I added to the old APIs, meaning they would still be considered the stable solution, and my new APIs would become completely optional, used by only those who really need them. These users would know the APIs could get dropped any time because they're @Incubating.
I could even move all of the new APIs into an internal package, so they wouldn't even become @Incubating public APIs. Maybe we could make some exceptions, as some APIs point in exactly the direction that you're proposing (creating a Scala classpath configuration for an explicitly specified version, solving #18435).

Let me know what you think. Provided that you see some way forward, can you please reopen the PR?
Thanks.

@jvandort, @ov7a, @dubinsky What do you all think about the proposed solutions? I would really like to avoid throwing all this work out the window. And I would still like to get this into #266, because the improvements are basically ready, I just need to know what exact modifications would make this acceptable (to avoid further wasted effort).

Sorry, Justin's out right now.
There are a couple of blocking issues in the PR. We do not want to create more Configurations, especially when they're used for a single purpose (e.g., like is done in IdeaScalaConfigurer).
We also don't want any of the APIs added in ScalaRuntime to creates/configure Configurations to be used for resolving Scala classpaths. It doesn't matter that they are @Incubating.
I think we're trying to solve too many issues at once, so to pare it back a bit, I think we can address just https://github.com/gradle/gradle/issues/27226
There are two ideas here:

Instead of looking at the file names, let's load up the given classpath in ScalaRuntime.inferScalaClasspath and ask what version it is. This might be slow, but we can cache or speed it up. This does't require any new APIs.
Introduce a ScalaRuntime.scalaVersion of type Property<String>. When this is set, we use whatever it says. Otherwise, we fallback to the old behavior.

(1) is doable. We don't need to support a generic way to lookup a Scala version from a jar or classpath. I think there are only 3 places that look up the Scala version:

ScalaRuntime definitely needs the Scala version, but this can be contained.
IdeaScalaConfigurer looks like it uses the Scala version to generate a name in IntelliJ, but I can't believe that the name is meaningful. It seems like we could just drop the version number.
ScalaCompileOptionsConfigurer needs the Scala version to determine what command-line arguments to pass, but I think this can be deferred and done later. Ultimately, ZincScalaCompilerArgumentsGenerator needs to know the command-line argument, but I think we can figure out what the appropriate CLI argument is there if we just know the effective target.


Why do you use a softwareBitmap

Hi!
I really love the library. its the first library i could find that looks good. I do however have a question regarding the code. In the renderers you use a software canvas and a software bitmap. It this to reduce compitations or something or why are you using it?

Hi, I use software canvas(no hardware acceleration) in LineChart and PieChart.
In LineChart I use Path to draw cubic lines and filled area, unfortunately there are problems with Path on hardware accelerated canvas. I can't use canvas.drawLines with Paint.Style.FILL because it doesn't work at all on hardware accelerated canvas.
Related issues: Path with HW, Large Path with HW
In PieChart I use software canvas to achieve transparency for center circle. To do this I need to use PorterDuff.Mode.CLEAR which doesn't work with hardware acceleration:(

Aaaah of course.
I really love the library and i use it on a daily basis. What i have noticed is that the line charts consume a lit of memory and i wanted the feature to click on one value in one line and then select that same x-value on another line having them both selected at the same time so i had to stack two linecharts on top of each other and that reuires quite a bit of memory due to the bitmaps.
I will try to look into this and if i find a good solution i would be happy to send you the code.


Add saving support to Settings file

Also Add method called after constructor has finished that can be overridden called OnLoaded, This means you can access ScriptSettings before the main script starts without getting errors that you would get by putting it in the constructor
fixes these issues
https://github.com/crosire/scripthookvdotnet/issues/249
https://github.com/crosire/scripthookvdotnet/issues/248

Looks good to me @crosire
Devs can decide if they want to support saving (with the disadvantage of comments getting deleted) or don't want to support it (and keep the comments)

I support it. It is at least better than this:
File.WriteAllText(configfile, ("[" + sectionname + "]"+ Environment.NewLine + "Enable/Disable_Menu = F6" + Environment.NewLine + "Forward_on_noclip = W" + Environment.NewLine + "Back_on_noclip = S" + Environment.NewLine + "Left_on_noclip = A" + Environment.NewLine + "Right_on_noclip = D" + Environment.NewLine + "Increase_speed_on_noclip = Add" + Environment.NewLine + "Increase_speed_on_noclip = Subtract"));


Can no longer check typeof foo.bar === 'function' without running afoul of method-unbinding

Flow version: 0.153.0
Expected behavior
/* @flow */

type Foo = {
  +[string]: string,
};

interface Bar {
  has(string): boolean,
}

function fn(o: Foo | Bar) {
  // works in 0.152.0, errors in 0.153.0
  if (typeof o.has === 'function') {
    o.has('');
  }
}

Actual behavior
    12:   if (typeof o.has === 'function') {
                       ^ property `has` [1] cannot be unbound from the context [2] where it was defined. [method-unbinding]
        References:
        12:   if (typeof o.has === 'function') {
                           ^ [1]
        8:   has(string): boolean,
             ^ [2]

Link to Try-Flow or Github repo: https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgBiccYAvGAN6phgDUA2gM4YBOAlgHYDmAugFxgWHHgBpUAXwDc6LhjysoAQwDGBAEJLWVGmAAWSpgAphXbgEpBAIxIw8SzuInooAV04qM7OJzBRORnCCxKQAPmCarOY6tOxQYEbY+HDxcAB0BkzkZBQA5G4eXj650dS0tOmZRrklMrTOzkA

Instead of checking the type of has can you instead add a sentinel property to these two types as described here: https://flow.org/en/docs/types/unions/#toc-disjoint-unions

Not in my case, though I found a way to just split fn into two functions and avoid the union entirely.


[SPARK-29311][SQL][FOLLOWUP] Add migration guide for extracting second from datetimes

…

What changes were proposed in this pull request?
Add migration guide for extracting second from datetimes
Why are the changes needed?
doc the behavior change for extract expression
Does this PR introduce any user-facing change?

No
How was this patch tested?

N/A, just passing jenkins

cc @gatorsmile @cloud-fan @dongjoon-hyun, thanks.

Test build #120891 has started for PR 28140 at commit 9ac24d8.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/25583/
Test PASSed.

Test build #120891 has finished for PR 28140 at commit 9ac24d8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/120891/
Test PASSed.

thanks, merging to master/3.0!


QOL: Autocomplete entries sorted by distance

Since I found it quite annoying that the autocompletion was always based on the coordinate 0,0, I implemented that if there is a query point above the currently selected one, these coordinates are sent together with the geocode request to the GraphHopper Geocoding API.

fixes #385

Ah yes, I admit that this realisation follows the motto "quick'n'dirty"
I'll look into this :)

This should do it

I've moved the logic part out of the Geocode class, could you check if this is what you had in mind?


ARROW-15788: [C++][FlightRPC] Prepare benchmark for alternative transports

CC @cyb70289 if you'd like to take a look, this is just a minor refactoring to minimize the amount of churn that will be in #12442


Conflicting Task model when sync = True

Hi !
So I'm trying to get my head around this package. I wrote an async call, following your doc (which is great !). Nothing happens, so I add sync=True and bam, I get this stacktrace:
def myhook(task):
    print task.result
    import ipdb; ipdb.set_trace()

def inventory_apply(request, pk, **kwargs):
    """Apply this inv to the stock.
    """
    from django_q.tasks import async, result
    async('models.Inventory.apply_inventory', pk, hook='myhook', sync=True)

stacktrace:
Traceback (most recent call last):
  File "/home/vince/.virtualenvs/abelujo/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 132, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/home/vince/projets/ruche-web/abelujo/search/models/api.py", line 959, in inventory_apply
    async('models.Inventory.apply_inventory', pk, hook='myhook', sync=True)
  File "/home/vince/.virtualenvs/abelujo/local/lib/python2.7/site-packages/django_q/tasks.py", line 49, in async
    return _sync(pack)
  File "/home/vince/.virtualenvs/abelujo/local/lib/python2.7/site-packages/django_q/tasks.py", line 675, in _sync
    cluster.worker(task_queue, result_queue, Value('f', -1))
  File "/home/vince/.virtualenvs/abelujo/local/lib/python2.7/site-packages/django_q/cluster.py", line 366, in worker
    m = importlib.import_module(module)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/home/vince/.virtualenvs/abelujo/local/lib/python2.7/site-packages/django_q/models.py", line 12, in <module>
    class Task(models.Model):
  File "/home/vince/.virtualenvs/abelujo/local/lib/python2.7/site-packages/django/db/models/base.py", line 309, in __new__
    new_class._meta.apps.register_model(new_class._meta.app_label, new_class)
  File "/home/vince/.virtualenvs/abelujo/local/lib/python2.7/site-packages/django/apps/registry.py", line 221, in register_model
    (model_name, app_label, app_models[model_name], model))
RuntimeError: Conflicting 'task' models in application 'django_q': <class 'django_q.models.Task'> and <class 'models.Task'>.

My app runs well with django-q installed, only sync=True will fire this.
Can I give you more info ? On my side, I checked that I don't have a model called Task. I saw an import * in my models' __init__.py, which I tried to remove with no different result.
Django 1.8, Python2.7, django-q latest from pypi, 0.7.18
Any idea ? Thanks !
ps: is there special debugging methods ? Looks like I won't fall into my ipdb.set_prompt.

@vindarel a few questions.
What's the backend your using?
Did you start all services?
What I can see from the error message it looks like you have a models.Task class

I'm using django's orm as cluster and cache. (and… services ?)
Maybe I have a django extension with a Task class ? (django-extensions, werkzeug, mod_wsgi). Will look into these then.

According to this SO thread, the pb may arise with two different kind of imports: from django_q.models import Task (like in signals.py) along with from .models import Task (init.py).

btw there is an interesting discussion in this old django bug report: https://code.djangoproject.com/ticket/22280#ticket


Received message handler?

We need a handler for received messages, calls, message statuses, etc. :)

I see that he already implemented database using postgree or maybe MySQL
We can get message in there
But yeah it will be good if there a config in .env maybe like url_message_received_callback= if it not empty, than it post message to that url

I see that he already implemented database using postgree or maybe MySQL We can get message in there
But yeah it will be good if there a config in .env maybe like url_message_received_callback= if it not empty, than it post message to that url

Only sqlite so far :)
MySQL would be magical, but whatsmeow doesn't plan mysql support, postgresql is prioritized there

I found the documentation https://pkg.go.dev/go.mau.fi/whatsmeow#Client.AddEventHandler but somehow I have no idea how to do it in our case

Thank's @Diden05 for the information, i also already explore it, with implement it as webhook like pak @ibnux said soon

Can't wait to see this in action... Any estimation on when to implement this pak @dimaskiddo ? :blush: :pray:

For now I use android apps, whatsauto In playstore
Because WhatsApp still need dedicated phone that's why it handle received message in phone

waiting for webhook implementation, this is going to be really cool 🙏

hey, really need this feature man. Do you have any estimations?


Added PluginAwareInterface and marked EventsCapableInterface as deprecated

Since the StorageFactory only checks for the EventsCapableInterface, it would result in a Call to undefined method WhateverStorage::hasPlugin.
Therefore, I would like to introduce that PluginAwareInterface for ZF3 and until then, I would like to mark the EventsCapableInterface usage as deprecated and provide this backport request.

@boesing
The target version is 2.9?

@froschdesign I'm not sure since I did not got into those release processes already. If thats a change for 2.8, I could change the target branch to master

No no, the develop branch is correct!
I looked at the code and thought it is for version 3 and then I saw the deprecation info. A deprecation goes in the next minor release.

I guess this PR is ready to merge now @froschdesign, would be great if you drop the WIP label. Thanks.

I really could need this PR in my latest project boesing/zend-cache-redis-cluster as I want to work with that PluginCapableInterface::getPluginRegistry to determine search for the serializer plugin.
I guess anything is on hold until we have more news about laminas?

This repository has been closed and moved to laminas/laminas-cache; a new issue has been opened at https://github.com/laminas/laminas-cache/issues/2.

This repository has been moved to laminas/laminas-cache. If you feel that this patch is still relevant, please re-open against that repository, and reference this issue. To re-open, we suggest the following workflow:

Squash all commits in your branch (git rebase -i origin/{branch})
Make a note of all changed files (`git diff --name-only origin/{branch}...HEAD
Run the laminas/laminas-migration tool on the code.
Clone laminas/laminas-cache to another directory.
Copy the files from the second bullet point to the clone of laminas/laminas-cache.
In your clone of laminas/laminas-cache, commit the files, push to your fork, and open the new PR.
We will be providing tooling via laminas/laminas-migration soon to help  automate the process.


configuring-a-workflow-in-studio-pro-for-the-employee-onboarding-process

Please use the form below, leaving the prefilled data to help us. Thank you.
Page link: configuring-a-workflow-in-studio-pro-for-the-employee-onboarding-process
Document link: workflow-how-to-configure.md
My Issue/Suggestion

Chapter 3.1 point# 6. The picture is showing a WorkflowAdministrator user role. This does not exist
Chapter 3.2 steps 6/7 should not repeat the exact same steps as for demo_facilities as they should not be linked to the Facilities User Role, but to their respective user roles Manager and HR

Thanks for the feedback! I've adressed all the feedback in the same PR: https://github.com/mendix/docs/pull/8439/files.


feat: add new error handler func with context parm

Add ErrorHandlerWithContext func to options. If both ErrorHandler and ErrorHandlerWithContext are set the later takes precedence.
Shows alternative fix for https://github.com/oapi-codegen/nethttp-middleware/issues/11

@pebo — See any reason it should be limited to r.Context and not instead just pass in r?
I came here today because I need access to r.URL and r.Method so I can determine what content type I should return for the response.

@pebo — See any reason it should be limited to r.Context and not instead just pass in r?
I came here today because I need access to r.URL and r.Method so I can determine what content type I should return for the response.
Also, come to think of it, validateRequest(r *http.Request, router routers.Router, options *Options) should really also return the route that it matches, and then pass that to the error handler as well. Otherwise I'll have to maintain hard-coded information in my custom error handler that is already in openapi.yaml` file and should really only need to be here.
Would love to hear from the project owner if they will consider these or not.

I just needed the context and IIRC this is how the other middlewares worked. As for project owner, @jamietanna any chance this could be considered?


output PT format

Hi Rinongal, first of all many thanks for your amazing repo :)
I assume that generated .pt models under output/checkpoint folder are also in Pytorch Rosinality format, is it correct?
Is there any way to transform them into "standard" Pytorch or Tensorflow format?
Thanks again and sorry if it's off-topic
S.

They are indeed in Pytorch Rosinality format, and unfortunately I'm not aware of a good way to convert them back.
However, if you're willing to do a bit of code-work, you can use the StyleGAN3 branch which I believe should be able to support StyleGAN2 and StyleGAN-ADA pkls with minor changes.
Let me know if you're willing to dive into that and I'll be happy to chat and tell you what needs to be changed (or if you want to wait, I can try getting around to it towards the end of November).

Hi, the thing is I have some tools that uses either tensorflow or standard pytorch format, and I was praying to use them with nada-generated stuff for a project I'm working on :) . Many thanks, I'll keep an eye to your repo.

To anyone stumbling across this issue, this repo has a tool for converting rosinality checkpoints back to an official .pkl format.

To anyone stumbling across this issue, this repo has a tool for converting rosinality checkpoints back to an official .pkl format.


Correct button behaviour

Add pinMode(0, INPUT_PULLUP);
Add checkbox that one can use the button as a switch

closed #84


confirmation: only Adam optim is implemented at this time

based on the code:
https://github.com/thumt/THUMT/blob/81b16687b7ddd0a194a3acc2b5f026768afc6492/thumt/bin/trainer.py#L341
I remember there are others in the older version?

The Theano version of THUMT can use other optimizers. The TensorFlow version only support Adam optimizer. However, you can use other optimizers by change the name of Optimizer (For example, AdamOptimizer -> AdadeltaOptimizer)


Add first stab at FAQ

Add some client documentation, and things that I discovered when setting up LXD, and referenced in issue #5541

This pull request didn't trigger Jenkins as its author isn't in the whitelist.
An organization member must perform one of the following:

To have this branch tested by Jenkins, use the "ok to test" command.
To have a one time test done, use the "test this please" command.

Those commands are simple Github comments of the format: "jenkins: COMMAND"


Does Handoff also have links out to our Storybook?

Hi David!
Apologies for the radio silence, we've been really busy prepping a new release. We're rolling out a Figma plugin to streamline the component schema part of the workflow.
To answer your question, the documentation site is based on NextJS and fully customizable, you can link to anything you want. Of course, you can use the tokens in your Storybook implementation.
We don't use Storybook ourselves but it would be really cool if we could meaningfully integrate with that part of the ecosystem. One idea we've been chatting about was supporting the Component Story Format in the docs, something like Ladle does. Let me know if you have any thoughts on what you'd like to see.


Any plans for support for Digitalocean?

At the moment AWS is hard-wired in. An example digitalocean droplet terraform state file the values are slightly different (in terms of IP address etc..) e.g. -
 "digitalocean_droplet.test": {
                    "type": "digitalocean_droplet",
                    "primary": {
                        "id": "4597742",
                        "attributes": {
                            "id": "4597742",
                            "image": "11137507",
                            "ipv4_address": "<IP_ADDRESS>",
                            "locked": "false",
                            "name": "test-0",
                            "region": "lon1",
                            "size": "512mb",
                            "ssh_keys.#": "1",
                            "ssh_keys.0": "54:0r:91:05:db:b7:7f:47:ba:3b:w2:7e:8u:dc:5d:45",
                            "status": "active"
                        }
                    }
                }

Thanks for raising this. I should be clearer in the README that only AWS is currently supported. I don't have any immediate plans to add support for other providers, but I do consider it a bug. It should be reasonably simple to fix, if you're interested in doing so.

Update: v0.4 includes DigitalOcean support.


mgmt, appplatform support Storage

Description
Step 1 of supporting custom persistent storage in https://github.com/Azure/azure-sdk-for-java/issues/28776

Step:

Support CRUD Spring Cloud Storage.
Support attaching Spring Storage to Spring App as the custom persistent storage.

Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

API change check for com.azure.resourcemanager:azure-resourcemanager-appplatform
API changes have been detected in com.azure.resourcemanager:azure-resourcemanager-appplatform. You can review API changes here

Close due to https://github.com/Azure/azure-sdk-for-java/issues/28776#issuecomment-1123220532


Some analyzer ignore are not working anymore on 1.20.0

Hello!
I updated my SDK version from 1.17.3 to 1.20.0 and these ignore are not working anymore:
// ignore: undefined_prefixed_name
ui.platformViewRegistry.registerViewFactory(viewType, (int viewId) {

// ignore: uri_does_not_exist
import 'dart:web_audio';

// ignore: undefined_method
static final audioContext = AudioContext();

Ex:

Target of URI doesn't exist: 'dart:web_audio'.
Try creating the file referenced by the URI, or Try using a URI for a file that does exist. dart(uri_does_not_exist)

The ignore is for the right error.
Other ignores are working as expected. Reverted to 1.17.3 to be sure and they are working.
If I add the error like this in analysis_options.yaml, it stops showing the error in VS Code:
errors:
        uri_does_not_exist: ignore

But if I add the file in exclude like this in analysis_options.yaml, the error is still there in VS Code:
analyzer:
    exclude:
        - lib/managers/sound/data/sound_web.dart

Although running flutter analyze ignores it correctly.
Flutter doctor:
[√] Flutter (Channel unknown, 1.20.0, on Microsoft Windows [Version 10.0.18363.959], locale en-US)
    • Flutter version 1.20.0 at C:\dev\flutter
    • Framework revision 840c9205b3 (7 days ago), 2020-08-04 20:55:12 -0700
    • Engine revision c8e3b94853
    • Dart version 2.9.0

[X] Android toolchain - develop for Android devices
    X Unable to locate Android SDK.
      Install Android Studio from: https://developer.android.com/studio/index.html
      On first launch it will assist you in installing the Android SDK components.
      (or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed instructions).
      If the Android SDK has been installed to a custom location, set ANDROID_SDK_ROOT to that location.
      You may also want to add it to your PATH environment variable.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed instructions).

[√] VS Code (version 1.47.3)
    • VS Code at C:\Users\Obs\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.13.2

[√] Connected device (3 available)
    • Web Server (web) • web-server • web-javascript • Flutter Tools
    • Chrome (web)     • chrome     • web-javascript • Google Chrome 84.0.4147.105
    • Edge (web)       • edge       • web-javascript • Microsoft Edge 84.0.522.52

I can reproduce this on the latest master 1.21.0-8.0.pre.176 and can't on 1.17.5 but it seems to be intended.

Minimal reproducible code sample
import 'package:flutter/material.dart';

// ignore: unused_import
import 'package:flutter/services.dart/';

// ignore: uri_does_not_exist
import 'aaaaaaaaaaaaaaaaaaaa';

void main() {
  runApp(Container());
}

flutter doctor -v
[√] Flutter (Channel master, 1.21.0-8.0.pre.176, on Microsoft Windows [Version 10.0.19041.388], locale en-US)
    • Flutter version 1.21.0-8.0.pre.176 at C:\Development\flutter_master
    • Framework revision d9637ed784 (3 hours ago), 2020-08-11 23:51:03 -0400
    • Engine revision 6381b1511b
    • Dart version 2.10.0 (build 2.10.0-11.0.dev)

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.1)
    • Android SDK at C:\Users\marku\AppData\Local\Android\sdk
    • Platform android-30, build-tools 30.0.1
    • Java binary at: C:\Users\marku\AppData\Local\JetBrains\Toolbox\apps\AndroidStudio\ch-0\193.6626763\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.6.5)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
    • Visual Studio Community 2019 version 16.6.30320.27
    • Windows 10 SDK version 10.0.18362.0

[√] Android Studio (version 4.0)
    • Android Studio at C:\Users\marku\AppData\Local\JetBrains\Toolbox\apps\AndroidStudio\ch-0\193.6626763
    • Flutter plugin version 47.1.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)

[√] Connected device (4 available)
    • SM G950F (mobile) • ce12171c51cc001c03 • android-arm64  • Android 9 (API 28)
    • Windows (desktop) • windows            • windows-x64    • Microsoft Windows [Version 10.0.19041.388]
    • Web Server (web)  • web-server         • web-javascript • Flutter Tools
    • Chrome (web)      • chrome             • web-javascript • Google Chrome 84.0.4147.105

• No issues found!

Logs
On latest master
C:\Users\marku\Desktop\triage\master>flm analyze
Analyzing master...

  error - Target of URI doesn't exist: 'aaaaaaaaaaaaaaaaaaaa' - lib\main.dart:7:8 - uri_does_not_exist

1 issue found. (ran in 1.3s)

On 1.17.5
C:\Users\marku\Desktop\triage\stable17>fl17 analyze
Analyzing stable17...
No issues found! (ran in 1.1s)

dart.dev states that

Version note: As of Dart 2.8, you can’t stop error rules from being applied to individual files or lines of code.

but the version for 1.17.5 is 2.8.4 so it shouldn't have worked there either?
C:\Users\marku\Desktop\triage\stable17>fl17 --version
Flutter 1.17.5 • channel unknown • unknown source
Framework • revision 8af6b2f038 (6 weeks ago) • 2020-06-30 12:53:55 -0700
Engine • revision ee76268252
Tools • Dart 2.8.4

Maybe this was deprecated as it should have been at some point but I'll leave it open for clarification in case I'm mistaken. Feel free to close if this is working as intended.

Same problem here. flutter doctor output:
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel beta, 1.20.0, on Mac OS X 10.14.6 18G103, locale en-US)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 11.3.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 4.0)
[✓] VS Code (version 1.48.0)
[✓] Connected device (3 available)

I think this is the same as upstream issue https://github.com/dart-lang/sdk/issues/42977

You're right, closing this issue as a duplicate.


KHR_node_visibility

Adding the implementation of KHR_node_visibilityAs per specs in this PR - https://github.com/KhronosGroup/glTF/pull/2410
Vis test added to make sure we support the current specs.

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/15754/merge
Test environment:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15754/merge/index.html
To test a playground add it to the URL, for example:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15754/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/15754/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/15754/merge
https://gui.babylonjs.com/?snapshot=refs/pull/15754/merge
https://nme.babylonjs.com/?snapshot=refs/pull/15754/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/15754/merge#BCU1XR#0

Visualization tests for WebGPU (Experimental)
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15754/merge/testResults/webgpuplaywright/index.html

WebGL2 visualization test reporter:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15754/merge/testResults/webgl2playwright/index.html

This new extension should be added to packages/dev/loaders/src/glTF/2.0/Extensions/dynamic.ts as well.


Change the SendAll method parameter to take a ICollection instead of List

From the source, it doesn't seem there would be any detriment to changing this and would allow arrays and dict keys to be used directly.
public void SendAll(ICollection<int> connectionIds, ArraySegment<byte> source)
        {
            ArrayBuffer buffer = bufferPool.Take(source.Count);
            buffer.CopyFrom(source);
            buffer.SetReleasesRequired(connectionIds.Count);

            // make copy of array before for each, data sent to each client is the same
            foreach (int id in connectionIds)
                server.Send(id, buffer);
        }

You're right, I didn't think of allocations because my use case isn't as affected by it. I agree, a second method would be most useful then to preserve the original better method but still allow for others, thanks!
I thought of IEnumerable but then the Count would be through linq

added it here: https://github.com/James-Frowen/SimpleWebTransport/commit/28b6b25f7c1bf26cef04f5bae25377b485eec1ae

Awesome, thanks!


fix(rtc_interface): fix name space

Signed-off-by: Fumiya Watanabe<EMAIL_ADDRESS>Description
Before this change, no_stopping_area does not send RTC status because of the limitation of the character of name space.
In this PR, I change the name space of RTC status and commands.
Before:
/planning/scenario_planning/lane_driving/behavior_planning/behavior_**_planner/**/cooperate_status
/planning/scenario_planning/lane_driving/behavior_planning/behavior_**_planner/**/cooperate_commands

After:
/planning/cooperate_status/**
/planning/cooperate_commands/**

Change for api is following.
https://github.com/tier4/tier4_ad_api_adaptor/pull/61

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

cc. @0x126


Option to add a delay to the last frame

Currently, the generated GIF cycles rapidly, meaning the final output is hard to be able to read.
It would be useful if there could be a delay at the end, so that the results may be seen before the GIF loops.
This can be done with imagemagick with the following command, to set an e.g. 5 second delay.
convert $name.gif '(' -clone 0  ')' -swap 0 +delete '(' +clone -set delay 500 ')' +swap +delete $name-delay.gif

It would be nice to offer this as an option in asciicast2gif.

Closing as asciicast2gif is dead. Try https://github.com/asciinema/agg instead. agg doesn't support this yet but adding an option for this makes a lot of sense 👍


Changed the base image in the Dockerfile to be the same as ko

This makes the local development image the same as the production one, avoiding the cert errors that appeared with scratch.
Ideally we should be able to just use ko locally and avoid the need for a Dockerfile altogether. I haven't had a chance to look into this yet but there are flags like -L to the ko build command that might work.

should this use distroless.dev/static:latest? I think that's what ko defaults to now.

should this use distroless.dev/static:latest? I think that's what ko defaults to now.

According to the docs, this is the default. Where did you find that distroless.dev/static:latest is the default?

https://github.com/ko-build/ko/blob/7dc51c0cf6db4346bfbe98b82e1c3ea0eb5e4bd3/pkg/commands/options/build.go#L35
I think the docs are out of date. @imjasonh FYI

The docs are out of date, as of v0.12 the default base image is cgr.dev/chainguard/static:latest (equivalent to distroless.dev/static:latest)
https://github.com/ko-build/ko/pull/903

Thanks @patflynn and @imjasonh. Has the base image been changed often? If so we might as well remove the Dockerfile now.

The base image has changed exactly once ever, from gcr distroless to distroless.dev, then in name only to the equivalent cgr.dev/chainguard image.
I don't expect it will change again, at least not soon.


Bk

The idea was to keep all content in the bk branch (we have a few direct URLs in the book, and this kept them short enough to fit!); and therefore (to avoid any confusion) have nothing but the readme in the master branch. But let me know if that is causing a problem.  (Was there anything else in this commit, other than copying "bk" to "master"?)

Pending some problem  (with keeping all code and datasets in "bk" branch), I'm closing this.


An option to restore outputs cache without merging

Which project is this feature idea for?
Turborepo
Describe the feature you'd like to request
I have found that turborepo actually merges files when restores outputs caches. In some cases this may lead to a buggy behavior.
For example, I have these tasks:
{
  "pipeline": {
    "build": {
      "inputs": ["src/**"],
      "outputs": ["build/**"]
    }.
    "test": {
      "dependsOn": ["build"]
    }
  }
}

When build is executed, it initiates an sqlite database:
build/.sqlite

Turborepo caches it for me.
Then I run test and this does some interactions with the database which change the database files:
build/.sqlite // changed
build/.sqlite-shm // created
build/.sqlite-wal // created

Then I do changes to the tests and rerun test. Turborepo checks caches for build task. It sees that src/** haven't changed. So it restores the outputs from the cache:
build/.sqlite // restored from cache
build/.sqlite-shm // left untouched
build/.sqlite-wal // left untouched

The result is a broken database 😢
(This is a real-world example. I had to create an ugly workaround to make things work: https://github.com/AmazeeLabs/silverback-template/commit/cc7545f0a351e1a3daa35c75fc790ef9191c02ca)
Describe the solution you'd like
I would like Turborepo to restore outputs cache without merging. So for my case above, when I run test for the second time, I'd like build/.sqlite-* files to be removed once the build cache is restored. Basically, I need the whole build directory to be replaced from the cache.
But I understand that this would be quite a big change in Turborepo behavior. So maybe it can be an option? E.g. strictOutputs: true or something like that.
Describe alternatives you've considered

Don't create a new option. Make the no-merge behavior default.
Implement the no-merge behavior for directories configured without globs. So "outputs": ["build/**"] will still merge the directory contents, but "outputs": ["build"] will replace the directory.

This is a good question, I'll ask the team.

Hey @Leksat , we talked about this at the team meeting and decided not to provide this feature. One immediate issue is that it could only really work in the case where your output glob is configured to build/**. If instead you've specified build/**/*.js, we wouldn't be able to delete the entire directory (and matching the files to delete would create even more confusing behavior).
For now, we believe this makes more sense to handle in user-land since you ultimately understand what your scripts do better than us. Thanks for filing and apologies for not being able to help more!

If this comes up again, I'd vote for

Describe alternatives you've considered

Don't create a new option. Make the no-merge behavior default.
Implement the no-merge behavior for directories configured without globs. So "outputs": ["build/**"] will still merge the directory contents, but "outputs": ["build"] will replace the directory.

Because TIL that "outputs": ["build"] caches the build dir without contents 😅

I also think that, caching a directory without contents and than merging an empty directory with whatever is there, feels counter-intuitive. Adding a directory without wildcards should trigger a warning at least.
Clearing the directory before restoring it to avoid merging issues can be solved with an additional step, but it makes the turbo configuration even more complex, and in some cases its hard to grasp already. To me @Leksat 's suggestion alternative "2" feels very intuitive for both cases.


[trim] vkUpdateDescriptorSetTemplate path needs refinement

From issue #1375, a change was added to properly track and record the accelerator data if used in a call to vkUpdateDescriptorSetTemplate.  This is done for now by writing out pNext data of an accelerator structure which matches the way the other descriptor set data is currently saved for this entrypoint.
This entrypoint should properly record the tracking data without the pNext data hack to more closely reproduce the original intent of the capture.
You can reproduce this on Linux (although it happens on other platforms) using my fork of Sascha Willem's Vulkan examples. using the branch marky_move_raytrace_reflect_to_desc_templates.  Building this will produce a raytracingreflectionsdesctemplates sample which can be recorded and trimmed and then replayed.  Without the fix in #1375 it crashes, so when updating the source to properly fix this issue, run that sample and make sure a trimmed capture does not crash.

@fabian-lunarg want to take a crack at this?  I think it will mean reading through the existing code for tracking and descriptor set templates.  Please talk with @MarkY-LunarG if there is context you think you need that is missing.

sounds good, will do :)


KARAF-5849: Update version of pax transx to 0.4.0

@jbonofre : This fixes several bugs would be nice to have it in 4.2.1, yet.

@graben Thanks ! It sounds good. Let me do the review.

retest this please


Recreate RFC 6350 in the new AsciiDoc format

From original REQUIREMENTS.adoc. @ronaldtse , please confirm this is still expected.

No longer necessary. We’ve already got a better example.

Actually, it’d be great to have a long example like this to exercise our code... how long do you think it’ll take to convert this?

(An actual RFC not an internet draft)

Hm. 3-4 hrs?

Let's do it 👍 Hope to make the flow work also for a published RFC.

Converted text; had some nifty nesting of definition lists.
Have not yet converted references.

Thanks @opoudjis , it would be great if we could compare the generated RFC text (through xml2rfc) against the published one (we can include it in the /spec folder) so we know it is entirely (mostly) the same.

I will be doing an XML comparison with both this and #38. With xml2rfc, you're proposing a comparison of target formats from the two as well. OK, cool; do you want comparison of the HTML, or the TXT?

Probably the HTML will catch more, but the TXT version will already tell us a lot. Let's first do TXT then HTML output comparison. For example in #59 a diff was run against the generated TXTs and found a number of issues.

I've done this, using the asciidoctor-bibliography gem. In order to do the TXT comparison, I am stripping out the page separations: it is impossible to get the pagination to aline, and I strongly suspect that the online RFC 6350 text file had manual line breaks inserted. There are also some occasional inexplicable variations in paragraph width, and hyphens do not seem to break at lines in the original. But after a lot of work, if we ignore line breaks, the texts do line up, and I have added RFC 6350 to the rspec.
(The comparison of text output in general does not do well under rspec, because of differences in line breaks, but they are still very useful as examples.)
Having reconstructed the markup of 6350, btw, I am somewhat disappointed with how unadventurous it was originally; I would have used a lot more monospace, for example (which gets rendered as quotes in xml2rfc txt). The extensive definition lists now render correctly. Most tables align well, though one large table towards the end ends up with different table widths.


MudListItem and MudMenuItem: Render as anchor with"Href" property (#1717)

Description
fixes #1717
MudElement is used to render a MudListItem either using a div or an a element to render the item.
This way a list and or menu item with an Href can be opened in a new browser tab using the right click menu.
MudElement had to be modified the ClickPropagation property was depending on the HtmlTag value, this logic was moved to
the MudBaseButton.
How Has This Been Tested?

unit tests have been added
visually

Types of changes

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[X] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

[X] The PR is submitted to the correct branch (dev).
[X] My code follows the code style of this project.
[X] I've added relevant tests.

The breaking change is in my opinion minor as it concerns MudElement with the ClickPropagation property not having internal logic.

Another thing that I would like to discuss here.
What is the intended behaviour when both Href and OnClick handlers are present. I think the behaviour should be consistent across all components.
From my understanding, if Href is set the OnClick should not be called. But this decision imposes some troubles. It is for example not easily possible to add an MenuClose handler to inner MudListItem.
It  even gets more complex, if we add an Target attribute (e.g. _blank) and or a ForceLoad parameter. What is the expected behaviour for a disabled button/item with an href. Should the Href then also be disabled, by forcing a render as button tag.
For my expectation it would be best to always call the OnClick handler. That might close a menu and Browser client can do a navigation (even to a new tab) -- then the close menu is desired.
I think it is quite important to have a discussion on this intended behaviour, to get a consistent design!
My Pull-Request tried to solve the problem of #1717, but it seems there are more thoughts required!

Sorry, I think my PR https://github.com/MudBlazor/MudBlazor/pull/8634 added conflicts to your PR, since I did method renaming, so was the tests affected too.

I've merged with dev and kept the meaning of MudElements ClickPropagation Parameter.

What is the intended behaviour when both Href and OnClick handlers are present. I think the behaviour should be consistent
From my understanding, if Href is set the OnClick should not be called. But this decision imposes some troubles. It is for example not easily possible to add an MenuClose handler to inner MudListItem. It even gets more complex, if we add an Target attribute (e.g. _blank) and or a ForceLoad parameter. What is the expected behaviour for a disabled button/item with an href. Should the Href then also be disabled, by forcing a render as button tag.
For my expectation it would be best to always call the OnClick handler. That might close a menu and Browser client can do a navigation (even to a new tab) -- then the close menu is desired.
I think it is quite important to have a discussion on this intended behaviour, to get a consistent design!

I agree that calling the OnClick handler regardless of the Href value (except if Disabled is true) makes sense. If I attach a click handler I expect it to fire. If I want to just navigate I don't attach the handler, right?

I agree that calling the OnClick handler regardless of the Href value (except if Disabled is true) makes sense. If I attach a click handler I expect it to fire. If I want to just navigate I don't attach the handler, right?

@henon Isn't it a problem that several other controls do it the other way?

@belucha Please resolve conflicts. What's the status? We should get this done for v7

@henon I've just resolved all conflicts.
@danielchalmers I also considered  your suggestions, except on regarding the rename of MudElement.ClickPropagation. I left that unchanged, since this was the original API and the the difference between OnClickPropagation and ClickPropagation is quite little.

Thanks!

@henon  Thanks to you and the others for the great work on this lib!

Added to v7.0.0 Migration Guide #8447

@henon
I'm so sorry, I found an issue in the code just now, that was not my intention and I somehow missed it.
in MudBaseButton.cs there is a property:
        public bool ApplyClickPropagation => HtmlTag != "button" || ClickPropagation;

this should be private and matching to your convention:
        private bool GetClickPropagation() => HtmlTag != "button" || ClickPropagation;

Do you wan't me to open a new pull request, or do you change that yourself?
Sorry for this mistake.

Don't worry, I am fixing it myself.

After going through this PR again, I noticed that it was requested to add XML documentation for this property: https://github.com/MudBlazor/MudBlazor/pull/8649#discussion_r1567828070.
However, it's missing:
https://github.com/MudBlazor/MudBlazor/blob/38782f5d83c481333526370ca274d8e45e389b32/src/MudBlazor/Components/Menu/MudMenuItem.razor.cs#L42-L46
Additionally, there is an extra new line and a missing new line after the property.
@belucha, can you please make a PR to fix it?

Sure. I'm sorry if I missed that. I will do so in about two weeks.

Sure. I'm sorry if I missed that. I will do so in about two weeks.

Fixed already https://github.com/MudBlazor/MudBlazor/pull/9387
But if something is missing, feel free to PR.


••• Rare testing links for Refined GitHub •••

If you find some rare pages on GitHub that would be useful when implementing new features, post them here.
Tags: unique test examples oddballs
PR with 250 files
https://github.com/DefinitelyTyped/DefinitelyTyped/pull/34748/files
TypeScript file with 18K lines
https://github.com/Microsoft/TypeScript/blob/master/lib/lib.dom.d.ts
Issues opened via apps
https://github.com/dotnet/docs/issues/10085

Readme file in subfolder
https://github.com/davidbailey/tum/tree/master/handbook#readme

Multiple pages of labels
https://github.com/sourcegraph/sourcegraph/labels?page=7&sort=name-asc


Test against Test ROMS

https://github.com/retrio/gb-test-roms
https://github.com/Emu-Docs/Emu-Docs/tree/master/Game Boy/test_roms

[ ] cgb_sound
[ ] cpu_instrs
[ ] dmg_sound
[ ] instr_timing
[ ] interrupt_timing
[ ] mem_timing
[ ] mem_timing-2
[ ] oam_bug

This can now be automated since getting a screen hash is possible

Added a test runner process to run ROMs that print the output at the terminal. Seems like not all test ROMs are making use of the serial port. Right now three test ROMs can be run using CI.


Not Getting updated Deployment appearing in Browser after Refresh.

Describe the bug
I have setup deployments with Amplify Console. I have multiple Apps to the same branch so they all update and I can manage seperate domains with seperate environment variables (maintaining domain assets)
When I merge to a Bitbucket branch, it goes through the process to build and deploy.
After completion, I got to the site, Hit Ctrl+R to refresh but it appears still that I'm pulling from a cache as it's not updating to the latest version I just deployed.
To Reproduce
Steps to reproduce the behavior:

Go to Bicketbucket
Click on 'Merge' in Pull request
Wait for Deployment to all go Green
Click on URL link under App image
Open Page and click Ctrl+R

Expected behavior
I thought the Console was updated so as to cause a forced refresh of the CDN. This would mean the Refresh would pull the new Vue application down from Bucket.
Additional context
I have noticed that it can be out of sync across multiple computers.

Do you have a service worker running in your app? Try opening the URL in incognito..

You can also try to open the browser console -> network tab, and verify where the response come from.


content string not rendered properly

Describe the bug
Ok, maybe that's also a bug that happens because of my shadow dom. But when I give an initial value to the content property, the html and the styling is not right.

System (please complete the following information):

mui-tiptap version: 1.8.5
tiptap version: 2.1.12
Browser: chrome
OS: win11

Additional context
BTW great work you're doing, the best looking and working editor I've seen so far...

@simon-schuster44 I'm not very familiar with utilizing React components (or mui-tiptap) with the shadow dom. Would you be able to provide a CodeSandbox (I recommend forking the one linked from the README) so I can see the full code used in the above example and take a look?
Side note in case it's the cause of your issue: if you do not include all of the relevant extensions in your editor's extensions array, Tiptap will remove unrecognized markup. For instance, in your example, you need to ensure that Color, FontFamily, Highlight, and TextStyle (used by color and font-family) are all included in the extensions array.
If this turns out to be a more general problem with Tiptap itself and not specific to mui-tiptap, I'd recommend filing an issue here https://github.com/ueberdosis/tiptap.

Hey, thanks for the quick response. I've created a Sandbox with a part of my current Project. Unfortunately (for me, not for you ) the Sandbox seems to run just fine, so I'll close this issue and search in my code for errors. I'll come back if I should run into an error again. And again, great work you're doing!
https://codesandbox.io/s/heuristic-lumiere-9qv4zl?file=/src/Editor.tsx:1029-1039

Maybe one last addition, because I'm really struggling right now... It seems as if the Color picker opens onClick and immediately closes again. have you ever had that issue or maybe know what could cause it?

Okay, I appreciate you following up! And thanks for the kind words and for using mui-tiptap!


Mantine

I'd like to replace Tailwind and the slew of custom components for using Mantine.
Phase 1

[ ] Remove Tailwind, autoprefixer, and postcss packages
[ ] Remove global CSS
[ ] Remove all Tailwind markup in HTML

Phase 2

[ ] Install Mantine
[ ] Refactor both app.tsx and _document.tsx to instantiate Mantine

Phase 3

[ ] Replace or refactor custom components and pages to use Mantine components
[ ] Test all the things

Could you please assign me to this ticket?

Have you made a start on this @gregrickaby?    Happy to help.

@leonlafa I have. Just haven't pushed my branch yet (but will today).
If there's anything else you see (either issues or in the codebase itself) feel free to tackle it!

@leonlafa I've got the initial work up here and Mantine is configured.
Feel free to jump in and begin work on Phase 3 items!

@leonlafa Good morning!
I'm 100% onboard with using default Mantine components/styling with light tweaks using createStyles() here and there.
It looks like you and I are on the same page, because screencast looks like https://ui.mantine.dev/category/headers#header-menu (which is exactly what I was thinking of using). So far I've got the provider and <Layout /> component scaffolded. This should clear the way for putting in Mantine components today!
I've been pushing to this branch https://github.com/gregrickaby/nextjs-wordpress/tree/feature/%2326-mantine, and now that you're a collaborator (💪🏻 ) you should be able to commit and push to that one too.
While you work on components, I'm going to refactor the <CommentForm> to use Mantine's form workflow.
Thanks again for all the help!!!


Indention glitches for long sections

Hi, first of all - thank you for this amazing plugin! It literally changed the way I use the Obsidian and amazing work!
I have noticed a bug when scrolling through the longer section of a heading. When given heading is very long (expands below the screen space), it starts glitching when the user is scrolling further (indention is changing). I'm uploading a video showing the problem here. Your help with resolving of this issue would be greatly appreciated.
PS. any news regarding the implementation of this feature into the Live Preview mode? Can't wait to see this happening!
Thanks :)

This happens with all my docs. I know you're just one person... I wish the Obsidian team would implement this as a core feature.

I am having the same issue, has this been addressed yet?  if not can it be bumped up the list a bit :)

I am having the same issue, has this been addressed yet? if not can it be bumped up the list a bit :)

Instead of using the plugin, I modified the css

I am having the same issue, has this been addressed yet? if not can it be bumped up the list a bit :)

Instead of using the plugin, I modified the css

Interesting. How would I go about that? What do I need to put in?

Download my css: https://github.com/jerviscui/Example.Obsidian/blob/main/文件夹/.obsidian/snippets/editor-reading-mode-color.css
Then in the Obsidian css snippet enable it.

I was using the debug tools and noticed that the classes for headers and the following div tags are dynamicaly changed.  So just before the larger text is changed I can see the margins set, but when you move past the threashold where everthing left aligns again, the classes are dynamicaly changed with no margins.  Just thought this would help in troubleshooting.

indentation in preview mode is a little bit optimized. If you want test it, u can download the latest release with BRAT, specifing version the 2.0.0 version
Also now there is support for editing mode, i for example do not use reading mode anymore

I just downloaded the manifest and main and replaced them in my plugins directory overtop the ones there
It still has the same behavior in reading mode where if it’s a long entry under a heading half way down its starts to left align not honoring the indent anymore on that heading.
also is there a way to adjust the text under a heading to line up with the heading instead of indenting that as well

It still has the same behavior in reading mode where if it’s a long entry under a heading half way down its starts to left align not honoring the indent anymore on that heading.

this bug still present in reading mode, but not in editing XD. the only thing was donde in reading is speed up a little bit the indent itself

also is there a way to adjust the text under a heading to line up with the heading instead of indenting that as well

in reading mode this kind of indent you can do with just a css. Maybe ill make a option in settings that will do this instead. Just didn't know somebody prefer this way of indent

Ok cool I didn’t know if editing and reading mode behave the same as far as rendering div tags like I and @jerviscui mentioned.
I have tried a lot of different css and couldn’t get that to work at all this plugin has made it a lot easier
Also thanks for considering adding the extra indent.  That will be exciting.

Ok cool I didn’t know if editing and reading mode behave the same as far as rendering div tags like I and @jerviscui mentioned.

also they behave completely different. editing mode is embedded codemirror editor with batteries, while reading mode is purely obsidian feature where all stuff is rendered into "sections". In reading mode its easy to apply any styles. The problem is that the content under this "sections" lacks of anything that points out about which heading is come after. So the way this plugin identify the heading of the content is adding classes to the content sections so you can also set your own css. This classes are added on-the-fly based on current viewport, so if the content under a heading is huge, it losses the last heading from the viewport and the plugin eats some shit as this issue point out. The reason why is done this way is that in editing mode the content lacks of this information as well, so we cannot "transfer" this information in rendering of reading view, as other plugin does. But with editing mode support i think it is possible so when it will be done i'll give it a try and maybe no more on-the-fly shit will be needed
also, meanwhile you can solve current issue using live-preview if you dont care about the other bugs on editing mode that are not solved yet

Thanks for the info, I use two modes, edit and read.  I only use the edit mode to make modifications to the content.  everthing esle I use my notes for is in reading mode.  Hopefully you can find a solution to this, if you need me to test anything let me know

I have tried a lot of different css and couldn’t get that to work at all

did u tried this css snippet? is working on both modes well, i just found out

I tried and the css didn’t work for me. I even turned off and back on your plugin but it still didn’t go.

try disable another snippets and plugins

Maybe it's been caused after spellcheck occurrences.
Try to add this words to dictionary and check if it fix your notes.
I open another issue detailing it: https://github.com/svonjoi/obsidian-heading-level-indent/issues/21


Linter forcing me not to declare a Type in valid Typescript code

Bug Report

TSLint version: 3.15.1
TypeScript version: 2.0.3
Running TSLint via: Node.js in the package.json file as a script

TypeScript code being linted
let myBool: boolean = true;

with tslint.json configuration:
{
  "rules": {
    "class-name": true,
    "comment-format": [
      true,
      "check-space"
    ],
    "curly": true,
    "eofline": true,
    "forin": true,
    "indent": [
      true,
      "spaces"
    ],
    "label-position": true,
    "label-undefined": true,
    "max-line-length": [
      true,
      140
    ],
    "member-access": false,
    "member-ordering": [
      true,
      "static-before-instance",
      "variables-before-functions"
    ],
    "no-arg": true,
    "no-bitwise": true,
    "no-console": [
      true,
      "debug",
      "info",
      "time",
      "timeEnd",
      "trace"
    ],
    "no-construct": true,
    "no-debugger": true,
    "no-duplicate-key": true,
    "no-duplicate-variable": true,
    "no-empty": false,
    "no-eval": true,
    "no-inferrable-types": true,
    "no-shadowed-variable": true,
    "no-string-literal": false,
    "no-switch-case-fall-through": true,
    "no-trailing-whitespace": true,
    "no-unused-expression": true,
    "no-unused-variable": true,
    "no-unreachable": true,
    "no-use-before-declare": true,
    "no-var-keyword": true,
    "object-literal-sort-keys": false,
    "one-line": [
      true,
      "check-open-brace",
      "check-catch",
      "check-else",
      "check-whitespace"
    ],
    "quotemark": [
      true,
      "single"
    ],
    "radix": true,
    "semicolon": [
      "always"
    ],
    "triple-equals": [
      true,
      "allow-null-check"
    ],
    "typedef-whitespace": [
      true,
      {
        "call-signature": "nospace",
        "index-signature": "nospace",
        "parameter": "nospace",
        "property-declaration": "nospace",
        "variable-declaration": "nospace"
      }
    ],
    "variable-name": false,
    "whitespace": [
      true,
      "check-branch",
      "check-decl",
      "check-operator",
      "check-separator",
      "check-type"
    ]
  }
}

Actual behavior
When I have the following Typescript line in a test spec:
let myBool: boolean = true;

the linter complains with:
(no-inferrable-types) app/app.component.spec.ts[39, 17]: LHS type (boolean) inferred by RHS expression, remove type annotation
So I change the code to read:
let myBool = true;

and the error goes away.
Why is this? Shouldn't I be able to write valid Typescript in a spec?
Note this problem does not occur in a regular Typescript class. My spec file seems to transpile just fine.
This doesn't mean to be a nit-picking question: I am just curious.
Thanks.

There is no-inferrable-types in your tslint.json which warns you about such cases with primitives (number, string, boolean).
Just remove it from your configuration ant there will be no warnings.
To make sure that definitions are required you can check typedef rule and add it to your tslint.json

@IllusionMH Thank-you

That REALLY should NOT be a default.

number, string, boolean

There is no-inferrable-types in your tslint.json which warns you about such cases with primitives (number, string, boolean).
Just remove it from your configuration ant there will be no warnings.
To make sure that definitions are required you can check typedef rule and add it to your tslint.json

Just courious to check, if [no-inferrable-types] is removed then it will not warn not only for boolean but also for number, string. Will it be feasible solution?


Bright bottom and left edge when using hybridbackforward

Steps to reproduce:

Open this scene: lighttracing_brightline.zip
Press F12
You should see the attached results

Note: since github uses a bright background, you might have to open the images in a new tab or download them and open them in a program that has dark background so you can spot the bright bottom and right lines.
hybridbackforward enabled:

hybridbackforward disabled:

It happens with Path CPU and Path OpenCL.
Bidir is fine.
Sampler doesn't matter.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I should have fixed the problem.

Thanks!


version bump?

Should the version of the latest commit be bumped?
Otherwise updating it would not work unless i include a force-reinstall flag

ah right yes.


bump swagger parser library version

I guess it also needs a couple of examples with swagger 3 specs...

Unfortunately this seems as though it'll be quite a bit more involved than just bumping a version number -- initially I assumed that would be the case as well, but it seems as though the underlying model representing the swagger format has changed.
diff --git a/modules/codegen/src/main/scala/com/twilio/guardrail/ReadSwagger.scala b/modules/codegen/src/main/scala/com/twilio/guardrail/ReadSwagger.scala
index 30dbcd9..f552941 100644
--- a/modules/codegen/src/main/scala/com/twilio/guardrail/ReadSwagger.scala
+++ b/modules/codegen/src/main/scala/com/twilio/guardrail/ReadSwagger.scala
@@ -2,17 +2,19 @@ package com.twilio.guardrail

-import _root_.io.swagger.models.Swagger
-import _root_.io.swagger.parser._
+import io.swagger.v3.parser.OpenAPIV3Parser
+import io.swagger.v3.oas.models.OpenAPI
 import cats._
 import java.nio.file.Path
 import scala.io.AnsiColor
 import scala.util.Try

-case class ReadSwagger[T](path: Path, next: Swagger => T)
+case class ReadSwagger[T](path: Path, next: OpenAPI => T)
 object ReadSwagger {
   def unsafeReadSwagger[T: Monoid](rs: ReadSwagger[T]): T =
     (for {
       absolutePath <- Try(rs.path.toAbsolutePath.toString).toOption
-      swagger      <- Option(new SwaggerParser().read(absolutePath))
+      swagger      <- Option(new OpenAPIV3Parser().read(absolutePath))
     } yield rs.next(swagger))
       .getOrElse {
         println(s"${AnsiColor.RED}Spec file ${rs.path} is either incorrectly formatted or missing.${AnsiColor.RESET}")

this starts us down the rabbit hole. It seems as though there is a Swagger/OpenAPI2.0 -> OpenAPI3.0 translation layer included with the parser, so we'll still be able to support OpenAPI2.0 specifications, but I haven't given it more than a cursory glance.
Tangentially related, I'd previously done some work towards investigating whether it would be possible to derive a parser from json-schema itself; there have been some challenges with the hand-written parser, primarily around error reporting, which I believe could be solved by simply deriving a parser that was consistently expressive at all levels (I'm thinking errors reported as JSON Paths to exactly where the problem is, instead of Spec file ${rs.path} is either incorrectly formatted or missing..
It seems as though the OpenAPI 3.0 parser has resolved the most frustrating issue, which suggests the underlying implementation has gotten similar treatment, but I still maintain that hand-written parsers will eventually be replaced with something derived from a specification.


Update migrate-tier.md

I would suggest to add as two sections for WAF Policy options under "Prepare for Migration" as two sections, like 1. Use existing WAF Policy for migrated profile 2. Make a new WAF policy for migrated profile, with screenshots as it would help with clarity.

Looks good. Thanks @asukumar22
@duongau - Could you take a look at the feedback in the opening comment?


[AutoPR edgegateway/resource-manager] Update API version, update data contract for Order APIs

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/5191

This PR has been merged into https://github.com/Azure/azure-sdk-for-go/pull/4094


Add pkg-config to the setup for zLinux machines

Currently, we use an extension to remove the need for pkg-config from the OpenJDK on OpenJ9 builds on zLinux. Without that extension, the builds fail.
I understand Ansible Playbooks are used to configure machines for the AdoptOpenJDK Build and Testing pool.
Please configure, or confirm, these playbooks add pkg-config to the zLinux machines.
Thank you.
P.S. Please merge PR https://github.com/ibmruntimes/openj9-openjdk-jdk10/pull/1 once this task is complete. It will be reviewed in advance by another developer, so all you should have to do is merge.

It failed too early, and could not find fontconfig. I notice the ansible playbooks for sles and red hat lack a lot of the packages the Ubuntu one has, so I'm closing this issue and raising one for the package discrepancy.


Incorporate plugins

plugins are here as of Go 1.8. Despite some of the general issues and difficulties with getting plugins to compile using objects shared with the main program, it seems likely that we'll need to do something with them as part of dependency management.
Problem is, I'm not sure much we could really do via static analysis to determine what plugins are necessary. The import names are just strings, and if the focal point during analysis is an individual file in a particular package (with a plugin.Open call site), then the origin of those strings could easily be in a package from an entirely separate project, or generated based on the input to a running program.
If we can't provide any assurances about the completeness of analysis, then it suggests dep should handle plugins - if it does at all - through an entirely different mechanism than typical import-based dependencies. Perhaps explicit declaration in the manifest? I don't know.
In any case, this issue is here for some open discussion on the topic.

I'd save your innovation tokens and pass on plugins, with just over a month
left in the 1.9 dev cycle it doesn't look like the plugin situation is
going to improve for Go 1.9, and that isn't even considering that they're
not enabled on windows or mac.
On Thu, Mar 23, 2017 at 1:41 PM, sam boyer<EMAIL_ADDRESS>wrote:

plugins https://golang.org/pkg/plugin/ are here as of Go 1.8. Despite
some of the general issues and difficulties with getting plugins to
compile using objects shared with the main program
https://groups.google.com/forum/#!topic/golang-nuts/IKh1BqrNoxI, it
seems likely that we'll need to do something with them as part of
dependency management.
Problem is, I'm not sure much we could really do via static analysis to
determine what plugins are necessary. The import names are just strings,
and if the focal point during analysis is an individual file in a
particular package (with a plugin.Open call site), then the origin of
those strings could easily be in a package from an entirely separate
project, or generated based on the input to a running program.
If we can't provide any assurances about the completeness of analysis,
then it suggests dep should handle plugins - if it does at all - through an
entirely different mechanism than typical import-based dependencies.
Perhaps explicit declaration in the manifest? I don't know.
In any case, this issue is here for some open discussion on the topic.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/dep/issues/347, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAcA89Z9_jdjNLEWP2e2-lq-St5fMHLks5rodvkgaJpZM4MmGAJ
.

@davecheney fully agree, this is not a priority. Really just opened it so that there's a place for any thoughts or ideas that might come up as we move along.


Merge commits after 0.29.0 release

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/3058/
Test PASSed.


Use one unified root ca cert to protect exposed core and notary ingresses

What can we help you?

When we enable notary (TLS must be enabled), shall we update the following customization files that are located at config/?

harbor-full/harbor_notary_patch.yaml

apiVersion: goharbor.io/v1alpha2
kind: Harbor
metadata:
  name: sample
spec:
  notary:
    migrationEnabled: true
  expose:
    notary:
      ingress:
        host: notary.harbor.domain
     tls:  // add tls config and share the same root cert with core?
        certificateRef: sample-public-certificate

harbor/https.yaml

apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: sample-public-certificate
spec:
  isCA: false
  issuerRef:
    name: sample-public-certificate
  secretName: sample-public-certificate
  dnsNames:
  - core.harbor.domain
  - notary.harbor.domain # add notary domain here?

cc @holyhope


Decide where the Cupcake content is going to be published

chsanche created the following on Aug 08:
Introduction
There are several options to host the Cupcake content.

Git repo wiki section.
Website built on the Gatsby theme.
Current v19a website.

The problem

One location should be selected to avoid user confusion and address adopter pain points.
One location should be selected to avoid any surprises happened to the planning of resources and timeline for developing the website.

Expected outcomes

The decision of the hosting location that addresses user pain points and considers the potential integration with Carbon

Additional information
This issue is created based on the "Cupcake Website strategy and planning" meeting we had on 08/08.
Original issue: https://github.ibm.com/webstandards/digital-design/issues/1422

On Aug 08, chsanche commented:
FYI - @hahnrob.

On Aug 08, Jeff-Chew commented:
@Wonil-Suh1 Yes, both are based on MD. We don't have a story yet for the Gatsby themed website, but my understanding is that it is relatively quick to get it going. We will need to create stories to get the gatsby themed website up and running.
cc: @hahnrob @linda-carotenuto @chsanche

On Aug 08, Wonil-Suh1 commented:
Definitely not on the current website.
@Jeff-Chew it is my understanding that both Git Wiki and Gatsy theme are based on Markdown - what we publish on Wiki can be lifted and shifted to Gatsby when we have an instance set up - correct?
And do we have a sense of when a Gatsby theme will be available?

On Aug 14, Wonil-Suh1 commented:
Per discussion with Jeff and Roberta today, we will try to add a story around setting up Gatsby in sprint 16. I suggest we close this story.

On Aug 14, hahnrob commented:
The decision was made to host the Cupcake content in a website based on the Gatsby theme in the Aug 13, 2019 DDS Leadership meeting.