[BUG] Kick on Hypixel

Describe the bug
Using Quick Move in inventory on Hypixel lead to being Kicked
To Reproduce
Install the mod
Go on Hypixel
Use Quick Move in some inv (might need to do it twice or thrice)
Get Kicked
Expected behavior
Not being kicked i guess ?
Screenshots

PC (please complete the following information):

OS : Windows
Minecraft : 1.19.4
Fabric : 0.14.19
Fabric API : 0.76.0
Mods : Fabulously Optimized 4.7.0-beta.4 (can also be reproduced with just MidnightControls)
Version : 1.8.1

Additional context
Here are infos
https://hypixel.net/threads/update-regarding-modifications-sending-invalid-clicks.5130489/
https://hypixel.net/threads/update-regarding-modifications-sending-invalid-clicks.5130489/page-8#post-36853060

Midnight Controls isn't allowed on hypixel for some reason.

Midnight Controls isn't allowed on hypixel for some reason.

It's not that it isn't allowed, it's that it does some special thing with the click which it is supposed doing in another way from what their article says

Would love if someone were to fix that. As I have a hard time playing on keyboard/mouse so I prefer controller.


Share in Messenger

Hi. First of all, thank you creating this component. I want to ask if there is any option at the moment to share links to Facebook Messenger? Thanks.

Hello @bajracharya-kshitij,
according to this page: https://developers.facebook.com/docs/sharing/messenger/web there is no special link to share to Facebook Messenger, only Facebook.
Let me know if you find something!


ERROR: unable to update: fsync: invalid argument

Hi everyone,
currently getting the following error when updating mirror:
ERROR: unable to update: fsync: invalid argument

After some digging I found out that the aptly leveldb is hosted on a cifs share.
https://github.com/google/leveldb/issues/281
One idea would be to separate the leveldb from the "rootDir" defined in the .aptly.conf file.
Regards
Eric

@erickeller you can use symlinks to put one part on regular FS and another on CIFS. But I haven't tested any of aptly work on CIFS, and I doubt it would work (hard links).

thanks for the response, I was able to make this workaround, using a non cifs for hosting the db and mounting the pool as cifs.
But I will discourage this setup.

Hi Andrey, I think you can close this issue...


Format Errors - Dot Products

In the first Practice sections, five bullets down, it reads "compute $x, y, z-1, 2, 3". It should be a dot product of two vectors.
In the Length section under "True or False?" it reads "i.e., holds for any $". This seems to be another formatting problem.

Can you provide a URL? I'm not sure if you're talking about the lecture notes or the externally-hosted practice problems.

This one: http://maxlieblich.github.io/math126/#lecture-3.html


Configure Orcid UC3 account to be used in the DMPtool

Currently using @briri test account for the Orcid OmniAuth setup in the DMPtool. That should be replaced by using the UC3 Orcid Member API accounts both for sandbox testing (in dev/stage) and live one in production.
To Contact Orcid Team for this.

Moving this to Pivotal since it relates to private configuration details: https://www.pivotaltracker.com/n/projects/772637


Parser: Parse UUIDs; implement comments in AST; implement type annotations and signatures; fix field names

Pull Request Description
Implements:

UUIDs: https://www.pivotaltracker.com/story/show/182931137
Comments: https://www.pivotaltracker.com/story/show/182981779
Type annotations and signatures: https://www.pivotaltracker.com/story/show/182497454
Fix getter names (https://github.com/enso-org/enso/pull/3627#discussion_r940887460).

Important Notes

I can't fully test UUIDs; I have tested that the data obtained in Rust matches my understanding of how the format is supposed to work. What remains to be tested is that the data in Java matches the way the old parser handles the format. So @JaroslavTulach, let me know if you see any cases where I'm not returning the same values.
This implementation of type annotations and signatures accepts any expression in type context. It would probably be nice to narrow this down at some point, but for now I have no design info on what specifically should be allowed in type expressions; this implementation should be at least an incremental improvement.

Checklist
Please include the following checklist in your PR:

[x] The documentation has been updated if necessary.
[x] All code conforms to the
Scala,
Java,
and
Rust
style guides.
All code has been tested:

[x] Unit tests have been written where possible.
[x] If GUI codebase was changed: Enso GUI was tested when built using BOTH
./run ide build and ./run ide watch.

[ci no changelog needed]

I've just merged this PR into #3611 as https://github.com/enso-org/enso/pull/3611/commits/d4e5a4b36dfc636ea974e5f478a2011b89165bbe and there is one new failure when running the EnsoCompilerTest:
enso$ sbt --java-home /graalvm
sbt:enso> project runtime
sbt:runtime> testOnly *EnsoCompilerTest*
[error] Test org.enso.compiler.EnsoCompilerTest.testComment failed: IR for ## A type representing computations that may fail.
[error] type Maybe
[error]  shall be equal expected:<...ings = List(
[error]     IR.[Comment.Documentation(
[error]       doc =  A type representing computations that may fail.,
[error]       location = Some(
[error]         IdentifiedLocation[_]
[error]       ),
[error]       passData = Iterable(),
[error]       diagnostics = DiagnosticStorage(
[error]         diagnostics = List()
[error]       ),
[error]       id = _
[error]     ),
[error]     IR.]Module.Scope.Definit...> but was:<...ings = List(
[error]     IR.[]Module.Scope.Definit...>, took 0.076 sec
[error] Failed: Total 12, Failed 1, Errors 0, Passed 10, Skipped 1
[error] Failed tests:
[error]         org.enso.compiler.EnsoCompilerTest

which means the code in this PR no longer recognizes
    ## A type representing computations that may fail.
    type Maybe

as documentation comment. The old parser apparently believes this is a documentation comment.

There is no getter for UUID field of Tree as far as I can say.

I've just merged this PR into #3611 as d4e5a4b and there is one new failure when running the EnsoCompilerTest:
enso$ sbt --java-home /graalvm
sbt:enso> project runtime
sbt:runtime> testOnly *EnsoCompilerTest*
[error] Test org.enso.compiler.EnsoCompilerTest.testComment failed: IR for ## A type representing computations that may fail.
[error] type Maybe
[error]  shall be equal expected:<...ings = List(
[error]     IR.[Comment.Documentation(
[error]       doc =  A type representing computations that may fail.,
[error]       location = Some(
[error]         IdentifiedLocation[_]
[error]       ),
[error]       passData = Iterable(),
[error]       diagnostics = DiagnosticStorage(
[error]         diagnostics = List()
[error]       ),
[error]       id = _
[error]     ),
[error]     IR.]Module.Scope.Definit...> but was:<...ings = List(
[error]     IR.[]Module.Scope.Definit...>, took 0.076 sec
[error] Failed: Total 12, Failed 1, Errors 0, Passed 10, Skipped 1
[error] Failed tests:
[error]         org.enso.compiler.EnsoCompilerTest

which means the code in this PR no longer recognizes
    ## A type representing computations that may fail.
    type Maybe

as documentation comment. The old parser apparently believes this is a documentation comment.

Doc comments have not been implemented in the new parser (it's on the roadmap: https://www.pivotaltracker.com/story/show/182497173). That test must have been relying on treating all comments as doc comments, which is no more correct than treating all comments as machine-invisible plain comments. Sorry for the apparent regression, but in the implementation it's progress.

Combined this into #3674 for easier merge.


dart2js needs to support the dart:_debugger

The DDC currently supports import 'dart:_debugger' dart2js needs to support this library too for the test lib_2/html/debugger_test.

Why does dart2js need to support a private library?


chore: add jsdom web runner

Summary

Checklist

[ ] Tests updated (or not required).
[ ] Documentation updated (or not required).

!test-ng

!test-ng


Polls

Bluesky will be more entertaining when it has native support for embedded polls in posts, like most popular micro-blogging sites including Twitter, Facebook, Tumblr, and Mastodon.
Presumably depends on adding poll support to atproto:
https://github.com/bluesky-social/atproto/issues/1430

Further discussion on this feature can be found here: https://github.com/bluesky-social/atproto/discussions/1310
(Not closing this issue just in case the client app team wants to track it 👍 )


add answer exact match metric

add answer exact match metric

#29

We will define task as the evaluation API. Then, these metrics should be re-designed.


llmservice reconciler implementation

Adding the LLMServiceReconciler and updating the datastore. Consuming the LLMService is considered out of scope of this PR

There is a follow up PR to do the model name re-write, right?

This is already mentioned in description :)

A couple small linter-error fixes made here as well.

/lgtm


Create Search Page - Search Results Components

Requirements

A list that shows the medical institutions with doctors that meet the user’s criteria

Is sorted by shortest distance for MVP

Workflow - Using the results list

The user sees a list of clinics to the left and a map with pins to the right
The user clicks on one of the clinics in the list
The map centers on the pin associated with that clinic and the appearance of the pin changes to distinguish it from the other pins
The user clicks on the website icon in the list for the selected clinic, and a new tab opens for the location’s info page on Google Maps

On Google Maps, the user can see ratings, comments, and get directions

The user is able to refine their search results at the top of the results list

The user can change the language
The user can change the location
The user can change the doctor’s specialty

Let's adjust the workflow requirements based on our meeting notes as Search is going to be very simple for Milestone 1, and Maps may not come until Milestone 4.
https://www.notion.so/ourjapanlife/2022-12-22-Developer-Meeting-4e292f36d4304cd8ae07973abc453c26


Possible VSSPreview js problem?

I created an extension where I would like to use chart services. The relevant code looks like the following:
============ charts.ts =============
///
import WidgetHelpers = require('TFS/Dashboards/WidgetHelpers');
import * as Chart_Service from "Charts/Services";
class ChartWidget {
public load() {

    this.renderChart();

    return WidgetHelpers.WidgetStatusHelper.Success();
}

public reload() {

    this.renderChart();

    return WidgetHelpers.WidgetStatusHelper.Success();
}

private renderChart() {

    Chart_Service.ChartsService.getService().then(chartsService => { });
}

}
WidgetHelpers.IncludeWidgetStyles();
WidgetHelpers.IncludeWidgetConfigurationStyles();
VSS.register("id", function () {
return new ChartWidget();

});
private renderChart() {
    Chart_Service.ChartsService.getService().then(chartsService => { });

}
}
After installing the widget and putting it onto the Dashboard the following error occurs:
https://{account}.gallerycdn.vsassets.io/extensions/{account}/{extension}/{version}/1523791959911/VSSPreview/Utilities/ColorUtilities.js - 404 error
What is the fix for this issue?

Publishing the VSSPreview/Utilities/ColorUtilities.js file manually into the extension solved the problem. Undocumented feature or missing/incorrect reference?

@sonka-zs could you please elaborate on how you accomplished this? I am having the same problem but cannot figure out how to resolve it.

I am having the same issue too. Can you please elaborate?

Thanks for reporting this.
The broken load on VssPreview path looks like a regression on charts which affects 3rd party usage of the VSTS charting API. ColorUtilities previously existed as part of charting, but was factored outside of that SDK. I've filed a bug for correcting this dependency as a high priority.
I believe Sonka's local workaround approach was to download a copy of that file and self publish it(that script doesn't have any external dependencies).

Getting back to this thread - A hot fix for the broken dependency was rolled out to hosted service accounts on M135.1 and later of the "TFS" service. The version level of an account can be checked here:
https://.visualstudio.com/_apis/servicelevel
3rd Party usage of Charting should again be working for callers on accounts at that service version, with no need for workaround. If anyone is on an account with M135.1 or above and still sees an error here, let me know.
Thanks

I am using TFS 2018 update 3, Version M131.1. I am also getting the same error - "The extension 'extension-name' doesn't contain the requested asset type 'VSSPreview/Utilities/ColorUtilities.js".
@sonka-zs @PeterAntal : Could you please help how we can manually publish that file?


Pass parameters to modules in a way familiar to Python users/developers

Search before asking

[X] I searched the issues and found no similar issues.

Component
Transforms/Other
Feature
We need a way to pass parameters to the modules without using the CLI, at least in the notebooks to have a Pythonic way which most developers are familiar with.
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

@shahrokhDaijavad I suggest we make this part of https://github.com/IBM/data-prep-kit/issues/774 . Since we are doing one transform at a time, I think it makes sense that once the re-structuring is done, we immediately do the API so we get early peak on results.

@touma-I Makes sense. I agree


Remove GetContainers from Runtime interface

This function is no longer considered needed.

/cc @vmarmol, @yifan-gu, @dchen1107

lgtm

LGTM

I'll merge on green


[<IP_ADDRESS>] Advancing game time does not advance crafting

Under Gameplay > Tools > Adventure, using "Increase game time by" correctly advances the clock, but does not progress crafting (or other time-based resource usage, such as food).
It might be a feature request, but perhaps a checkbox option could be added to actually advance progress when this feature is used?
An alternative would be to allow Short Rests to last longer than 1 hour to avoid doing a dozen of them when crafting something that doesn't take 24 hours. Maybe add 6 hour and 12 hour Short Rest buttons to the game UI? Not sure what is easier.

Use the other option to reduce crafting time if that is your use case. Not a bug.

Use the other option to reduce crafting time if that is your use case. Not a bug.

That is a workaround, which from my understanding requires the following steps to perform if one does not wish to simply avoid crafting and spawn the item in question:

Click Increase game time as desired
Reduce crafting time by a percentage calculated according to the time increased
Perform a Short Rest to complete crafting
Reduce Crafting time by 0% to go back to normal

This would need to be performed every day if you wish your party to adventure at night and use crafting.
Does this require a separate feature request?

It’s simpler than that.  Simply reduce the time and call it done.


[Backend] JSON PATCH Endpoint for Datasets/Saas Configs

Describe the solution you'd like
For making edits to a datasetconfig or a saasconfig, your only option currently is to edit a very deeply nested JSON body and PATCH the whole thing back to Fidesops.
Add a new endpoint(s) PATCH /dataset/{fides_key} that supports incremental edits to a dataset using JSON Patch format, with slight adjustments. The frontend should be able make requests saying to add/remove/replace a collection/field/reference/identity without having to know the index of its location or whether a key exists already, the backend will take care of that. The frontend request body should be as simple as possible, and the backend is responsible for re-formatting in the appropriate way.
The backend should be responsible for taking the frontend request, formatting them into appropriate index-based patch operations, and applying the patch on the dataset or saas config using python-json-patch. Since the backend needs to make edits anyway, we may just avoid python-json-patch and just roll our own solution. It should fail in an all or nothing way.  If all the operations can't be completed, none of it should be persisted to the database.   It should support an unlimited number of patch operations, one operation, ten operations, etc.
Unlike JSON Patch format, don't specify indices in path.
[
  { "op": "replace", "path": "/baz", "value": "boo" },
  { "op": "add", "path": "/hello", "value": ["world"] },
  { "op": "remove", "path": "/foo" }
]

Describe alternatives you've considered, if any
Early design review had the frontend be entirely responsible for building properly formatted JSON Patch operations. To lighten the FE load, we are looking into moving more of the logic to the backend.  If a collection key doesn't yet exist on the dataset, the backend should add it for example, without the FE having to specify that it needs to be added.
Additional context
Output of ticket:

Determine what information for Saas configs will need to be incrementally edited at this time.  Saas connectors differ from database connectors in that their configuration is stored in two locations instead of one.  References for example, are stored on the saas config instead of the dataset for a saas connector, while they are stored on the dataset for a database connector.   If very minimal edits are needed to the saas config, we could potentially have one endpoint that figures out if the information should be persisted to the saas config or the dataset config.
Determine request body first.   - Specify frontend request bodies for adding/updating/deleting a collection/field/nested field/reference/identity.  Make the request body as simple as possible. For example, the FE could specify we want to add a reference, but the backend figures out that it needs to go under fidesops_meta.
Determine if we should use python-json-patch or roll our own solution.
Add the new api endpoint(s) to support these edits.  - figure out if saas configs and dataset configs should be updated through the same endpoint.

Note: Reference checking won't be added here.   If a reference is added, for now, we'll just add it, we won't validate that it exists. This is in line with our current practices.  Reference checking can be added as a follow-up.


Getting 8 in front of each numbers.

Not sure why. The Odometer module was working fine and then it broke.
<Odometer value={1234} format="(,ddd).dd" />
output
81,828384
Anyone know why?

Not sure why. The Odometer module was working fine and then it broke.
<Odometer value={1234} format="(,ddd).dd" />
output
81,828384
Anyone know why?

I think,
It's because of css. You may not import css ?

Exactly. Please check CSS. This "8"s generated by original library

Yes that was it!

I am getting the same issue, and I have imported the css as given in the documentation in my index.html
<link rel="stylesheet" href="odometer-theme-default.css" />
Still i get this error and css is not getting applied in my project.
Anything i might have done right?

open the page url by putting view-source: before the url like, view-source:https://domain.com    and the href link <link rel="stylesheet" href="odometer-theme-default.css" />
Check, if the href css file location is correct or not

Correctly. You should download theme CSS file and put somewhere in project. Then import it.
Do you think I should update Readme to make it more clear for everyone?

It will be good.
And i have a question.
Is it possible to make this odometer for react native.
I need odometer for in react native but i have not find any library of odometer for react native..

Is it possible to make this odometer for react native.

Unfortunately no. This is just a wrapper over odometer.js for web.

Correctly. You should download theme CSS file and put somewhere in project. Then import it.
Do you think I should update Readme to make it more clear for everyone?

Thanks, that worked!
Yes, I think you can update the Readme, as it will be more precise and someone like me wouldn't get stuck.


Update Azure AD menu options

Small change to the menu option labels in the AzureAD portal when setting the MFA Trusted IP settings.

#sign-off


v1alpha2: Add implementation

/assign @ddysher @DjangoPeng @jlewi @mitake @ScorpioCPH
This PR is the implementation of v1alpha2 and it is mainly contributed by @ScorpioCPH  and @gaocegege
Signed-off-by: Ce Gao<EMAIL_ADDRESS>

This change is

Coverage increased (+3.02%) to 50.061% when pulling 30b9872e7fa3dc1cf60e46a11b4837741a452fa4 on gaocegege:implementation into 792d399e6538d92f80258e58e418cd92759f7f3f on kubeflow:master.

The test coverage of v1alpha2 should be 70%+, PTAL

Would you mind submitting a separate PR for the signals package just to cut down the size of this PR a bit?

@jlewi Sure

Rebased upstream/master and addressed some comments. PTAL

Review status: 0 of 15 files reviewed at latest revision, 8 unresolved discussions.

cmd/tf-operator.v2/app/options/options.go, line 38 at r2 (raw file):
Previously, gaocegege (Ce Gao) wrote…
Yeah, I will update it.

Don't we get the path of the KubeCOnfig from an environment variable? So is the plan to get rid of this flag altogether?

pkg/controller.v2/controller.go, line 152 at r7 (raw file):

expectations

Can you explain this to me? Why do track expectations in the form of aggregated statistics?
Why wouldn't we keep track of expectations for each replica? e.g. have an expectation for
service-0 create
service-1 create
If we just look at aggregated statistics won't we have problems? e.g. suppose we expect 2 workers
So in the current implementation we expect 2 create requests but if we get
service - 0 create
service -0 create
Then we haven't actually created both services even though we observed 2 create events.

pkg/controller.v2/controller_pod.go, line 54 at r7 (raw file):

	// Expect to have `replicas - succeeded` pods alive.
	expected := *spec.Replicas - succeeded

Why are you only checking the number of pods? Why aren't you checking that each individual replica has a pod in the expected state?
Not only will checking each replica be more robust, but it positions us to do a better job debugging problems because we will know what state each replica is in.

pkg/controller.v2/controller_pod.go, line 61 at r7 (raw file):

		err := tc.updateTFJobConditions(tfjob, tfv1alpha2.TFJobSucceeded, tfJobSucceededReason, msg)
		if err != nil {
			log.Infof("Append tfjob condition error: %v", err)

Here and everywhere else please use a context logger like
https://github.com/kubeflow/tf-operator/blob/master/pkg/trainer/training.go#L89
And log fields for the
job namespace + name
uuid
replica (if applicable)
replica index if applicable
This will ensure these fields are stored as metadata in the json log entry which makes filtering log messages for a particular job to figure out what happened easier.

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):

	diff := len(activePods) - int(expected)

	if diff < 0 {

Per comments above; can we check that every replica is in the expected state?

pkg/controller.v2/controller_pod.go, line 109 at r7 (raw file):

		for _, index := range diffIndexes {
			log.Infof("need to create new pod: %s-%s", rt, index)

Please use logrus to log this with rt and index as metadata fields so we can easily filter log messages by replica.
This will make it really easy to filter logs to find out what happened during a replicas life.

pkg/controller.v2/controller_pod.go, line 148 at r7 (raw file):

			// Set restart policy
			if spec.RestartPolicy != "ExitCode" {

nit; Define a named constant

pkg/controller.v2/controller_pod.go, line 203 at r7 (raw file):

		if _, ok := desiredIndexes[index]; ok {
			desiredIndexes[index] = hit
		}

Should we log a warning if index isn't found in desiredIndexes? That would seem like it indicates a bug of some sort since that shouldn't happen.

pkg/controller.v2/controller_pod.go, line 218 at r7 (raw file):

// getPodsForTFJob returns the set of pods that this tfjob should manage.
// It also reconciles ControllerRef by adopting/orphaning.
// Note that the returned Pods are pointers into the cache.

What does adopting/orphaning pods mean? I assume it means changing the owner ref on the pod to point to this TFJob controller.
Do we actually expect this to happen? Why would the labels or selector get changed  on the pod?

pkg/controller.v2/controller_pod.go, line 295 at r7 (raw file):

		tfjob := tc.resolveControllerRef(pod.Namespace, controllerRef)
		if tfjob == nil {
			log.Info("This pod's tfjob does not exists")

Lets add appropriate metadata fields to the long entry; e.g. tfjob name and uuid and maybe replica type and index?

Comments from Reviewable

cmd/tf-operator.v2/app/options/options.go, line 38 at r2 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Don't we get the path of the KubeCOnfig from an environment variable? So is the plan to get rid of this flag altogether?

Please have a look at https://github.com/kubeflow/tf-operator/issues/522, I think we should keep it for local running.

Comments from Reviewable

pkg/controller.v2/controller.go, line 152 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…

expectations

Can you explain this to me? Why do track expectations in the form of aggregated statistics?
Why wouldn't we keep track of expectations for each replica? e.g. have an expectation for
service-0 create
service-1 create
If we just look at aggregated statistics won't we have problems? e.g. suppose we expect 2 workers
So in the current implementation we expect 2 create requests but if we get
service - 0 create
service -0 create
Then we haven't actually created both services even though we observed 2 create events.

@ScorpioCPH knows more about it.
Personally, I think we will check all services index to keep all services running, thus we can detect there are two smiliar services.
I think we should not keep track of expectations for each replica, because we do not keep any state in controller side and we do not know how many replicas we have.

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 54 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Why are you only checking the number of pods? Why aren't you checking that each individual replica has a pod in the expected state?
Not only will checking each replica be more robust, but it positions us to do a better job debugging problems because we will know what state each replica is in.

Here is to check if all workers are succeeded, we do check that each individual replica has a pod in the expected state, if expected is not 0

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 61 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Here and everywhere else please use a context logger like
https://github.com/kubeflow/tf-operator/blob/master/pkg/trainer/training.go#L89
And log fields for the
job namespace + name
uuid
replica (if applicable)
replica index if applicable
This will ensure these fields are stored as metadata in the json log entry which makes filtering log messages for a particular job to figure out what happened easier.

Good point, I will file an issue to keep track and fix it after the PR merged. WDYT?

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Per comments above; can we check that every replica is in the expected state?

I am not sure if I misunderstand you. Could you explain more about it?

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 109 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Please use logrus to log this with rt and index as metadata fields so we can easily filter log messages by replica.
This will make it really easy to filter logs to find out what happened during a replicas life.

SGTM. I will file an issue for it.

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 148 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
nit; Define a named constant

OK, I will update it.

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 203 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Should we log a warning if index isn't found in desiredIndexes? That would seem like it indicates a bug of some sort since that shouldn't happen.

I do not think so, it is a normal behaviour since this function is to move from current state to desired. Thus there will be lots of warnings.
WDYT @ScorpioCPH

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 295 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Lets add appropriate metadata fields to the long entry; e.g. tfjob name and uuid and maybe replica type and index?

I will file another PR to solve all issues about the log.

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 218 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
What does adopting/orphaning pods mean? I assume it means changing the owner ref on the pod to point to this TFJob controller.
Do we actually expect this to happen? Why would the labels or selector get changed  on the pod?

It is from job controllers. We do not expect there are orphaning pods but there will be new pods which need to be claimed.
/cc @ScorpioCPH

Comments from Reviewable

Reviewed 2 of 18 files at r1, 1 of 4 files at r6.
Review status: 3 of 15 files reviewed at latest revision, 16 unresolved discussions.

pkg/controller.v2/controller.go, line 152 at r7 (raw file):

expectations

The controller doesn't maintain a cache of TFJobs somewhere?
It seems like the controller only checks all the replicas if there is a difference between the number of expected events and actual events in controller_pod.go

pkg/controller.v2/controller_pod.go, line 54 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…
Here is to check if all workers are succeeded, we do check that each individual replica has a pod in the expected state, if expected is not 0

You are only counting the number of pods in a given state eg. #active, #succeeded, #runningPods.
I think there's an implicit assumption in the code (filterPodsForTFReplicaType and FilterActivePods)  that if you have N pods in a given state e.g (2 active pods) then these pods correspond to different replicas.
I think the code should be able to handle the case where there are multiple pods for a given replica.
Perhaps we can do something simple; e.g. if there are multiple pods for a given replica remove it from the list pods before counting pods in each state.  This would ensure we trigger the extended checks below.

pkg/controller.v2/controller_pod.go, line 61 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…
Good point, I will file an issue to keep track and fix it after the PR merged. WDYT?

SGTM.

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…
I am not sure if I misunderstand you. Could you explain more about it?

I think the current code assumes that if there are N pods in a given state these correspond to different replicas as opposed to N pods for the same replica.
The code also assumes that if there are two pods in different states they correspond to different replicas.
I don't think we should make the assumption as noted above.
I think we need to explicitly allow for multiple pods for a given replica.
For example, if a pod is terminated by K8s or for some other unrelated reason. I don't know that we should delete it immediately; it might be helpful to keep it around for debugging.
But the computation of diff implicitly assumes that each pod is for a different replica. I think we should fix that.
Why not do the following

Have filterPods return a map from replica index -> list of pods
Loop over the map

For each replica  check if there is anything that needs to be done (i.e. create a pod)
As you loop over the map aggregate whatever statistics you need to report and to decide the condition of the job.

pkg/controller.v2/controller_pod.go, line 203 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…
I do not think so, it is a normal behaviour since this function is to move from current state to desired. Thus there will be lots of warnings.
WDYT @ScorpioCPH

desiredIndexes is initialized to a map with keys 0 ... replicas
So if the if condition isn't satisfied this means index is outside the range 0 to N.  This shouldn't happen so its worth logging a warning .

pkg/controller.v2/controller_pod.go, line 218 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…
It is from job controllers. We do not expect there are orphaning pods but there will be new pods which need to be claimed.
/cc @ScorpioCPH

What does claiming a pod mean? Does it mean setting the owner reference? Wouldn't the owner reference be set when the pod is created?

pkg/controller.v2/controller_utils.go, line 110 at r8 (raw file):

// * Once set expectations can only be lowered
// * A controller isn't synced till its expectations are either fulfilled, or expire
// * Controllers that don't set expectations will get woken up for every matching controllee

Is there a typo? should it be "every matching event"?

pkg/controller.v2/controller_utils.go, line 124 at r8 (raw file):

// Warning: if using KeyFunc it is not safe to use a single ControllerExpectationsInterface with different
// types of controllers, because the keys might conflict across types.
type ControllerExpectationsInterface interface {

Would it make sense to move expectations code into its own file expectations.go?

pkg/controller.v2/controller_utils.go, line 166 at r8 (raw file):

	if exp, exists, err := r.GetExpectations(controllerKey); exists {
		if exp.Fulfilled() {
			glog.V(4).Infof("Controller expectations fulfilled %#v", exp)

Please use logrus and add metadata field to the log entries so that we can filter messages by job/replica etc...
Otherwise its pretty impossible to understand what is happening to a given job if there are multiple jobs running.

pkg/controller.v2/controller_utils.go, line 372 at r8 (raw file):

// Reasons for pod events
const (

Isn't the convention in Go to Define constants at the top?

pkg/controller.v2/controller_utils.go, line 397 at r8 (raw file):

	// CreatePodsOnNode creates a new pod according to the spec on the specified node,
	// and sets the ControllerRef.
	CreatePodsOnNode(nodeName, namespace string, template *v1.PodTemplateSpec, object runtime.Object, controllerRef *metav1.OwnerReference) error

Why do we support creating a pod on a specific node?

Comments from Reviewable

@jlewi Thanks for your review. FYI, the controller_utils.go is copied from kubernetes and I think we'd better not to change it.
It is Saturday in Shanghai, China and I will take a look at your comments after the weekend. 😄

pkg/controller.v2/controller.go, line 152 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…

expectations

The controller doesn't maintain a cache of TFJobs somewhere?
It seems like the controller only checks all the replicas if there is a difference between the number of expected events and actual events in controller_pod.go

We do not maintain the cache, we get the TFJob from the list-watch when there are some changes from replicas or TFJobs.

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 218 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
What does claiming a pod mean? Does it mean setting the owner reference? Wouldn't the owner reference be set when the pod is created?

Yeah, the code refers to the job controller and I think we do not expect that happen but there might be. Thus I think we should claim them and deal with them later.

Comments from Reviewable

pkg/controller.v2/controller_utils.go, line 110 at r8 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Is there a typo? should it be "every matching event"?

The file is a copy of https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/controller_utils.go and we do not vendor it since we think the vendor k8s.io/kubernetes is too large thus we put it in the code. But I think we should not change the code manually.

Comments from Reviewable

pkg/controller.v2/controller_utils.go, line 124 at r8 (raw file):

The file is a copy of https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/controller_utils.go and we do not vendor it since we think the vendor k8s.io/kubernetes is too large thus we put it in the code. But I think we should not change the code manually.

Comments from Reviewable

pkg/controller.v2/controller_utils.go, line 166 at r8 (raw file):

The file is a copy of https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/controller_utils.go and we do not vendor it since we think the vendor k8s.io/kubernetes is too large thus we put it in the code. But I think we should not change the code manually.

Comments from Reviewable

pkg/controller.v2/controller_utils.go, line 372 at r8 (raw file):

The file is a copy of https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/controller_utils.go and we do not vendor it since we think the vendor k8s.io/kubernetes is too large thus we put it in the code. But I think we should not change the code manually.

Comments from Reviewable

pkg/controller.v2/controller_utils.go, line 397 at r8 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Why do we support creating a pod on a specific node?

The file is a copy of https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/controller_utils.go and we do not vendor it since we think the vendor k8s.io/kubernetes is too large thus we put it in the code. But I think we should not change the code manually.

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 54 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
You are only counting the number of pods in a given state eg. #active, #succeeded, #runningPods.
I think there's an implicit assumption in the code (filterPodsForTFReplicaType and FilterActivePods)  that if you have N pods in a given state e.g (2 active pods) then these pods correspond to different replicas.
I think the code should be able to handle the case where there are multiple pods for a given replica.
Perhaps we can do something simple; e.g. if there are multiple pods for a given replica remove it from the list pods before counting pods in each state.  This would ensure we trigger the extended checks below.

Oh, yeah. It is a good point. Actually, we have a potential bug during distributed training. Please see https://github.com/kubeflow/tf-operator/issues/538#issue-314491487. I am not sure if we should use a map to fix it. We could just diff all (active + succeeded) replicas and create it. If there are more pods than we need for one replica, it should be handled by  https://github.com/kubeflow/tf-operator/pull/526/files#diff-a5453ed67196062408fa782a70f4be38R166 although it is TODO.
Map is an option to solve it. I will keep track of the issue in https://github.com/kubeflow/tf-operator/issues/538. It is a p0 bug.

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):

Oh, yeah. It is a good point. Actually, we have a potential bug during distributed training. Please see #538 (comment). I am not sure if we should use a map to fix it. We could just diff all (active + succeeded) replicas and create it. If there are more pods than we need for one replica, it should be handled by  https://github.com/kubeflow/tf-operator/pull/526/files#diff-a5453ed67196062408fa782a70f4be38R166 although it is TODO.
Map is an option to solve it. I will keep track of the issue in #538. It is a p0 bug.

Comments from Reviewable

Review status: 3 of 15 files reviewed at latest revision, 12 unresolved discussions.

cmd/tf-operator.v2/app/options/options.go, line 38 at r2 (raw file):
Previously, gaocegege (Ce Gao) wrote…
Please have a look at https://github.com/kubeflow/tf-operator/issues/522, I think we should keep it for local running.

Why do we need two ways of specifying the path to kubeconfig? Even if users are running locally they should be able to set the environment variable KUBECONFIG.
I think its highly undesirable to have both an environment variable and a command line flag. This inevitably leads to confusion about which should take precedence.

pkg/controller.v2/controller_pod.go, line 54 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…
Oh, yeah. It is a good point. Actually, we have a potential bug during distributed training. Please see https://github.com/kubeflow/tf-operator/issues/538#issue-314491487. I am not sure if we should use a map to fix it. We could just diff all (active + succeeded) replicas and create it. If there are more pods than we need for one replica, it should be handled by  https://github.com/kubeflow/tf-operator/pull/526/files#diff-a5453ed67196062408fa782a70f4be38R166 although it is TODO.
Map is an option to solve it. I will keep track of the issue in https://github.com/kubeflow/tf-operator/issues/538. It is a p0 bug.

I couldn't understand from #538 what the bug is. What's the plan for this PR?

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…

Oh, yeah. It is a good point. Actually, we have a potential bug during distributed training. Please see #538 (comment). I am not sure if we should use a map to fix it. We could just diff all (active + succeeded) replicas and create it. If there are more pods than we need for one replica, it should be handled by  https://github.com/kubeflow/tf-operator/pull/526/files#diff-a5453ed67196062408fa782a70f4be38R166 although it is TODO.
Map is an option to solve it. I will keep track of the issue in #538. It is a p0 bug.

Do you plan to fix this in this PR?

pkg/controller.v2/controller_pod.go, line 203 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…
I will put the issue in https://github.com/kubeflow/tf-operator/issues/537

Why not just fix it in this PR?

Comments from Reviewable

cmd/tf-operator.v2/app/options/options.go, line 38 at r2 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Why do we need two ways of specifying the path to kubeconfig? Even if users are running locally they should be able to set the environment variable KUBECONFIG.
I think its highly undesirable to have both an environment variable and a command line flag. This inevitably leads to confusion about which should take precedence.

Make sense. I could remove the flag later. Personally, I think it is better not to import more enhancements into the PR, since I think it is a sync with upstream/v1alpha2. We are using it to implement some systems and I hope we could use this commit instead of the branch v1alpha2. Thus keeping consistent matters.

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 54 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
I couldn't understand from #538 what the bug is. What's the plan for this PR?

Please see above, could we merge it and enhance the implementation iteratively?

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Do you plan to fix this in this PR?

No, I think it is a big change and I am not sure map is the best way. Thus we could merge it and enhance the implementation iteratively.

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 203 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Why not just fix it in this PR?

Because we need to import logger and then do it. I think we could do it after the PR merged. Or I could file a new PR based on this PR to fix it.

Comments from Reviewable

Review status: 3 of 15 files reviewed at latest revision, 12 unresolved discussions.

cmd/tf-operator.v2/app/options/options.go, line 38 at r2 (raw file):
Previously, gaocegege (Ce Gao) wrote…
Make sense. I could remove the flag later. Personally, I think it is better not to import more enhancements into the PR, since I think it is a sync with upstream/v1alpha2. We are using it to implement some systems and I hope we could use this commit instead of the branch v1alpha2. Thus keeping consistent matters.

I don't understand your point about doing more changes in this PR. The point of this PR is to start checking code into master.
Why would we treat the work going on in the v1alpha2 branch any differently from work going on in a local branch
I think we should make all the changes in this PR such that the resulting code that's checked into master is in a good state and the source of truth.
So I think we should make this and other straightforward changes in this PR. I don't think we should check in code only to remove it in a follow on PR.

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…
No, I think it is a big change and I am not sure map is the best way. Thus we could merge it and enhance the implementation iteratively.

If we're uncertain about how to implement it then why check it in?
Why not remove the code that we are uncertain about (replace it with a TODO).
Alternatively, is there a simpler, less efficient but correct implementation we could check in? I don't like the idea of checking in code that we don't think works. Could we just iterate over all the replicas and check for each one if we need to do any work?

pkg/controller.v2/controller_pod.go, line 203 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…
Because we need to import logger and then do it. I think we could do it after the PR merged. Or I could file a new PR based on this PR to fix it.

Isn't controller_pod.go already importing log?

Comments from Reviewable

Review status: 3 of 15 files reviewed at latest revision, 13 unresolved discussions.

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
If we're uncertain about how to implement it then why check it in?
Why not remove the code that we are uncertain about (replace it with a TODO).
Alternatively, is there a simpler, less efficient but correct implementation we could check in? I don't like the idea of checking in code that we don't think works. Could we just iterate over all the replicas and check for each one if we need to do any work?

Hi, getDiffPodIndexes() will check which replica should be handled.

pkg/controller.v2/controller_pod.go, line 218 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…
Yeah, the code refers to the job controller and I think we do not expect that happen but there might be. Thus I think we should claim them and deal with them later.

We can't assume that only tf-operator will change the pods' status, so we should claiming these pods.

Comments from Reviewable

cmd/tf-operator.v2/app/options/options.go, line 38 at r2 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
I don't understand your point about doing more changes in this PR. The point of this PR is to start checking code into master.
Why would we treat the work going on in the v1alpha2 branch any differently from work going on in a local branch
I think we should make all the changes in this PR such that the resulting code that's checked into master is in a good state and the source of truth.
So I think we should make this and other straightforward changes in this PR. I don't think we should check in code only to remove it in a follow on PR.

Done

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):
Previously, ScorpioCPH (Penghao Cen) wrote…
Hi, getDiffPodIndexes() will check which replica should be handled.

@ScorpioCPH I think Jeremy means that we use an integer instead of a map to represent the succeeded/failed pods.

Comments from Reviewable

Review status: 3 of 15 files reviewed at latest revision, 12 unresolved discussions.

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…
@ScorpioCPH I think Jeremy means that we use an integer instead of a map to represent the succeeded/failed pods.

I think the problem is that we check if diff < 0 to decided whether there is any work to do.
As noted in my earlier comment I think that check is insufficient under certain conditions; e.g. the case where you have multiple pods for a given.
You already get a list of all pods for this job.  So I think you want to group these pods based on replica. You can then correctly check

If there is a replica missing some pods
If there are multiple pods for a replica; you can figure out what the correct state and action is.

pkg/controller.v2/controller_pod.go, line 218 at r7 (raw file):
Previously, ScorpioCPH (Penghao Cen) wrote…
We can't assume that only tf-operator will change the pods' status, so we should claiming these pods.

Thanks.

Comments from Reviewable

@jlewi @gaocegege v1alpha2 is not just a api change? we are doing a totally refactoring??? can we still keep compatiblty with v1alpha1?

@u2takey We can not since API changes. We refactored the operator because of #300

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
I think the problem is that we check if diff < 0 to decided whether there is any work to do.
As noted in my earlier comment I think that check is insufficient under certain conditions; e.g. the case where you have multiple pods for a given.
You already get a list of all pods for this job.  So I think you want to group these pods based on replica. You can then correctly check

If there is a replica missing some pods
If there are multiple pods for a replica; you can figure out what the correct state and action is.

I cam not sure if I understand you. Do you mean the code similar to here:
func (tc *TFJobController) syncPods(pods []*v1.Pod, replicas int, logger  *log.Entry) {
	podSlices := getPodSlices(pods, replicas， logger)
	for index, podSlice := range podSlices {
		if len(podSlice) > 0 {
			logger.Warning("We have to many pods for the worker %d", index)
			// Kill some
		}
		if len(podsSlice) == 0 {
			// Create one
		}
		pod := podSlice[0]
		// We already have one, and check if it is succeede or something else.
	}
}

func getPodSlices(pods []*v1.Pod, replicas int, logger *log.Entry) [][]*v1.Pod {
	resMap := make([][]*v1.Pod)
	for _, pod := range pods {
		if _, ok := pod.Labels[tfReplicaIndexLabel]; !ok {
			logger.Warning("The pod do not have the index label.")
		}
		index, err := strconv.Atoi(pod.Labels[tfReplicaIndexLabel])
		if err != nil {
			logger.Warning("Error when strconv.Atoi: %v", err)
		}
		if index < 0 || index >= replicas {
			logger.Warningf("The label index is not expected: %d", index)
		}

		resMap[index] = append(resMap[index], pod)
	}
}

Comments from Reviewable

Review status: 3 of 17 files reviewed at latest revision, 11 unresolved discussions.

cmd/tf-operator.v2/app/options/options.go, line 38 at r2 (raw file):
Previously, gaocegege (Ce Gao) wrote…
Done

Thanks.

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):
Previously, gaocegege (Ce Gao) wrote…
I cam not sure if I understand you. Do you mean the code similar to here:
func (tc *TFJobController) syncPods(pods []*v1.Pod, replicas int, logger  *log.Entry) {
	podSlices := getPodSlices(pods, replicas， logger)
	for index, podSlice := range podSlices {
		if len(podSlice) > 0 {
			logger.Warning("We have to many pods for the worker %d", index)
			// Kill some
		}
		if len(podsSlice) == 0 {
			// Create one
		}
		pod := podSlice[0]
		// We already have one, and check if it is succeede or something else.
	}
}

func getPodSlices(pods []*v1.Pod, replicas int, logger *log.Entry) [][]*v1.Pod {
	resMap := make([][]*v1.Pod)
	for _, pod := range pods {
		if _, ok := pod.Labels[tfReplicaIndexLabel]; !ok {
			logger.Warning("The pod do not have the index label.")
		}
		index, err := strconv.Atoi(pod.Labels[tfReplicaIndexLabel])
		if err != nil {
			logger.Warning("Error when strconv.Atoi: %v", err)
		}
		if index < 0 || index >= replicas {
			logger.Warningf("The label index is not expected: %d", index)
		}

		resMap[index] = append(resMap[index], pod)
	}
}

Exactly. I'd be fine merging that snippet with TODOs to flush out the implementation.

Comments from Reviewable

pkg/controller.v2/controller_pod.go, line 94 at r7 (raw file):
Previously, jlewi (Jeremy Lewi) wrote…
Exactly. I'd be fine merging that snippet with TODOs to flush out the implementation.

I added the snippet to the code and add a TODO in reconcilePods, PTAL

Comments from Reviewable

Thanks!
/lgtm
/approve


Cannot Disable Sticky Hover

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.93.1
OS Version: Linux, Arch

Steps to Reproduce:

use these settings: "editor.hover.sticky": false, "editor.hover.delay": 0, "editor.hover.hidingDelay": 0
hover over some code so that a hover panel appears, for example hovering a line of CSS shows something from MDN
move mouse cursor over the hover

expected: hover panel disappears
actual: hover panel is still shown, as if editor.hover.sticky were true
Additional Info:
I don't know when exactly this problem began, but it has been a while. I think a few months. I typically use the newest stable vscode within a week or two of it releasing.
Sometimes, it works correctly for a while after launching or restarting vscode. But after a few minutes, the problem appears again.
Workaround:
If anyone else is looking for an immediate fix, I quickly figured one out after I was very irritated by this today.

Use the "Custom CSS and JS Loader" extension.
Inject the following CSS:

div.overflowingContentWidgets div[widgetid="editor.contrib.resizableContentHoverWidget"]:hover {
	display: none !important;
}

After doing so, my hover works correctly and smoothly again.

I updated to version 1.94.1.
The bug is still present. I checked with all extensions disabled.
My workaround still works.

I updated to version 1.95.1.
The bug is still present. I checked with all extensions disabled.
I found a clue about the cause. Initially, when opening a new vscode instance, hovering works correctly. When I hover over a color code in CSS, it brings up a sticky color selector. Afterwards, all hovers are sticky until I launch a fresh vscode instance again.

Hi thank you for filing this issue. I am not able to reproduce this issue on our nightly Insiders release. We have made some improvements both to the hover and the color decorators recently. Do you see this issue on the latest daily release?
https://github.com/user-attachments/assets/b4c45c9d-b4bf-4c17-8278-f7e41a14d7b0

I tried a daily build and it seems fixed.
Thanks for looking into it.
Version tried:
Version: 1.96.0-insider
Commit: b18e7a700033b39ed2c3975759b6327c8205f958
Date: 2024-12-08T16:04:45.916Z
Electron: 32.2.6
ElectronBuildId: 10629634
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Linux x64 6.10.10-zen1-1-zen

Thank you for confirming. I will close this issue.


Fixes and Extensions to the IncludeProcessor and Reader classes

This PR includes the following thee changes:
Fix of IncludeProcessor#handles method
The handles(String) method in the IncludeProcessor is not called, because the annotation on the IncludeProcessorProxy#handles method lacks a question mark. Test case added.
Extended IncludeProcessor to accept anonymous attributes
Before, the IncludeProcessor ignored any anonymous attributes. Now they can be used separated by commas. Internally, they are key value pairs where the keys are numbered accordingly to their order in the squared macros. The fix is only that these key value pairs are also evaluated when constructing the attributes map. Test case added.
Extended Reader and ReaderImpl
The reader now provides the methods getFile and getDir which are delegated to 'file' and 'dir' of asciidoc.

Awesome, thank you!
Great that you discovered that the handles() method wasn't actually called for IncludeProcessors.
I am personally ok with mapping the positional args to the strings "1", "2", ...
Could you please check why the tests are failing on Travis with Java 7?
Another – maybe pedantic – note: Could you please check the indentation of the source code? Looks like you're using Tabs instead of Spaces which makes the code look a bit weird on Github.

I am personally ok with mapping the positional args to the strings "1", "2", ...

I believe that will solve some other type issues we were having. I was using numbers here to avoid collision with attributes that have the same name, but we could just say that numeric keys (1=value) are reserved for another purpose and should not be declared explicitly.

Extended IncludeProcessor to accept anonymous attributes

Do you mean positional attributes (value only)? If so, could you update the terminology? (See http://asciidoctor.org/docs/user-manual/#setting-attributes-on-an-element)
If I try using an IncludeProcessor written in Ruby, I get these attributes:
include::other.adoc[foo,bar,a=b]

gives me:
{1=>"foo", 2=>"bar", "a"=>"b"}

So effectively this fix translates those numeric keys into string keys, correct?

Btw, thanks for this fix!

:+1:

Thanks for your feedback!

I replaced the tabs by spaces, as you preferred, @robertpanzer.
@mojavelinux, you're right, this fix translates those numeric keys into string keys.
I also replaced the term 'anonymous' by 'positional' to fit in to the terminology.
I tried to reproduce the errors in the Java7 environment, but it seems to work with JDK7 on my machine. Do you have some advice on how I could reproduce the failure?

Sorry for responding so late!
I just tried out the failing test.
I guess this is due to the extension iterating over the attributes Map and concatenating the results.
The map is not ordered in any way and the order of the elements given by a HashMap definitely differs between Java 7 and 8. (Stumbled myself over this change a couple of times)
So for me the test fails with this error:
java.lang.AssertionError:
Expected: a string starting with "My,Positional,Attribute List"
     but: was "Attribute List,Positional,My"
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:956)
	at org.junit.Assert.assertThat(Assert.java:923)
	at org.asciidoctor.extension.WhenJavaExtensionIsRegistered.a_include_processor_can_handle_positional_attrs(WhenJavaExtensionIsRegistered.java:430)

You might simply want to either sort the entries by key ("1", "2" and "3") or just test if the expected substrings are present.

@robertpanzer thanks a lot for your advice! Hopefully the tests will be green now!

@robertpanzer, I don't know the cause of the error. The message says, I should look at
file:///C:/projects/asciidoctorj/asciidoctorj-pdf/build/reports/tests/index.html
to get information about the error. Do you know the cause of the error?

Awesome!
Thank you for this great contribution!

Do you know the cause of the error?

@mmews-n4 The full report is not accessible now, but the output shows this SEVERE: (RuntimeError) asciidoctor: FAILED: required gem 'rouge' is not installed. Processing aborted.
Highly likely, to be related to this: https://github.com/robertpanzer/asciidoctorj-pdf/issues/3


FFSSBs with spaces in names don't launch correctly

While ffssb seems to support creating FFSSB's with spaces in names (when correctly escaped or quoted, of course), they fail to launch correctly. When launched, Firefox prompts to pick the profile because the name isn't quoted/escaped in the Exec line of the ffssb.*.desktop file.

@sebastianappler I'll submit a PR for this.


Fix https://github.com/virt-s1/rhel-edge/issues/61

/test-cs8-ng

/test-rhel-8-6-ng

/test-rhel-9-0-ng

/test-rhel-9-1-ng

Issue #87 fixed by this PR.


Feat: Fibonacci Series

@appgurueu @Panquesito7 @raklaptudirm I have implemented Fibonacci Series (Math/series) please review my PR

So I have to implement a infinite generator for Fibonacci numbers and use that in the first function of nthFibonacci function.

@appgurueu So I have to implement a infinite generator for Fibonacci numbers and use that in the first function of nthFibonacci function.

I think that would be the best solution, yes.

@Panquesito7 @raklaptudirm anyone review my code


feat: create Runs TES component

Description

Create TES create runs comp using design package
Fixes #155
Checklist

[ ] My code follows the contributing guidelines of this project.
[ ] I am aware that all my commits will be squashed into a single commit, using the PR title as the commit message.
[ ] I have performed a self-review of my own code.
[ ] I have commented my code in hard-to-understand areas.
[ ] I have updated the user-facing documentation to describe any new or changed behavior.
[ ] My changes generate no new warnings.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] I have not reduced the existing code coverage.

Comments

Hey @JaeAeich can you add the docs here in too & maybe close this pr https://github.com/elixir-cloud-aai/cloud-components/pull/146. It will help keep tes thing in one place & we can merge this after #157 & then this https://github.com/elixir-cloud-aai/cloud-components/pull/149#issuecomment-1793497597

@git-anurag-hub can you please check this PR  out, I have a couple of issues here:

For some reason I can't set @property or @state in this eslint throws error.
I am using any for almost everything which defeats the purpose of typescript and eslint shows alot of warnings.

Could you please help me on how should I proceed from here.

Hey @uniqueg will the TES API always malform if for a field that user didn't input anything, component sends in empty string?
for example:
{
  "description": "",
  "executors": [
    {
      "command": [
        "/bin/md5",
        "/data/file1"
      ],
      "image": "ubuntu:20.04",
      "workdir": "/data/"
    }
  "inputs": [
    {
      "path": "/data/file1",
      "url": "s3://my-object-store/file1"
    }
  ],
  "name": "",
  "outputs": [
    {
      "path": "",
      "type": "",
      "url": ""
    }
  ],
  "resources": {
    "cpu_cores": "",
    "disk_gb": "",
    "preemptible": false,
    "ram_gb": "",
    "zones": ""
  },
  "tags": {
    "PROJECT_GROUP": "",
    "WORKFLOW_ID": ""
  },
  "volumes": [
    ""
  ]
  ]
}

If so @git-anurag-hub should I reparse the form data and recursively remove all the empty fields?

@JaeAeich: I think that values/sections should be omitted rather than putting empty strings, unless the user specifically wants to put an empty string (but I can't really think of an actual use case for that). For example, if the task has no outputs, it not only makes no sense to add outputs with things like "path": "", or "type": "", it's also wrong - because there is no file with an empty string as a file name, and an empty string is not an allowed type. Same for inputs, resources, volumes, executors.$.workdir. Empty strings for "description" and "name" values may or may not work, depending on the implementation, but I wouldn't count on it. Empty strings for "tags" values should (I think) be supported by the specification (but please double check), so those should be fine (and if not, it's a compliance issue with the implementation).

Some more thoughts after looking at the component:

"Inputs", "Outputs" (and "Volumes") should be empty by default, given that they are optional:

I would add a * to "Executors" as well, given that at least one executor is required. Same is true for the outer "Command", which should be "Commands" (plural). For the same reason, it shouldn't be possible to remove the last executor (and command), which it currently is:

Resources ("CPU Cores", "Disk Gb" etc., including "Preemptible") should be grouped under a collapsible section "Resources", just like "Inputs" etc., and it should also be empty by default.
Even if a user adds input, output, volume, resources or additional executor fields and does not (or only partly) fills them out, the client shouldn't pass empty strings, but rather omit the empty string values from the request. The only exception is that all required fields for a given section MUST be filled in, or the user should otherwise delete the section.
I think a "Tags" section is missing. "Project Group" and "Workflow ID" should be grouped under that section, as predefined tags. But users should also be able to define custom tags (similar to specifying env variables).
In the "Executors", I'm not sure where that "false" comes from, between "Env" and "Image". Also, is "Workdir" really required? Please double check the specs.
As in WES, I think only the first word of the field names should be capitalized, e.g., "CPU cores" rather than "CPU cores". I would also rename some of the fields to make it clearer what we are dealing with. For example, "Working directory" instead of "Workdir", "Environment variables" instead of "Env", "Disk space (Gb)" instead of "Disk Gb".
Some of the other WES comments also apply, e.g., regarding the "Submit" button or the tooltips/field descriptions.

Again, none of these points should block the PR, but please create issues out of them.

For example, if the task has no outputs, it not only makes no sense to add outputs with things like "path": "", or "type": "", it's also wrong - because there is no file with an empty string as a file name, and an empty string is not an allowed type. Same for inputs, resources, volumes, executors.$.workdir

@git-anurag-hub would it make more sense to then maybe have an extra options like needed or something with which we can specify if we need the specific input or not. We will render fill button which user can then click if they want to fill it, this can be done for most of the non required fields ig.

For example, if the task has no outputs, it not only makes no sense to add outputs with things like "path": "", or "type": "", it's also wrong - because there is no file with an empty string as a file name, and an empty string is not an allowed type. Same for inputs, resources, volumes, executors.$.workdir

@git-anurag-hub would it make more sense to then maybe have an extra options like needed or something with which we can specify if we need the specific input or not. We will render fill button which user can then click if they want to fill it, this can be done for most of the non required fields ig.

Sounds good to me. But suggesting required rather than needed.

Even if a user adds input, output, volume, resources or additional executor fields and does not (or only partly) fills them out, the client shouldn't pass empty strings, but rather omit the empty string values from the request. The only exception is that all required fields for a given section MUST be filled in, or the user should otherwise delete the section.

Hey @git-anurag-hub leaving this here just to discuss as I don;t think we can have an abstraction of this at design level, if so we need to see what would be the best way to handle it package side.

Hey @uniqueg I have patched some of the concerns which could be scoped in this PR. Please take a look.

Component creates task runs fine mostly but for some fields it request malforms, I believe it to be a backend issue.

@git-anurag-hub Please review it, I have added types for and tried to minimize use of any. Let me know if there are changes.

Looks very nice, thanks a lot @JaeAeich :pray:


Test results on ScanNet

Hi,
Thank you for sharing your code!
Could you please also share the meshes generated by your method? similar to what you did for VoRTX ?
Thanks

Yup I can absolutely do that! It will take me a couple of days to get to.
Thanks for your interest!
-Alex


Return to ongoing meshtagger

Related to #70.

Provide a meta item to the project (/folder) to inform the front end that the tagger is running
How to detect that the tagger is no longer active and remove the meta item?

@TristanWright I think if I make the change we talked about in terms of having the mesh tagger task stay in the running state until it returns will provide a way to detect when the tagger is nolonger active.

@TristanWright what change has been made, the mesh tagger will stay in running state until it times out.

No changes yet on that branch, I'm going to commit it there though.


#155528617 Integrate database

What does this PR do?

Integrate PostgreSQL Database to persist data in a database
Write models (that conforms with database)

Description of Task to be completed?

PostgreSQL Database integration and 100% coverage tests
Update README with database integration

How should this be manually tested?

This can be tested using Swagger ui docs or POSTMAN

Pivotal tracker story
#155515767

Codecov Report

Merging #1 into develop will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff           @@
##           develop     #1   +/-   ##
======================================
  Coverage      100%   100%
======================================
  Files           10     10
  Lines          401    433   +32
======================================
+ Hits           401    433   +32

Impacted Files
Coverage Δ

api/validations.py
100% <100%> (ø)
:arrow_up:

api/models/business.py
100% <100%> (ø)
:arrow_up:

api/helpers.py
100% <100%> (ø)
:arrow_up:

api/models/user.py
100% <100%> (ø)
:arrow_up:

api/__init__.py
100% <100%> (ø)
:arrow_up:

api/models/review.py
100% <100%> (ø)
:arrow_up:

api/api.py
100% <100%> (ø)
:arrow_up:

api/models/token.py
100% <100%> (ø)

api/inputs/inputs.py
100% <100%> (ø)
:arrow_up:

api/docs/docs.py
100% <100%> (ø)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

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

Pull Request Test Coverage Report for Build 20

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

Totals

Change from base Build 2:
0.0%

Covered Lines:
433

Relevant Lines:
433

💛  - Coveralls


CON-119: Status API and smoke tests

This is an API change. It requires the following tasks to be completed:

[x] openapi.yaml updated (remember version bump)
[ ] /spec/8-service-apis.md to include new endpoints
[ ] Gherkin tests added or updated
[x] Mock application updated
[ ] 100% "patch coverage"
[ ] GitBook merge request referencing this change?

Fixes https://govstack-global.atlassian.net/browse/CON-119?atlOrigin=eyJpIjoiYTAzYWZkYTQxMGI4NGE3YTgzZTcyYzYxNDYwZTcwNDMiLCJwIjoiaiJ9

Here is a screenshot of what a nice test coverage report can look like:

So I'm gonna close this, as the work has become pretty unmerge-able over time :) I think this is 100% something that building blocks need, but it needs to be addressed across all building blocks.


Demo is not working

I loaded https://playnotebook.jsdata.org/demo and hit RUN on the first command and it sits in a loop.

This is the issue, dfd isn't set anymore


[BUG]  Google Analytics not working with content scripts

What happened?
I'm not able to use google analytics in content scripts.
I've followed the documentation, google analytics is working fine with popup.jsx but not with content.jsx
Version
Latest
What OS are you seeing the problem on?
Windows
What browsers are you seeing the problem on?
Chrome
Relevant log output
No response
(OPTIONAL) Contact Details
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate problems.

You will need to manually send analytic data to BGSW, since the content script will try to inject google analytic into the host webpage, and GA will assume analytic of the current host page.
This prompts us to think of analytic feature dedicated to web extension - let's move toward that direction.

@louisgv but BGSW doesn't have window in MV3, gtag has multiple references to window

For the original issue
import "https://www.googletagmanager.com/gtag/js?id=$PLASMO_PUBLIC_GTAG_ID"

triggers in content script, parcel/webpack issues?
content.ffb82774.js:62 Uncaught (in promise) Error: Cannot find module 'fNtPQ'
    at newRequire (content.ffb82774.js:62:19)
    at Function.newRequire (content.ffb82774.js:46:18)
    at runtime-c4b959552458ec6a.js:1:262

For anyone running into this, this is a possible solution

Download gtag.js
Patch it by adding following to top of file

// Manually created from https://www.googletagmanager.com/gtag/js?id=G-XXX on 21/06/2023
// this has been added as well, because gtag expect this to exist before it is loaded
window.dataLayer = window.dataLayer || [];
window.gtag = function gtag() {
  window.dataLayer.push(arguments)
}
window.gtag("js", new Date())

// Copyright 2012 Google Inc. All rights reserved.

@louisgv but BGSW doesn't have window. gtag has multiple references to window

Gtag has a manual event API that you can ping it instead of using their default script. It's indeed a bit of a hassle to setup

For the original issue
latest (v0.76.3)
doing in CS
import "https://www.googletagmanager.com/gtag/js?id=$PLASMO_PUBLIC_GTAG_ID"

triggers
content.ffb82774.js:62 Uncaught (in promise) Error: Cannot find module 'fNtPQ'
    at newRequire (content.ffb82774.js:62:19)
    at Function.newRequire (content.ffb82774.js:46:18)
    at runtime-c4b959552458ec6a.js:1:262

parcel/webpack issues?

Is this happening in both prod and dev build?

For the original issue
latest (v0.76.3)
doing in CS
import "https://www.googletagmanager.com/gtag/js?id=$PLASMO_PUBLIC_GTAG_ID"

triggers
content.ffb82774.js:62 Uncaught (in promise) Error: Cannot find module 'fNtPQ'
    at newRequire (content.ffb82774.js:62:19)
    at Function.newRequire (content.ffb82774.js:46:18)
    at runtime-c4b959552458ec6a.js:1:262

parcel/webpack issues?

adding script to CS will cause rejection on publish to chrome store.


about diffusers-0.27.2 plz！！！The third day of failed installation

I found that the automatically downloaded pytorch3D0.7.7 could not be adapted to py10/11. I finally manually downloaded 0.7.5 to solve this problem, but I couldn't solve the subsequent diffuses problem. I tried to switch various versions and the same error message appeared.  plz！！！！！
info：
(unique3d-py310) E:\Unique3D>python gradio_app.py --port 7860
Traceback (most recent call last):
File "E:\Unique3D\gradio_app.py", line 14, in
from app.gradio_3dgen import create_ui as create_3d_ui
File "E:\Unique3D\app\gradio_3dgen.py", line 7, in
from app.custom_models.mvimg_prediction import run_mvprediction
File "E:\Unique3D\app\custom_models\mvimg_prediction.py", line 8, in
from app.custom_models.utils import load_pipeline
File "E:\Unique3D\app\custom_models\utils.py", line 6, in
from custum_3d_diffusion import modules
File "E:\Unique3D\custum_3d_diffusion\modules.py", line 14, in
from custum_3d_diffusion.trainings import base, image2mvimage_trainer, image2image_trainer
File "E:\Unique3D\custum_3d_diffusion\trainings\base.py", line 14, in
from custum_3d_diffusion.custum_modules.unifield_processor import ConfigurableUNet2DConditionModel, AttnConfig
File "E:\Unique3D\custum_3d_diffusion\custum_modules\unifield_processor.py", line 8, in
from diffusers.loaders import IPAdapterMixin
ImportError: cannot import name 'IPAdapterMixin' from 'diffusers.loaders' (C:\Users\WS01\anaconda3\envs\unique3d-py310\lib\site-packages\diffusers\loaders_init_.py)
(unique3d-py310) E:\Unique3D>
(unique3d-py310) E:\Unique3D>python test_3d.py
Python executable: C:\Users\WS01\anaconda3\envs\unique3d-py310\python.exe
Python version: 3.10.14 | packaged by conda-forge | (main, Mar 20 2024, 12:40:08) [MSC v.1938 64 bit (AMD64)]
Sys path: ['E:\Unique3D', 'E:\Unique3D\pytorch3d-0.7.5', 'C:\Users\WS01\anaconda3\envs\unique3d-py310\lib\site-packages\diffusers\loaders', 'C:\Users\WS01\anaconda3\envs\unique3d-py310\python310.zip', 'C:\Users\WS01\anaconda3\envs\unique3d-py310\DLLs', 'C:\Users\WS01\anaconda3\envs\unique3d-py310\lib', 'C:\Users\WS01\anaconda3\envs\unique3d-py310', 'C:\Users\WS01\anaconda3\envs\unique3d-py310\lib\site-packages']
PYTHONPATH: E:\Unique3D\pytorch3d-0.7.5;C:\Users\WS01\anaconda3\envs\unique3d-py310\lib\site-packages\diffusers\loaders
PyTorch3D imported successfully.

I'm having the same issue,  ask if you solved it
"ImportError: cannot import name 'IPAdapterMixin' from 'diffusers.loaders'"

I'm having the same issue, ask if you solved it "ImportError: cannot import name 'IPAdapterMixin' from 'diffusers.loaders'"

I was met it but solved it in comfyui

I'm having the same issue, ask if you solved it "ImportError: cannot import name 'IPAdapterMixin' from 'diffusers.loaders'"

I was met it but solved it in comfyui

Wow, can you tell us the way?thanks

I'm having the same issue, ask if you solved it "ImportError: cannot import name 'IPAdapterMixin' from 'diffusers.loaders'"

I was met it but solved it in comfyui

Wow, can you tell us the way?thanks

I really want to help u guys but actucaully ,i dont know ........

"ImportError: cannot import name 'IPAdapterMixin' from 'diffusers.loaders'"
in the diffusers/loaders/__init__.py  , it has conditions for importing modules by is_torch_available() and is_transformers_available() . IPAdapterMixin is only imported if both conditions are met .
SOLUTION = install transformers
pip install transformers==4.39.3

"ImportError: cannot import name 'IPAdapterMixin' from 'diffusers.loaders'"
in the diffusers/loaders/__init__.py , it has conditions for importing modules by is_torch_available() and is_transformers_available() . IPAdapterMixin is only imported if both conditions are met .
SOLUTION = install transformers pip install transformers==4.39.3

thanks very much! This problem has been solved, but there is a new problem,  can you run successfully, normal reasoning?


feat: 🎸 use  to preview icons in Storybook

:tada: This PR is included in version 2.12.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Binding to the first free cpu, porting to FreeBSD

Hi!
thanks for the PR.
I am not happy with this:
#if defined(linux)
...
#else
...
as it assumes everything is BSD style.  Have you tested OSX, OpenBSD and NetBSD as well that you changes work there? If not reversing it to  "if FreeBSD" but be the better first step IMHO

No you re right it slipped my mind.

thanks!


ppc64le

Hi @jeking3,
There is some interest from boostorg/math to include tests for the ppc64le architecture. In the README file, it mentions "Supported combinations of architecture and OS:"  Could ppc64le be added?

Hi, yes, I think it could be.

I assume ubuntu focal ppc64el would be sufficient for this?

The most recent LTS Releases of Ubuntu:
Ubuntu 24.04 LTS (Noble Numbat) ›
Ubuntu 22.04.4 LTS (Jammy Jellyfish) ›
Ubuntu 20.04.6 LTS (Focal Fossa) ›
my general strategy about versions is to prefer the newest recent release, unless something is blocking that.     It offers the longest runway, before upgrading again is necessary.
1st choice, Ubuntu 24.04 Noble Numbat.
2nd choice, Ubuntu 22.04 Jammy.

Packages installation is more standard on ubuntu.  Most boost-ci scripts use ubuntu. Is multiarch support not available?

The original request came from boostorg/math and Matt Borland. I think you were chatting with him. If he believes alpine is acceptable, try it out.

This will be in v3.0.0

v3.0.0 published and includes ppc64le/el images


Editing existing object

I have an AR model that has some complex after_save calbacks/methods. I'd like to move the logic out into interactors but I'm not sure how to load attribute values so that form fields are correctly populated.
Is this possible with ActiveInteraction?

I don't think I fully understand your question.

Hi Aaron,
I mean populating a form for a typical edit/update action.
If I use @company = Company.find(1) in the edit action, then the form fields are populated with existing values.  Is it possible to do the same using an interactor like this:
class EditCompany < ActiveInteraction::Base
string :name
string :email
end
Something like:
def edit
@company = EditCompany.new(company: Company.find(1))
end
so that name and email fields are populated.

That should be possible. Check out this example: https://github.com/orgsync/active_interaction/issues/220#issuecomment-56574824

That's just what I was looking for. Thanks!

I added a note to #219 so that in the future this will be part of the readme.


Modules (packages) resolution?

I have following structure for project
build/
 app-bundle.js
client/
  node_modules/
    some-module
   app.js <= requires `some-module`
fuse.js

fuse.js is run config. homeDir is client
So this doesn't work. Package not found some-module, so from docs I see that fuse requires node_modules only in folder wher fuse.js is located? This is really strange to me.
Actually one should be able to have flexibile structure with multiple node_modules:
build/
 app-bundle.js
client/
  node_modules/
    some-module
  sub-app
    node_modules/
       ...
   app.js <= requires `some-module`
/node_modules
  other module
fuse.js

And modules should be resolve using nodejs resolution algorithm, and then some other features maybe introduced like https://webpack.js.org/configuration/resolve/#resolve-modules
I also tried for this case use modulesFolder: 'client/node_modules' but result is the same.

Seem to be a problem with cache. Will close for now.


TextField : fix resize when full width

This PR fixes the resizing problem when the TextField is full width by allowing only the height of the TextField to be resized.

@JoeyDjr Thanks for the changes, could you please update the description accordingly?

Codecov Report

Merging #533 (ccba8a4) into main (f6fa5e3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #533   +/-   ##
=======================================
  Coverage   96.73%   96.73%
=======================================
  Files          74       74
  Lines         950      950
  Branches      146      146
=======================================
  Hits          919      919
  Misses         29       29
  Partials        2        2

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Move test file to autoload-dev to fix composer update

Fix for #391, #394, #396

Meanwhile waiting for PR to be accepted. Here's a workaround by adding "repositories" and changing zizaco/entrust to use dev-middlewaretest-fix.
{
    ...
    "repositories": [
        {
            "url": "https://github.com/tuwannu/entrust.git",
            "type": "git"
        }
    ],
    "require": {
        ...
        "zizaco/entrust": "dev-middlewaretest-fix",
        ...
    },
    ...
}

Hi, I am not sure I've understood everything here! But I've added the repositories array as well as the require middlewaretest-fix and done composer update, composer dump-autoloader but the problem persists! :/

This pull request has already been merged. There is no need to put a workaround on this. Simply require
"zizaco/entrust":"dev-master"

in your composer.json, without any additional changes I mentioned in this pull request, should work fine.

Ok let's see I am still getting the same error "ReflectionException in Container.php line 737:
Class App\Http\Zizaco\Entrust\Middleware\EntrustRole does not exist"
{
"name": "laravel/laravel",
"description": "The Laravel Framework.",
"keywords": ["framework", "laravel"],
"license": "MIT",
"type": "project",
"require": {
"php": ">=5.5.9",
"laravel/framework": "5.1.",
"intervention/image": "^2.3",
"zizaco/entrust": "dev-master"
},
"require-dev": {
"fzaninotto/faker": "~1.4",
"mockery/mockery": "0.9.",
"phpunit/phpunit": "~4.0",
"phpspec/phpspec": "~2.1"
},
"autoload": {
"classmap": [
"database"
],
"psr-4": {
"App\": "app/"
}
},
"autoload-dev": {
"classmap": [
"tests/TestCase.php"
]
},
"scripts": {
"post-install-cmd": [
"php artisan clear-compiled",
"php artisan optimize"
],
"pre-update-cmd": [
"php artisan clear-compiled"
],
"post-update-cmd": [
"php artisan optimize"
],
"post-root-package-install": [
"php -r "copy('.env.example', '.env');""
],
"post-create-project-cmd": [
"php artisan key:generate"
]
},
"config": {
"preferred-install": "dist"
}
}
composer update

php artisan clear-compiled
Loading composer repositories with package information
Updating dependencies (including require-dev)

Removing predis/predis (v1.0.3)
Updating zizaco/entrust (dev-middlewaretest-fix 8d88ff4 => dev-master 3b41a8e)
The package has modified files:
M src/Entrust/Middleware/EntrustRole.php
Discard changes [y,n,v,d,s,?]? y
Checking out 3b41a8ec0cdba8400eab344f919291bcc59c0115

Writing lock file
Generating autoload files

php artisan optimize

Your composer.json file looks alright.
From the error message, it should not be trying to find App\Http\Zizaco\Entrust\Middleware\EntrustRole, but rather Zizaco\Entrust\Middleware\EntrustRole.

Aliases
'Entrust'   => Zizaco\Entrust\EntrustFacade::class,
providers
Zizaco\Entrust\EntrustServiceProvider::class,
protected $routeMiddleware = [
    'auth' => \App\Http\Middleware\Authenticate::class,
    'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,
    'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class,
    'role' => Zizaco\Entrust\Middleware\EntrustRole::class,
    'permission' => Zizaco\Entrust\Middleware\EntrustPermission::class,
    'ability' => Zizaco\Entrust\Middleware\EntrustAbility::class,
];

I actually solved the problem and for future reference there needs to be a \ before the Zizaco i.e
protected $routeMiddleware = [
'auth' => \App\Http\Middleware\Authenticate::class,
'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,
'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class,
'role' => \Zizaco\Entrust\Middleware\EntrustRole::class,
'permission' => \Zizaco\Entrust\Middleware\EntrustPermission::class,
'ability' => \Zizaco\Entrust\Middleware\EntrustAbility::class,
];
Rather than
protected $routeMiddleware = [
'auth' => \App\Http\Middleware\Authenticate::class,
'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,
'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class,
'role' => Zizaco\Entrust\Middleware\EntrustRole::class,
'permission' => Zizaco\Entrust\Middleware\EntrustPermission::class,
'ability' => Zizaco\Entrust\Middleware\EntrustAbility::class,
];
That's just basic namespacing but if anyone else find themselves in this position it's probably because you just copy pasted the code from the git page like myself :)

@Profeten +1

@Profeten +1


(PUP-6819) Use packaged cert when attempting to contact rubygems

Since the rubygems certificate update, Windows boxes provisioned by
beaker-hostgenerator have been unable to connect to rubygems due to a
bad cert. This adds a valid cert to the environment when calling out to
rubygems.

CLA signed by all contributors.

Per conversation in PA-620 I think there's a possibility we haven't solved the whole issue with this as users trying to install gems on previous PE versions as part of support module install instructions (ie https://forge.puppet.com/puppetlabs/azure) are no longer able to since the cert switch? I'm just commenting that here to suggest we hold on merging this PR until the conversation in PA-620 is resolved - not trying to bifurcate the conversation

Closing this in favor of the alternative solution proposed in PA-620


No real speedup

I had hoped this would help make generation faster on my P40. Unfortunately it only seems to add a few seconds to generation time.
I made the model work from 512-768 and tried converting in both fp16 and fp32. A matter of 21 sec vs 24 sec for tensort to make a 704x704 image.
I will see if there's some difference on my 3090. I at least hope there is. OS was linux.
So far got a bigger speedup from getting rid of that ancient transformers and accelerate version pushed via requirements.

same on V100, same speed as without tensorrt.

Adding shared.sd_model.model.diffusion_model = current_unet after current_unet.activate() will enable TrtUnet and speed it up.


New Endscreen for victories bricks the bot.

The beginning loop now does not exit out of the victory screen for AI battles, since the bot is using preset x,y values it should be an easy fix to add an extra couple of values for the bot to click on when the match ends.

So did Riot change the menus up?
I unfortunately won't have access to a windows PC for a while. If it is just a matter of adding values, that can be done here. Feel free to open a PR :)

so what are the correct values to be add there? can you update those lines
to be replace with here? Thanks
On Thu, 12 Oct 2023 at 05:11, Matija Ojo @.***> wrote:

So did Riot change the menus up?
I unfortunately won't have access to a windows PC for a while. If it is
just a matter of adding values, that can be done here
https://github.com/MOj0/LoR-Bot/blob/master/Bot.py#L261. Feel free to
open a PR :)
—
Reply to this email directly, view it on GitHub
https://github.com/MOj0/LoR-Bot/issues/32#issuecomment-1758548867, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABDO2PYOIDWKIAUNBRHOSDDX64DQZANCNFSM6AAAAAA54MAEOY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

So did Riot change the menus up? I unfortunately won't have access to a windows PC for a while. If it is just a matter of adding values, that can be done here. Feel free to open a PR :)

they added another screen after the old ones it just requires you to hit another continue button but for now but gets locked up there unfortunately

i sent you a screen shot of the new screen on discord

So the way to do that is pretty straightforward. The game is running at 1920x1080 on fullscreen. You just take a screenshot of the screen, get the x,y location of the button and divide x by 1920 and y by 1080. Now you should get a tuple with values between 0 and 1 (eg. (0.76, 0.86)). Now all you have to do is insert that tuple in the vals_ai list, in code, which I linked, at the right position, depending on when this buttons occurs in the menu sequence.

So the way to do that is pretty straightforward. The game is running at 1920x1080 on fullscreen. You just take a screenshot of the screen, get the x,y location of the button and divide x by 1920 and y by 1080. Now you should get a tuple with values between 0 and 1 (eg. (0.76, 0.86)). Now all you have to do is insert that tuple in the vals_ai list, in code, which I linked, at the right position, depending on when this buttons occurs in the menu sequence.

not home atm but got this in teamview for you. dead center of new button is this
Screen:	1414, 995
Window:	1414, 995
Client:	1414, 995 (default)
Color:	C5B8A7 (Red=C5 Green=B8 Blue=A7)

(0.73, 0.92)
thats what im seeing on my end

i submitted the PR adding that xy do i have to do a pr for a line other than 261?

There are no PRs open atm.
The way to test if it works, is to simply run a game. If it clicks through the menus correctly then it works and we can merge the PR.

There are no PRs open atm. The way to test if it works, is to simply run a game. If it clicks through the menus correctly then it works and we can merge the PR.

i did the req again let me know if i did that correct

the pr diddnt fix it any other lines? i notice that line has to do with deck selection rather than end screen is that something to do with it

brother you there?


Hsl

Current coverage is 100% (diff: 100%)

Merging #70 into master will not change coverage

@@           master   #70   diff @@
===================================
  Files          34    36     +2
  Lines         152   190    +38
  Methods         0     0
  Messages        0     0
  Branches        0     0
===================================
+ Hits          152   190    +38
  Misses          0     0
  Partials        0     0

Powered by Codecov. Last update 6257c31...83a4a33


feat: add element concept to base field package ( PROOF-748 )

Rationale for this change
The base/field package now has an element concept and a minimal example_element component. The element concept will allow field operations done with elements in Montgomery form to be written generically. These field operations currently exist in the field12 package group and depend on the f12t::element.
What changes are included in this PR?

An element concept is added to the base/field package that is similar to the base/curve/element concept.
A minimal example_element component is added to the base/field package that is similar to the base/curve/example_element component.
Branching is removed from the base/field/subtract_p component.

Are these changes tested?
Yes

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


Fix merge_root_options

Codecov Report

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

@@            Coverage Diff             @@
##           master     #448      +/-   ##
==========================================
- Coverage   73.29%   73.28%   -0.02%
==========================================
  Files         382      382
  Lines       17271    17273       +2
==========================================
- Hits        12659    12658       -1
- Misses       4612     4615       +3

Impacted Files
Coverage Δ

vast/query_options.hpp
61.53% <0%> (-7.7%)
:arrow_down:

src/system/default_configuration.cpp
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


ESlint 9

[x] Convert vue2 config
[x] Convert vue3 config
[ ] Convert nuxt2 config
[ ] Convert nuxt3 config
[x] Update package-lock.json
[x] Update configuration to mention each config
[x] Add automated tests
[x] Test configs in AT project

Dropped Nuxt 2 support (not possible anymore, use the vue2 config for that if necessary).
Nuxt 3 has a module that configures eslint based on the project settings, which is more powerful than we can do with this package. Added instructions on how to integrate our overrides with the nuxt generated config.
Tested everything in the AT frontend monorepo, which has plain javascript, vue2, typescript and vue 3/nuxt subprojects.

really nice work, love the testing approach
only remarks that I had are about consistently naming ESlint, not sure if we want to 'pull this straight' now

I believe I now consistently call it ESLint in the README.

Keeping this open until I'm completely done with the AT follow up, to make sure I don't need to follow up with a fixup PR/release.


Changing font size

Hi,
my users are requesting larger fonts on the value readouts, I can't seem to change the size using the theme   baseFontFamily: "sans-serif", setting. Should I be able to pass a font-size attribute somehow?

Svelte Tweakpane UI's theming system exposes the same variables that are used in Tweakpane's underlying theme customization implementation, which does not include font-size. There's a way to directly override the CSS in Tweakpane, discussed here, but I'm not sure how far it can be pushed before layouts start to break.
As an alternative, Svelte Tweakpane UI adds the scale prop on the <Pane> component, which makes it easy to increase the size of the entire pane using CSS transforms, and it looks great since Tweakpane is all vectors.
Also, I've also noticed that especially on Windows, the default monospace typeface looks very anemic and can be hard to read, swapping in a slightly heavier font can improve legibility even at the same size.

ok, thanks!


Update Pages “FoundTermitesPage”

Automatically generated by Netlify CMS

👷 Deploy Preview for chic-shortbread-66a66b processing.

Name
Link

🔨 Latest commit
c3b0fae812b72fa7ed74104ec62a9e4517e695dd

🔍 Latest deploy log
https://app.netlify.com/sites/chic-shortbread-66a66b/deploys/6552b77f583b260008a1238c


rtx3090 tf2.4.1 error with single machine multi-card

strategy is tf.distribute.MirroredStrategy, I train the model on two cards, it reports that
F tensorflow/stream_executor/cuda/cuda_driver.cc:1289] Check failed: context != nullptr success should entail non-null context.
how can I solve it?

@jiangjing1989,
In order to reproduce the issue reported here, could you please provide the complete code and the dataset you are using. Thanks!

Also, please take a look at issue #46851 with a similar error log and check if it helps. Thanks!

@jiangjing1989,
In order to expedite the trouble-shooting process, could you please provide the following information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary):
TensorFlow version (use command below):
Python version:
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:

along with the complete code and the dataset you are using. Thanks!

my environment is :
Ubuntu 18.04.5 LTS
python3.8
rtx3090
conda install cudatoolkit=11.0
conda install cudnn=8.0.5
pip3 install tensorflow_gpu-2.4.1-cp38-cp38-manylinux2010_x86_64.whl
pip install tfa-nightly
code address is https://github.com/jiangjing1989/asr_test/tree/master/my, the start script if train_sublm.py.
I run the code with RTX2080 successfully.

Also, please take a look at issue #46851 with a similar error log and check if it helps. Thanks!

sorr, tensorflow version is tf_nightly_gpu-2.5.0.dev20210130-cp38-cp38-manylinux2010_x86_64.whl

Also, please take a look at issue #46851 with a similar error log and check if it helps. Thanks!

sorry again, cudnn version is 11.2

@jiangjing1989,
Currently TensorFlow is not compatible with CUDA 11.2.
TF v2.4 and TF-nightly are built and tested against CUDA 11.0. Could you please check if you are facing the same error with CUDA 11.0 and cuDNN 8. Thanks!

@jiangjing1989,
Currently TensorFlow is not compatible with CUDA 11.2.
TF v2.4 and TF-nightly are built and tested against CUDA 11.0. Could you please check if you are facing the same error with CUDA 11.0 and cuDNN 8. Thanks!

Thanks. With CUDA 11.0 and cuDNN8.0.2, it run successfully.