Bug: Application error: Value "Email" does not exist in "IdentityType" enum. Did you mean the ...

Error message: Value "Email" does not exist in "IdentityType" enum. Did you mean the enum value "EMAIL"?
Error stack:
GraphQLError: Value "Email" does not exist in "IdentityType" enum. Did you mean the enum value "EMAIL"?
    at Le.parseValue (altair://-/main.js:1:2905097)
    at E (altair://-/main.js:1:21283)
    at E (altair://-/main.js:1:20180)
    at altair://-/main.js:1:20595
    at Array.map (<anonymous>)
    at T (altair://-/main.js:1:21530)
    at E (altair://-/main.js:1:20478)
    at altair://-/main.js:1:21866
    at Array.forEach (<anonymous>)
    at M (altair://-/main.js:1:21775)

When did this error occur? And does it re occur, or it happened only once?
Please provide some helpful screenshots of the bug
Version 5.0.17

When does this error occur? And does it re occur, or it happened only once?


Guest hotspot password

Any possibility of adding support for the guest hotspot password as well?  I believe it would be a PUT rest call to "rest/setting/guest_access".
Also I was curious if you've ever thought of using this module here instead of rolling your own code to interface with the controller?  That module exposes most of the controller api's.
I'll try and fork this when I have a minute to attempt adding the functionality I mentioned above but thought I would ask in the meantime.  Thanks!

Any possibility of adding support for the guest hotspot password

Not having used the hotspot manager much, it didn't even occur to me. I think I worked out the rest call code. All that's left is to figure out how to expose this option. The hotspot doesn't seem to be SSID specific, so the current HA services don't really work. I think the most sensible thing would be another service, specific to each host+site/coordinator/controller combo, to change the guest access password. Hmmm. I'll try to work on this soon; work life is in crunch mode right now.

instead of rolling your own code

To be honest, this project has been a way for me to learn Python. Doing it this way may not be the fastest, but it's definitely the most beneficial (to me). I suppose one of these days I should stop re-inventing the wheel . . . eventually.

I just pushed a pre-release version with hotspot password support. Would you be available to test the new service?

So appreciative of your work on this.  I didn't realize you were going to have this so quick that I ended up writing a pyscript to do this.  Guess it was a good excuse to learn more about pyscript but using this is much simpler.
I tested the new version and so far things look great.  I've tested the hotspot password both using the developer tools and a hard coded password and via an automation where I'm setting the password using a template value.  Both work great.  Haven't tested any other functionality but at least the hotspot password looks good.

Glad it's working well. Thanks for the feature suggestion!


NETOBSERV-857 After some time, it fails to retrieve flows

Reload HOST token from file on every query

/ok-to-test

/lgtm
up to you to do what I suggested above or not .. this isn't super critical

/label qe-approved
Verified no longer running into the cert issue with this change when authToken: HOST is set.

@jpinsonneau are we good to merge?

/approve


Holdem

Desc: 1. Created score detector for holdem game
2. Updated Card information
3. Added more params in HoldemTable
Test: N/A

LGTM


How do we make breaking changes immediately visible

We use semver (and once goes in, this will be meaningful). We are in "initial development" which is defined as

Anything MAY change at any time. The public API SHOULD NOT be considered stable.

That's accurate, but maybe not very convenient for users. So we should discuss how we want to highlight meaningful breaking changes. Or if we want to soon move to a major version release and leave the development space.

Now that we have our auto-release process set up, we can achieve this using our pr-minor-breaking and pr-major-breaking release labels (see also our template .autorc here). These should automatically organize breaking change PRs under a dedicated section in the changelog.


Constants without boilerplate

Naturally, I use attrs all the time for classes without boilerplate. But I also
use it for constants.
A common situation:
# I need some constants to get the magic strings out of my code.

KING = 'king'
QUEEN = 'queen'
ROOK = 'rook'
BISHOP = 'bishop'
KNIGHT = 'knight'
PAWN = 'pawn'

WHITE = 'w'
BLACK = 'b'

# But I also want to group the constants up in various ways.

PIECES = (KING, QUEEN, ROOK, BISHOP, KNIGHT, PAWN)
COLORS = (WHITE, BLACK)

I could bundle them inside trivial classes:
class Pieces:
    KING = 'king'
    etc

class Colors:
    etc

But that won't give me an easy way to iterate over the collections. And it
won't have as many conveniences as attrs-based classes.
So I wrote a utility function to create an attrs class and return an instance of it.
Pieces = constants('Pieces', 'KING QUEEN ROOK BISHOP KNIGHT PAWN')

if p == Pieces.KING:
    ...

By default, that instance is frozen, so it's a good vehicle for constants.
Pieces.KING = 'foo'   # Fails.

It's informative when printed:
Pieces(KING='KING', QUEEN='QUEEN', ROOK='ROOK', BISHOP='BISHOP', KNIGHT='KNIGHT', PAWN='PAWN')

It is directly iterable and convertable to other collections:
pairs = list(Pieces)
d = dict(Pieces)

for name, val in Pieces:
    ...

It supports various aesthetic/naming styles:
NAMES = 'KING QUEEN ROOK BISHOP KNIGHT PAWN'
names = NAMES.lower()

Pieces = constants('Pieces', names, value_style='upper')  # Pieces.king = 'KING'
Pieces = constants('Pieces', NAMES, value_style='lower')  # Pieces.KING = 'king'
pieces = constants('pieces', NAMES, value_style='lower')  # pieces.KING = 'king'

It supports enum-like behavior:
Pieces = constants('Pieces', names, value_style='enum')   # king = 1, queen = 2, ...
Pieces = constants('Pieces', names, value_style=(25, -5)) # king = 25, queen = 20, ...

The user can control the constant values precisely by supplying a dict:
Pieces = constants('Pieces', dict(king=0, queen=9, rook=5, bishop=3, knight=3, pawn=1))

Or by supplying a callable taking an INDEX and NAME:
f = lambda i, name: '{}-{}'.format(name, 10 - i)
Pieces = constants('Pieces', names, value_style=f)

If this functionality is of interest to the attrs developers I will submit a
proper PR, with code, tests, and docs.
Thanks for taking a look at this.

Why not use Enum from stdlib?

Well, that's by design… if you are using constants, you want all code to use the constants and not the underlying values, which, if changed, would make the code more fragile.
I've written a fair bit (de-)serialization code (or other code that interoperates with some external thing) where you are constantly converting to/from values, and even in that case, it's useful (especially with typing) to ensure you are using the constants internally and values only when crossing a boundary.
Of course you might think that's all a waste of time, but I'm not sure addressing that is in Attrs' problem domain.  Or I'm not thinking of your use case well.  A Chess game isn't good example, I'm pretty sure…

Thanks for taking the time to consider this. I published the short-con library separately. Closing the issue.


Correct union hash

This pull request resolves #3851.

Nice! what behavior is changed? I can't guess how the bug is fixed 😵

Though it was already merged, as a reply, the PyTuple::iter returns PyResult and it is Result. The Result implements IntoIterator so the PyFrozenSet::from_iter doesn't work well. It may expect PyFrozenset::from_iter(vm, [1, 2]) but it was PyFronzenSet::from_iter(vm, [[1, 2]]).


Cross(X) shape added

Closes #52
Feature added #52
Please review and merge

Done with the changes @Sachin-chaurasiya  Please review and merge


Limit to size of Redis hash? Error when hget'ing

This may be a gloss issue, but happened using Aleph so posting here.
I scraped some html from a web site and stored the raw escaped HTML into a redis hash.
Some of the values are quite large, but Redis can handle objects of this size. But I ran into an error when using "hgetall" with aleph
(apply hash-map @(@r [:hgetall "medications:14" ]))

Feb 16, 2012 8:04:17 PM sun.reflect.NativeMethodAccessorImpl invoke0
SEVERE: Unhandled error in Netty pipeline.
java.lang.AssertionError: Assert failed: success
	at gloss.data.bytes$wrap_finite_block$fn__4881$fn__4882.invoke(bytes.clj:75)
	at gloss.core.protocols$compose_callback$reify__4740.read_bytes(protocols.clj:58)
	at gloss.data.bytes$wrap_finite_block$fn__4881.invoke(bytes.clj:70)

The full stacktrace and a copy of the hgetall from redis-cli is below it:
https://gist.github.com/1dd54e07c78de7c7f60d
Is there a limit to how much data can be received in a single request?

There's no limit to how big a response can be, but apparently an empty string formatted as a bulk response brings the parser to its knees (the 28th key, in your case).  A fix will be forthcoming soon.

Thats right it was the empty field. Confirmed it on my end.
Funny how it turned out to be the opposite (small value instead of large).

Any timeline for a fix?
I hate making requests like this without being able to contribute a patch. But this is a show stopping bug for me since I work with unpredictable data that frequently comes with blank fields.
I would switch to another library temporarily, but Aleph is significantly better than the other Clojure libraries for working with Redis.

I've been planning to fix it today.  Sorry for the delay, I've been occupied this weekend.

I've checked a fix into gloss, and updated alpha2-SNAPSHOT to point to the latest version.  Sorry again for the delay.

thanks, appreciate it


Serve UI config from the backend

Following up on https://github.com/jupyterhub/binderhub/pull/1017#issuecomment-561082718. In particular the comment about "reduce duplication".
A possible way to do that which I've seen in other projects is to add an endpoint to the backend from which the UI loads the config. We'd have an endpoint like binder.example.com/_config which returns a JSON which is then used to configure the dropdown and labels on the main page.
The endpoint at /_config has access to the whole config of the binder hub like for example which repo providers are configured etc.
Things to do if you'd like to work on this or even just make a small prototype to see how it would work:

add a new endpoint at something like /_config that serves up a static config
add new code  to our JS which loads the config
transfer the labels currently configured in the JS to the repo provider classes
modify the /_config endpoint to dynamically generate the JSON it serves from the repo provider classes

Addressing the problem that we have some duplication between repo2docker and BinderHub is something I'd tackle in a new PR and not as part of this one.

I think it's a great idea - you could imagine a BinderHub provider that wants to have a drop-down item that is institution-specific. This could be a way that they can easily configure their hub to do so without needing to fork the BinderHub codebase

Closing as resolved by #1038!


Uncaught Error: ENOENT: no such file or directory, lstat '~/AppData\Local\atom\app-1.40.1\ Templa...

[Enter steps to reproduce:]

...
...

Atom: 1.40.1 x64
Electron: 3.1.10
OS: DOMINIK-PC
Thrown From: Atom Core
Stack Trace
Uncaught Error: ENOENT: no such file or directory, lstat 'C:\Users\WebDeveloper\AppData\Local\atom\app-1.40.1\ Templates usw'
At fs.js:143

Error: ENOENT: no such file or directory, lstat 'C:\Users\WebDeveloper\AppData\Local\atom\app-1.40.1\ Templates usw'
    at Proxy.realpathSync (fs.js:1744:7)
    at Proxy.fs.realpathSync (ELECTRON_ASAR.js:335:40)
    at TreeView.moveEntry (~/AppData/Local/atom/app-1.40.1/resources/app/static/<embedded>:14:1009306)
    at TreeView.onDrop (~/AppData/Local/atom/app-1.40.1/resources/app/static/<embedded>:14:1016235)
    at HTMLDivElement.<anonymous> (~/AppData/Local/atom/app-1.40.1/resources/app/static/<embedded>:14:989866)

Commands
     -2:33.6.0 core:backspace (input.hidden-input)
     -2:32.5.0 core:save (input.hidden-input)
     -2:15.9.0 tree-view:remove (div.header.list-item)
     -2:01.6.0 tree-view:duplicate (li.file.entry.list-item.selected)
     -1:58.8.0 core:select-all (input.hidden-input)
     -1:56.2.0 core:confirm (input.hidden-input)
     -1:50.1.0 core:undo (input.hidden-input)
  7x -1:49.4.0 core:close (input.hidden-input)
     -1:35.3.0 core:backspace (input.hidden-input)
     -1:34.4.0 snippets:next-tab-stop (input.hidden-input)
     -1:34.4.0 snippets:expand (input.hidden-input)
     -1:34.4.0 editor:indent (input.hidden-input)
     -1:32.6.0 editor:delete-to-beginning-of-word (input.hidden-input)
     -1:32.1.0 core:backspace (input.hidden-input)
  2x -1:19.9.0 core:save (input.hidden-input)
     -1:01.9.0 tree-view:show-in-file-manager (div.header.list-item.project-root-header)

Non-Core Packages
atom-beautify 0.33.4
atom-i18n 0.21.0
atom-material-syntax 1.0.8
atom-material-syntax-dark 1.0.0
atom-material-syntax-light 0.4.6
atom-material-ui 2.1.3
atom-minify 0.8.0
atom-path-intellisense 1.1.1
atom-ternjs 0.20.0
auto-id-class 0.7.1
autocomplete-html-entities 0.2.0
autocomplete-json 5.5.2
autocomplete-paths 2.12.2
autocomplete-project-paths 2.2.0
bezier-curve-editor 0.7.2
chrome-color-picker 0.8.0
css-snippets 1.1.0
css-spy 0.6.0
emmet 2.4.3
file-icons 2.1.35
hyperclick 0.1.5
improved-chester-atom-syntax 0.3.0
jQuery 1.2.6
jquery-snippets 11.0.0
jsdelivr 1.0.1
one-dark-material-syntax 1.0.3
pigments 0.40.2
platformio-ide-terminal 2.9.4
puddletown-css-snippets 1.1.0
rain-syntax 2.1.2
rocket-dark-syntax 1.0.0
snow-dark-material-syntax 0.1.1

Thanks for contributing!
We noticed that this looks like a duplicate of https://github.com/atom/tree-view/issues/1282 so you can subscribe there for updates if you'd like.

Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.


Disable Monitoring via detecting Condition

Problem:
Can't completely clean up after disabling cluster monitoring, as the
MonitoringStatus may be nil before disabling Monitoring operation
Solution:

Detect the status of MonitoringEnabled condition
Fill MonitoringStatus before Prometheus ready checking

Issue:
https://github.com/rancher/rancher/issues/19645

LGTM


Allow hrtime to be globally patched

This fixes #20.
Replaces #21 (just to make the PR from a fix-branch instead of YR/master

@myrne Have you had a chance to look at this? Is it possible to have this merged in?


Dropdown and Menu reimplementation

Dropdown component has issues in a similar fancy to #1169. Passing the source es problematic and it's way better to just allow rendering custom items so you can filter them, add separators, etc. Also it doesn't conform very well the spec since the selected option should be placed over the item, etc.
Also, this will come with a Menu reimplementation too. The Dropdown may be consider as an Input with  a caret that opens a Menu with a set of selectable options. This will be a good moment to implement #249.

Hey @javivelasco, How's this going? Would you like some help with it?

@javivelasco is there any progress on this? I'm interested in #886 but just multilevel inline, with ability to fold inactive submenus (carousel-like folding would be nice).
In terms of composability of components I suggest it to be as following:
<Menu>
  <MenuItem value="Hello">
     <Menu minimized={false}>
       <MenuItem value="Hello inner" />
     </Menu>
  </MenuItem>
</Menu>

Visually inner elements should have a margin in the left.
Currently I can achive this with (and some extra styling):
<Menu>
  <MenuItem value="Hello" />
  <Menu>
    <MenuItem value="Hello inner" />
  </Menu>
</Menu>

I use Menu for Navigation menu in Sidebar. Please drop me a note if this is the wrong usage pattern.

@dalefrancis88 @olegstepura Hi guys, I couldn't progress on this yet but I want to give you an update on what's going on and why I wasn't answering issues this past week. I'm currently restructuring the project for a POC of style-agnostic components. For this POC I want to implement a complex component and I chose the Calendar. I have it ready with Airbnb styles (https://twitter.com/javivelasco/status/831570140265340929) and also I have an implementation of the ripple in 4 different libraries (https://twitter.com/javivelasco/status/829770165847986176). I think I can get a react-native version too so I'm currently working on that to set a pattern. Also the project would be a monorepo for some different packages: react-toolbox-core, react-toolbox-web...
I want to set all of this up before rewriting those components so it can be done in this fancy. Truth is I have an implementation of the Dropdown and Autocomplete in other project so after the POC is ready it would not take too long. I'm afraid right now the best help I can get is with issues, once the pattern is set with the POC I can get more code help.
Hope it sounds promising!

@javivelasco Which styling library will react-toolbox-web v.2.0 final will be using? Will it continue to use postcss' cssnext with css-modules?

@javivelasco That sounds good, keep us informed :)
I am a bit confused though, what exactly would you like me to help with?

@olegstepura Styled Components looks like the best for me. I'm going to show the idea with the POC but the customization strategy is near to perfect and I'm making some tests for react native too. Will try to get it ready during this week
@dalefrancis88 I'm missing a communication channel for this kind of announcements. I'd like to warn people when I'm a bit off and can't pay too much attention to issues, I think Github is missing this. About the help: labeled issues are ready to be fixed, it would be helpful if you can take a look on them. Do not put too much effort on the Dropdown and Autocomplete because they need to be completely re-written. The rest of components would look pretty similar with this new strategy so any fix would be great. Also, I appreciate if you can help answering issues and questions about configuration.
Do you guys think we should release the current dev branch as stable with PostCSS and call the future version 3.0? I don't wan't people to be confused because we'd release a 2.0 and start speaking about 3.0 the same day :/

That's a pretty normal strategy, it's a normal thing to do.
On Mon, Feb 20, 2017 at 12:12 PM, Javi Velasco<EMAIL_ADDRESS>wrote:

@olegstepura https://github.com/olegstepura Styled Components looks
like the best for me. I'm going to show the idea with the POC but the
customization strategy is near to perfect and I'm making some tests for
react native too. Will try to get it ready during this week
@dalefrancis88 https://github.com/dalefrancis88 I'm missing a
communication channel for this kind of announcements. I'd like to warn
people when I'm a bit off and can't pay too much attention to issues, I
think Github is missing this. About the help: labeled issues are ready to
be fixed, it would be helpful if you can take a look on them. Do not put
too much effort on the Dropdown and Autocomplete because they need to be
completely re-written. The rest of components would look pretty similar
with this new strategy so any fix would be great. Also, I appreciate if you
can help answering issues and questions about configuration.
Do you guys think we should release the current dev branch as stable with
PostCSS and call the future version 3.0? I don't wan't people to be
confused because we'd release a 2.0 and start speaking about 3.0 the same
day :/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/react-toolbox/react-toolbox/issues/1170#issuecomment-280965856,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0iTdFcMC4FIqP8zQOCzMUvihes2qIxks5reOh_gaJpZM4LqzCr
.

@olegstepura, If 2.0 was released it would mean that people could use and test it. Any updates could be merged into 3.0
That being said, don't forget that major version increments should be reserved for breaking changes so if its not a breaking change to use the new version it may not need to be 2.0

It's breaking to 1.0 because we switched from SASS to PostCSS. The real issue about merging from that 2.0 to potential 3.0 is that the project would be restructured meaning constant conflicts. Maybe it could be released after this restructure.

Well, I think 2.0, since it's already beta, should be released with postcss. Not sure if selection of styled components is great, but if it solves issues like #1240, it actually is. This case 3.0 can be a split + another change of styling lib.

Ok, I will push the POC and then release 2.0 tagged as stable. I think it makes sense. The only issue is that we need to fix the documentation project which is not working in dev atm

@olegstepura it's working so perfect. You'll see 💃

@javivelasco issues appear when people start testing 2.0. I don't think it's ready to be released as stable in current state.
Since there is no publicly visible progress on your POC no one can assits you knowing that all the things will change again. Maybe it's a good idea to create a public branch or introduce separate repos with your POC?

Sorry @olegstepura I had some personal issues and couldn't work on anything at all. Will try to finish the POC and push it into a PR that doesn't need to be merged immediately. The main idea is to split react-toolbox into multiple packages. One of those packages can be the 2.0 version and everything else can evolve in the same repository and released as different packages.
What do you think about that?

@javivelasco here are my thoughts on the project (may not be well structured, but hopefully clear):

I think a split to core + dom is good way to go (well, according to my thoughts below, it may be a goal for 2.0 already). native should be a future goal, not current.
Current version with postcss seem to be kind of limited. If you insist that styled-components solve some core issues (like #1240) which postcss cannot (and that styled-components look amazing), it may be good idea to actually release 2.0 with styled-components (only if the switch will not take much of effort for end users and for you). As far as I can tell there is no styling hardcoded in components, so it may happen that a switch to styled-components is easy (and is actually a routine work). Also there is #1177 which is actually a stress test for current styling lib.
There is a lot of issues opened for current beta. This all need to be fixed before the first release candidate. Also I believe some more will appear before the release (and should be fixed as well).
Current release cycle is too slow. Some issues are fixed but not released and are reported again. It would definitely make sense to release more often.
Nothing should be developed privately. When there is some work going, project looks alive (!) and people may help and discuss the further way to evolve. Git has branches! ;)
This one doubtful, but maybe there is a need to add some more contributors to the organization.

Thanks for that comment @olegstepura! Let me comment over the same bullet points:

I agree, native is definitively a future goal but for this first POC on agnostic components I wanted to make sure it is possible to write components for both native and web with any style. I'm very very close to finishing it but, after that, we should go first for web, then native.
Styled Components fixes those issues for sure! Generating styles from CSS is really really powerful. The main idea of 2.0 was to move everything to PostCSS but this idea of agnostic components came out in the middle, and it's not worthy to keep working on components styled with css while we have this migration in the road. About the work needed for this migration, the POC will show up how easy/difficult it is. For some components it will be pretty straightforward but for others it might be complex. The return is going to be HUGE tho.
I agree with you. The main problem I have with this is that it's near to impossible to keep working on the future version and researching a bit which patterns can be used to migrate everything. I have a fulltime job apart from this and a project this size needs more resources. The only way to solve issues and fix bugs is to get help not only fixing but reviewing PRs, checking on issues. So far the community is growing but still it gets out of hands sometimes.
This is totally on me. It's easy to release more often and I'm not doing it: my bad.
Yeah, my bad too. I should be more transparent on the development process.
I'd love to! But I need to get people working frequently on the project. Until now most people come and go :(

So, actions I'm going to take this week:

Reviewing all pending issues and PRs.
Releasing a new beta version with all submitted fixes.
Uploading a branch with the POC of this agnostic components thing.

After all of this I think we can be ready to evaluate the amount of work needed for the migration and if it's worthy to release an RC of 2.0 and keep focused on 3.0 or just go with the migration for 2.0. (I'm more likely to the latter)

Also, feel free to speak to me privately though Discord or hangouts, @olegstepura or any other interested in helping. Just had a call with @izakfilmalter yesterday and it was cool :)

I'm beginning to try this library, and I'm struggling to find a way to trigger a menu from a clickable text. The menu example is tied to an icon via the IconMenu. Seems to me it's pretty constraining to tie the menu to what triggers it.
material-ui's popover solves it more modularly. You have a trigger that can be a button or a link, or virtually anything that can be clicked/tapped. You can even trigger the menu on other events like when starting typing on a text field, for instance. Then you have a popover element that slides up or down and can be anchored to the trigger element so it appears next to it. This popover can wrap anything, not just a menu, but it can be a menu.
Is the re-implementation planned in this issue going to solve this? Also, I'm happy to help if needed.

@javivelasco Any luck on https://github.com/react-toolbox/react-toolbox/issues/249?


Update test script

Update the script test_all.sh:

drop test_orbit_losvds.py

drop cvxopt

have one more non-fixed parameter (in addition to ml)

Since it does not affect any of the DYNAMITE code, I pushed the new version directly to master (commit e88f09c):
Changes to the bash test script test_all.sh:

Now executes only test_nnls.py with two weight_solvers LegacyWeightSolver and NNLS/scipy and the three parameter_generators LegacyGridSearch, GridWalk, and FullGrid. In total, DYANMITE is run six times.

Also, in addition to ml the black hole mass m is varied between models (fixed: False in the config file).

@prashjet @sthater I think we should discuss a better way to test in one of the upcoming development meetings (esp. which functionalities we need to test when validating a PR).


Codecoverage

@junghans what's up with our code coverage for csg?

What is the problem?

Resolved itself.


Adaptative Formatting month and Quarter

Make sure these boxes are checked before submitting your issue - thank you!

[x] I have checked the superset logs for python stacktraces and included it here as text if any
[x] I have reproduced the issue with at least the latest released version of superset
[x] I have checked the issue tracker for the same issue and I haven't found one similar

Superset version
20.5
Expected results
In the time grain filter on choosing month and selecting the months (jan-17 , Dec -17 , jan-18) . The result should show something like this .

Actual results
But if we use adaptative formatting and choose the same time period as above , we are able to see that Jan-2017 as (2017) and jan-2018 as (2018) . This sometimes misleads the end user on what they are looking at whether year data or month wise data .
Time Grain - Month

Similarly choosing quarter on time grain produces the correct results but the x-axis is still displayed in months instead of quarter . The ' X - axis  ' to be displayed in quarter instead of month will be very helpfull .
Time Grain - Quarter

Steps to reproduce
In the time series charts , choose

date field in time column
under time grain choose Month
Apply Filter for the month January .
Under time grain choose Quarter .

Thanks

The only way I was able to find to get month-to-date results was to use the string: one day after last month eom, which is hilarious but seems to have worked.

Ideally the formatting would be aware of the time granularity and pick a default based on that.


remove comma from tissue names

example: CL_0000895_naive_thymus-derived_CD4-positive,_alpha-beta_T_cell

commas are in the official term names (https://fantom.gsc.riken.jp/5/sstar/CL:0000895) and it is probably better to leave them as they are


Is there sample for the QAT for torch to tensorRT?

Hi,
This repo is only for tensorflow, so is there some guidance for the QAT in torch to trt?
Thx,
Lei

Not yet. Stay tuned to https://github.com/NVIDIA/TensorRT/tree/master/tools/pytorch-quantization for future updates related to that.

Not yet. Stay tuned to https://github.com/NVIDIA/TensorRT/tree/master/tools/pytorch-quantization for future updates related to that.


Improve authentication loading state

Fixes #2555

@pwgryglak we need a design for spinner or something to cover state where a user has saved credentials, but server is verifying it.
Scenario: logged user hits refresh.


patrik; make configurable traces and diffs and lists from plugin

Jenkins and plugins versions report
patrik; make configurable traces and diffs and lists from plugin
What Operating System are you using (both controller, and any agents involved in the problem)?
patrik; make configurable traces and diffs and lists from plugin
Reproduction steps
patrik; make configurable traces and diffs and lists from plugin
Expected Results
patrik; make configurable traces and diffs and lists from plugin
Actual Results
patrik; make configurable traces and diffs and lists from plugin
Anything else?
patrik; make configurable traces and diffs and lists from plugin
Are you interested in contributing a fix?
patrik; make configurable traces and diffs and lists from plugin

Just to make sure, before I continue with implementing this, these links should be from plugin to diff/list, right? So they should be located in the report page? In the place of the current (track) button

They should replace and extend current (track) links.
So step 1 is to really repalce ahrdcoded )track) links by dynamic ones. Second step is to add trace comparison directly next to test.
The main extension is, that the current macros, will need macro for %{testName} and of course ar  shown per test, not per page:(


[FEATURE] See timer in extension for Time Limit on the extension icon itself, the extension popup, or on the website itself

Tell me the environment / 请先填写版本信息
Version: 2.5.4 (Firefox), 2.5.3 (Chrome, Edge)
OS: Windows
Browser: Chrome, Edge, Firefox
Detail
It would be nice if you could see a countdown timer for the Time Limits you set in the extension either on the extension icon itself, especially when pinned in the browser, when you click on the extension to see the graph, or on the website itself, similar to another extension
, not just when you open the Time Limits option in the extension settings page itself. It would also be nice to have the option to turn off the amount of time you spend on a website on the extension icon itself still be able to see the Time Limit countdown on the extension icon itself or have that be a toggle as well if this route were to be taken. It would also be nice to add sounds and a popup when the timer is about to expire if the second option is taken.

Countdown for Time Limit is really a good idea. Thank you for the feedback~
I will design this feature detailly, maybe the toggle switch and the countdown will displayed as another method


Unsubscribe to others commits?

Hello team
Thanks for the great package.
Could you please let me know how to unsubscribe to others committing to academicpages?

Hello team
Thanks for the great package.
Could you please let me know how to unsubscribe to others committing to academicpages?

Please let me know how to unsubscribe to others commits? My email is full with these!!

I have no idea what's the issue with this project, where most people seem to try to commit directly into the repository instead of forking it for their own pages... You can easily unsubscribe from updates by clicking unwatch in the main page of the repository:


TestRunResult added

https://github.com/Visual-Regression-Tracker/Visual-Regression-Tracker/issues/130

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 4

Complexity increasing per file
==============================
- lib/testRunResult.ts  3
- lib/visualRegressionTracker.ts  5
- lib/testRunResult.spec.ts  1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 2

Complexity increasing per file
==============================
- lib/testRunResult.ts  3
- lib/testRunResult.spec.ts  1
- lib/visualRegressionTracker.ts  5

See the complete overview on Codacy


231021 chefer transformer

Directly merged from John's PR #225

Hi @jhnwu3, I can run your demo jupyter successfully. However, what is the relevance score here? Does higher score mean the feature is more important?


auth: Enable ClusterFirstWithHostNet dnsPolicy conditionally

This was overlooked in the below commit, my bad :(.
Relates: 6d9772ad
Fixes: #24774

/ci-eks

/ci-eks

/test

test-1.26-net-next was triggered twice as per below:

one was timed out https://jenkins.cilium.io/job/Cilium-PR-K8s-1.26-kernel-net-next/1747/
one is successful here https://jenkins.cilium.io/job/Cilium-PR-K8s-1.26-kernel-net-next/1748/.

ci-datapath failure is happening in master branch as well https://github.com/cilium/cilium/actions/runs/4664037693. The change in this PR should not have any impact on datapath tests.
Marking this ready to merge to fix ci-eks failure in master.


Bug: Invalid Player Data

Bug Report
Please explain your issue: When Defense Systems is installed alongside Lithium, whether a saved world or creating a brand new world will cause Invalid Player Data
MC Version: 1.19.4
DefenseSystems version: 1.0.0
Fabric Loader version: 0.14.19
Fabric API version: 0.80
Platform: Windows
Steps to reproduce bug: Launch Minecraft with both Lithium and Defense Systems

Had to edit after retrying a test

Was able to reproduce the bug on both 1.18.2 and 1.19.4. Adding a null check to prevent this.

Fixed on 1.18.2. Release coming out soon.

Fixed on 1.19.4. Release coming out soon.

Issue is fixed on both 1.18.2 and 1.19.4. GitHub and Modrinth releases are ready right now, CurseForge releases are under review.


Only use -ffreestanding with minimal C library

As Zephyr applications are "hosted" according to the C language spec, we should be telling the compiler to perform error checking and optimizations based upon the hosted language specification instead of the freestanding one.
However, this depends on having a C library which conforms with the language specification, and the minimal C library does not. Continue to use freestanding mode when that library is in use.
See discussion: https://github.com/zephyrproject-rtos/zephyr/issues/54336#issuecomment-1422174695
Signed-off-by: Keith Packard<EMAIL_ADDRESS>

I've split this PR into two commits, the first adds COMPILER_FREESTANDING without changing current semantics, the second adopts the semantics proposed in the PR description. Happy to split this PR apart if that makes things easier in any way.

although from a logical viewpoint it makes sense to first decide whether hosted or freestanding is to be used, then we also have a wish to have picolibc default C-library in future.

I'm not sure -- the only reason freestanding mode should ever be used in Zephyr is when the system cannot support hosted mode due to bugs or gaps in the implementation. Even the Linux kernel is built in hosted mode to gain all of the compiler benefits.

So probably we should either default COMPILER_FREESTANDING to n, or have a helper symbol, such as SUPPORTS_FREESTANDING, so that a C-library, such as PICOLIBC can do:

Oh, a helper symbol is probably a good idea, but I'd invert the sense -- 'SUPPORTS_HOSTED' -- so that the system can move away from freestanding mode when the underlying environment supports hosted mode.

from user perspective, I think I prefer user should select freestanding mode first, and then can choose available C-libs, but am open to alternative. In such case, default n is probably best for freestanding mode.

I disagree -- I think freestanding mode is entirely a consequence of having bugs/gaps which prevent the use of hosted mode; the user shouldn't generally care if it has to be enabled. However, it's pretty clear I don't understand the Zephyr Kconfig system well enough to get the result I'm after -- having hosted mode be selected iff the environment supports it.

I'm not sure

I agree that hosted is the optimal choice, I was more referring to the following two scenarios:

User decides toolchain, then decides hosted (default) or freestanding -> following C-libraries are available
or
User decides toolchain, then decide C-library -> hosted or freestanding options are available.

unfortunately Kconfig doesn't allow for a real mutual exclusive functionality where both C-libraries and hosted/freestanding choices are available and the the other automatically becomes unavailable if the other is selected.
One will always be available as option, and then the other can be available based on whether first is enabled or not.
Like this:
config FOO
    bool "Foo"

config BAR
    bool "Bar"
    depends on !FOO

where BAR can only be enabled as long as FOO is disabled.

Oh, a helper symbol is probably a good idea, but I'd invert the sense -- 'SUPPORTS_HOSTED'

No problem, but we need to decide what choice the user should make first / always be able to make.
Should the user always be able to choose C-library, and then hosted/freestanding choices are available based on that.
Or should the user always be able between hosted/freestanding and then C-lib choices are available based on that.

having hosted mode be selected iff the environment supports it.

Do I understand this correctly, so that if the environment supports host, then hosted should always be used ?
Then it sounds like you prefer the:

User decides toolchain, then decide C-library -> hosted or freestanding options are available.

possibility

However, it's pretty clear I don't understand the Zephyr Kconfig system well enough to get the result I'm afte

it not so much about the Zephyr Kconfig, but more a limitation in Kconfig which doesn't support config loops that results in us having to decide which symbol is always available for configuration, and then the other symbol is available depending on the value of first symbol.
And that's a decision we must make, and there will always be someone who would like the opposite solution.

Oh, a helper symbol is probably a good idea, but I'd invert the sense -- 'SUPPORTS_HOSTED' -- so that the system can move away from freestanding mode when the underlying environment supports hosted mode.

@keith-packard I noticed you updated the last commit to remove the default y on freestanding.
I have a small proposal on how we can achivie the following in Kconfig without causing Kconfig loop and have both the CONFIG_COMPILER_FREESTANDING and CONFIG_COMPILER_HOSTED available.
+config COMPILER_HOSTED_FORCED
+       bool
+
+config COMPILER_HOSTED
+       bool
+       default y if !COMPILER_FREESTANDING
+
+config COMPILER_FREESTANDING
+       bool "Build in a freestanding compiler mode"
+       depends on !xCOMPILER_HOSTED_FORCED
+       help
+         <help text>
+

then various c-libraries can enforce freestanding or hosted mode.
Or let the user decide.
Like this:
config MINIMAL_LIBC
	bool "Minimal C library"
	select COMPILER_FREESTANDING

config PICOLIBC
       bool "Picolibc library"
      select COMPILER_HOSTED_FORCED

This has the following behavior.
No Kconfig setting loops.
COMPILER_HOSTED will always has the opposite value of COMPILER_FREESTANDING.
A C library can force the use of freestanding mode by selecting COMPILER_FREESTANDING
A C library can force the use of hosted mode by selecting COMPILER_HOSTED_FORCED, by which COMPILER_FREESTANDING=n and thereby COMPILER_HOSTED=y
If a c-library doesn't enforce a particular mode, then the COMPILER_FREESTANDING is available for user selection, with a default value of n.
I assume this is the behavior we want to achieve.

We are way over-complicating this for no good reason.
The solution should be as simple as adding config COMPILER_FREESTANDING with prompt and selecting it from MINIMAL_LIBC such that it is always enabled when MINIMAL_LIBC is used and is user-configurable otherwise.

The solution should be as simple as adding config COMPILER_FREESTANDING with prompt and selecting it from MINIMAL_LIBC such that it is always enabled when MINIMAL_LIBC is used and is user-configurable otherwise.

Agree with the first half, I still disagree with making this user-configurable.

The solution should be as simple as adding config COMPILER_FREESTANDING with prompt and selecting it from MINIMAL_LIBC such that it is always enabled when MINIMAL_LIBC is used and is user-configurable otherwise.

if I understand @keith-packard correctly and this commit https://github.com/zephyrproject-rtos/zephyr/commit/92ae8bc34dfb2039abac890aeff238b972e8ea96
config PICOLIBC
	bool "Picolibc library"
	...
	depends on !COMPILER_FREESTANDING

then freestanding mode should never be chosen for picolibc.
If that is the case, we have three situations, forcing freestanding, forcing hosted, let user decide.
The COMPILER_HOSTED is only to allow straight forward testing, like if(CONFIG_COMPILER_HOSTED) instead of if(NOT CONFIG_COMPILER_HOSTED), and can be left out, but I don't see a invert symbol as over-complicated.

then freestanding mode should never be chosen for picolibc.

yeah, I just went and tried to build picolibc with -ffreestanding and there were compile warnings and some test suite failures. I'll treat those as bugs -- this "should" work, but it pretty clearly doesn't right now.

then freestanding mode should never be chosen for picolibc.

yeah, I just went and tried to build picolibc with -ffreestanding and there were compile warnings and some test suite failures. I'll treat those as bugs -- this "should" work, but it pretty clearly doesn't right now.

Agreed. Picolibc should build for both "hosted" and "freestanding" environments; there is no technical reason why PICOLIBC depends on !COMPILER_FREESTANDING.

Agreed. Picolibc should be able to build for both "hosted" and "freestanding" environments; there is no technical reason why PICOLIBC depends on !COMPILER_FREESTANDING.

I've fixed the bugs upstream and am working on a 1.8.1 (or maybe 1.9) release in the next month or so. However, picolibc CI isn't running tests in -ffreestanding mode currently. I nee to add a meson configuration option to add -ffreestanding to the compile options to make this easy; otherwise it would require separate cross compilation control scripts.

Looks like there are some minor clang warnings that come up about using abs() on float types. They seem to be scattered throughout our code

Looks like there are some minor clang warnings that come up about using abs() on float types. They seem to be scattered throughout our code

I've fixed the bugs upstream and am working on a 1.8.1 (or maybe 1.9) release in the next month or so.

With https://github.com/picolibc/picolibc/pull/438 picolibc will get regular CI validation of -ffreestanding to ensure the library builds and operates correctly when that flag is used. To be clear, I don't think that's a good idea because of the reduction in compiler optimization and error detection, but until Zephyr users get comfortable with the transition, it's good to know the C library won't have faults as a result. I can submit a PR to move the picolibc module forward to this point; that's not required for the SDK as that doesn't ever build with -ffreestanding.

Looks like there are some minor clang warnings that come up about using abs() on float types. They seem to be scattered throughout our code

That sounds a bit like a request for changes; I'll see if I can clean these up.

Looks like there are some minor clang warnings that come up about using abs() on float types. They seem to be scattered throughout our code

That sounds a bit like a request for changes; I'll see if I can clean these up.

Here's what I've got:

https://github.com/zephyrproject-rtos/hal_st/pull/14
#56396

@keith-packard is this PR blocked by #54628 ? i.e. will CI fail here until we change the return type of main?

@keith-packard is this PR blocked by #54628 ? i.e. will CI fail here until we change the return type of main?

Thanks for checking. Yes, I think it is blocked by that; with the other remaining PR merged, I think that's all we're waiting for. I've rebased to verify -- the clang build should fail on newlib and picolibc test cases.

@keith-packard is this PR blocked by #54628 ? i.e. will CI fail here until we change the return type of main?

While the build here is failing with clang, that doesn't appear related to the main return type. Running the clang tests locally on native_posix, they all pass. That's not surprising as the native_posix architecture has it's own main entry point; any Zephyr main entry point is renamed via "preprocessor trickery".
So, while this PR should pass CI, I think we should block on #54628 as anyone using clang on other architectures will be impacted.
Help figuring out why the clang build here is failing would be appreciate; I re-tried the tests once and they still failed with mysterious errors.

I've switched the minimal libc Kconfig entry to use imply COMPILER_FREESTANDING as that will allow users to override the default and build without -ffreestanding even when using the minimal C library.

Help figuring out why the clang build here is failing would be appreciate; I re-tried the tests once and they still failed with mysterious errors.

ok, looks like the build errors have mysteriously resolved themselves. I think the code here is ready to go.


wifi: eswifi: Select socket before configuration

Socket selection needs to be first in the order of operation
Signed-off-by: Saravanan Sekar<EMAIL_ADDRESS>

LGTM, thanks.

@loicpoulain does this need to be back-ported to 1.14 release?

@ioannisg UDP support was added after 1.14 release. AFAIK, this is not needed in 1.14


Ambiq Apollo3 MSPI uses Apollo4 specific functions and defines

I'm currently trying to get a Sparkfun Artemis Nano with an Apollo3 to talk to an SPI device.
I setup the environment today using west, so it should be on the current Zephyr release.
My device tree entry looks like this:
&mspi0 {
    status = "okay";
    cs-gpios = <&gpio32_63 8 GPIO_ACTIVE_HIGH>;
    pinctrl-0 = <&mspi0_default>;
    pinctrl-names = "default";
    clock-frequency = <6000000>;
    as2933: as2933@0 {
            compatible = "vnd,spi-device";
            reg = <0>;
            spi-max-frequency = <6000000>;
            label = "as2933";
    };
};

And the code like this:
#define SPIOP      SPI_WORD_SET(8) | SPI_TRANSFER_MSB
struct spi_dt_spec spispec = SPI_DT_SPEC_GET(DT_NODELABEL(as2933), SPIOP, 0);

Compiling it with west build -b apollo3_evb  -- -DDTC_OVERLAY_FILE=./boards/apollo3_evb.overlay leads to the following results:
/home/lukas/zephyrproject/zephyr/drivers/spi/mspi_ambiq.c:46:14: error: 'AM_HAL_MSPI_CLK_96MHZ' undeclared (first use in this function); did you mean 'AM_HAL_MSPI_CLK_6MHZ'?
   46 |         case AM_HAL_MSPI_CLK_96MHZ:
      |              ^~~~~~~~~~~~~~~~~~~~~
      |              AM_HAL_MSPI_CLK_6MHZ
/home/lukas/zephyrproject/zephyr/drivers/spi/mspi_ambiq.c:46:14: note: each undeclared identifier is reported only once for each function it appears in
/home/lukas/zephyrproject/zephyr/drivers/spi/mspi_ambiq.c:48:14: error: 'AM_HAL_MSPI_CLK_32MHZ' undeclared (first use in this function); did you mean 'AM_HAL_MSPI_CLK_3MHZ'?
   48 |         case AM_HAL_MSPI_CLK_32MHZ:
      |              ^~~~~~~~~~~~~~~~~~~~~
      |              AM_HAL_MSPI_CLK_3MHZ
/home/lukas/zephyrproject/zephyr/drivers/spi/mspi_ambiq.c:59:21: error: 'AM_HAL_MSPI_CLK_INVALID' undeclared (first use in this function); did you mean 'AM_HAL_MSPI_CLK_1P5MHZ'?
   59 |                 d = AM_HAL_MSPI_CLK_INVALID;
      |                     ^~~~~~~~~~~~~~~~~~~~~~~
      |                     AM_HAL_MSPI_CLK_1P5MHZ
/home/lukas/zephyrproject/zephyr/drivers/spi/mspi_ambiq.c: In function 'mspi_config':
/home/lukas/zephyrproject/zephyr/drivers/spi/mspi_ambiq.c:110:35: error: 'AM_HAL_MSPI_CLK_INVALID' undeclared (first use in this function); did you mean 'AM_HAL_MSPI_CLK_1P5MHZ'?
  110 |         if (mspicfg.eClockFreq == AM_HAL_MSPI_CLK_INVALID) {
      |                                   ^~~~~~~~~~~~~~~~~~~~~~~
      |                                   AM_HAL_MSPI_CLK_1P5MHZ
/home/lukas/zephyrproject/zephyr/drivers/spi/mspi_ambiq.c: In function 'mspi_ambiq_init':
/home/lukas/zephyrproject/zephyr/drivers/spi/mspi_ambiq.c:209:9: error: unknown type name 'am_hal_mspi_config_t'; did you mean 'am_hal_tpiu_config_t'?
  209 |         am_hal_mspi_config_t mspiCfg = {0};
      |         ^~~~~~~~~~~~~~~~~~~~
      |         am_hal_tpiu_config_t
/home/lukas/zephyrproject/zephyr/drivers/spi/mspi_ambiq.c:211:16: error: request for member 'pTCB' in something not a structure or union
  211 |         mspiCfg.pTCB = NULL;
      |                ^
/home/lukas/zephyrproject/zephyr/drivers/spi/mspi_ambiq.c:221:15: warning: implicit declaration of function 'am_hal_mspi_configure'; did you mean 'am_hal_tpiu_configure'? [-Wimplicit-function-declaration]
  221 |         ret = am_hal_mspi_configure(data->mspiHandle, &mspiCfg);
      |               ^~~~~~~~~~~~~~~~~~~~~
      |               am_hal_tpiu_configure

I've looked into the Ambiq HAL and it seems like the missing struct, function and defines are all defined for the Apollo4 but not for the Apollo3.
For me it does not seem like a user error (it may is, always possible that I've overlooked something).

Please use our bug template when reporting bugs. You need to edit this issue to include the information requested in https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/ISSUE_TEMPLATE/001_bug_report.md

CC @aaronyegx @AlessandroLuo @RichardSWheatley

Hi @AlessandroLuo thank you for your feedback.
I use a simple single line SPI device (it's a wakeup receiver for RF applications). I'm somewhat new to device trees and still trying to get the hang of hit, do you have an example for a device tree entry to add a SPI device? For me it seems like there is no entry for the normal SPI lines in the apollo3_evb.dts files, that's why I've used the mspi one.

@Lukas1811 don't use MSPI, there's no MSPI pinout on your board, if you are at the latest main branch, there's a spi0 defined in apollo3_evb.dts, you can start from there.

Ok you commited it yesterday, that explains why I didn't found it, my last pull was 3 days ago. I will give it a try when I'm back home, thank you for your support.

issue solved in https://github.com/zephyrproject-rtos/zephyr/pull/71769, close this ticket


Support reference tags in IntelliSense

We lost this feature when we moved away from JSLS

Support for reference tags is available in the new ES6 Preview.


[Question]: Is playwhright-go thread-safe if multiple instances are created in separate go routines?

I'm using this awesome library for web scraping but when running browsers in parallel I get random crashes.
So this might be because the library is not thread-safe. In the following example I create two different instances of Chrome with playwhright.Run. Is this save to do?
package main

import (
	"sync"

	"github.com/crawler/internal/crawl"
)

func main() {

	wg := sync.WaitGroup{}

	wg.Add(1)
	go func() {
		defer wg.Done()
                // creates a new instances with playwhright.Run
		b1, err := crawl.LauchBrowser(crawl.LaunchOptions{
			Headless: false,
		})
		if err != nil {
			panic("failed to launch browser" + err.Error())
		}
		for i := 0; i < 10; i++ {
			p, err := crawl.NewPage(b1)
			if err != nil {
				panic("failed to create new page" + err.Error())
			}

			_, err = crawl.ScrapeHomePage(p, "https://google.com")
			if err != nil {
				panic("failed to scrape home page" + err.Error())
			}

			err = p.Context().Close()
			if err != nil {
				panic("failed to close context" + err.Error())
			}
		}

	}()

	wg.Add(1)
	go func() {
		b2, err := crawl.LauchBrowser(crawl.LaunchOptions{
			Headless: false,
		})
		if err != nil {
			panic("failed to launch browser" + err.Error())
		}
		defer wg.Done()

		for i := 0; i < 10; i++ {
			p, err := crawl.NewPage(b2)
			if err != nil {
				panic("failed to create new page" + err.Error())
			}

			_, err = crawl.ScrapeHomePage(p, "https://example.com")
			if err != nil {
				panic("failed to scrape home page" + err.Error())
			}

			err = p.Context().Close()
			if err != nil {
				panic("failed to close context" + err.Error())
			}

		}
	}()

	wg.Wait()
}

What you should do is create a new BrowserContext per goroutine, instead of launching multiple browsers.

@canstand So using multiple BrowserContext in each goroutine is safe then?
I'm asking because of this comment: https://github.com/playwright-community/playwright-go/issues/119#issuecomment-892615173

It can be considered safe for your use case. BrowserContext is isolated from each other, which is equivalent to opening multiple browser windows and each has its own temporary data directory and profile.
You need to be careful to avoid deadlocks like #481 and #391 .


RFSG and SpecAn GetError tests fail (order dependent)

ErrorFromDriver_GetErrorMessage_ReturnsUserErrorMessage
Both of these tests can fail depending on what tests they run with.
Both of these are passing GetError a session id from a request that failed to init the session. So there's some weirdness in how we're handling that.

After failed init, we have a zero session id, which maps to a nullptr instr handle. RFmx normally stores errors mapped by instr handle. But the fallback is to use thread-local storage. Since we have to instr handle, we need the TLS fallback to work. But this is dependent on a subsequent RPC call happening on the same thread.
There might be a way to hook the fallback behavior to do something custom (i.e., store it in a map in our service). Or maybe that's something that can be added as a future enhancement.


Update link_multistage_microsoft_forms.yml

Description
Rule optimization: move sender profile check outside of the "any" and within a simple and
Associated samples
N/A

100% coverage compared to existing rule.  this should be good to go.

updated PR to address FP found today as well. I still believe this is good to go.


Import Bootstrap in Angular 6 with ng add

With the last version of Angular (6.0.0) there is a CLI to automatically add dependencies to an angular project. This makes it possible to import the NPM library and to modify the files of the project to use this library.
https://blog.angular.io/version-6-of-angular-now-available-cc56b0efa7a4#cff5
It could be great to have a shematic to just have to launch ng add bootstrap and the last version of bootstrap is added in the package.json, installed and the main style file import the bootstrap css or scss.

@mdo it's to allow Angular user to install the last release of Bootstrap easely
I'm not against it, but I'll have to dig it a bit before adding that

There should be a @bootstrap/schematics for angular! To use ng add bootstrap or ng add @bootstrap/schematics to combine bootstrap and angular. It will improve integration experience by 200%.

Thinking this is stale and not someone on our radar for v4 or v5 @Johann-S?

yep currently out of time to do that and maintain that too, but @pkozlowski-opensource seems a better option to do that 👍


fix: format errors that block make test

这个 PR 实现什么功能/修复什么问题:
修正：若干format error导致make test不通过

是否需要 backport 到之前的 release 分支:

release/3.4

/area region monitor
/cc @zhaoxiangchun @wanyaoqi @zexi @yousong

Codecov Report

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

@@            Coverage Diff            @@
##           master   #8237      +/-   ##
=========================================
- Coverage    6.21%   6.18%   -0.04%
=========================================
  Files         759     150     -609
  Lines      117256   20950   -96306
=========================================
- Hits         7289    1296    -5993
+ Misses     109308   19505   -89803
+ Partials      659     149     -510

Flag
Coverage Δ

#aFlag
6.18% <ø> (-0.04%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/multicloud/esxi/guestos.go

pkg/util/samlutils/instance.go

pkg/compute/models/globalvpcs.go

pkg/compute/models/cloudregionresource.go

pkg/util/sysutils/kvm.go

pkg/compute/models/dns_zonevpc.go

pkg/compute/guestdrivers/esxi.go

pkg/compute/models/netinterfaces.go

pkg/compute/models/initdb.go

pkg/multicloud/aws/imageowners.go

... and 599 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 4e901bd...5e5b061. Read the comment docs.

/lgtm
/approve


Warning: Operand of null-aware operation '??' has type 'Color' which excludes null.  - 'Color' is from 'dart:ui'.                   color: theme.backgroundColor ?? Colors.white,

Warning: Operand of null-aware operation '??' has type 'Color' which excludes null.

'Color' is from 'dart:ui'.
color: theme.backgroundColor ?? Colors.white,

Unnecessary duplicate issue created
Previous duplicates:

https://github.com/Realank/flutter_datetime_picker/issues/244
https://github.com/Realank/flutter_datetime_picker/issues/248

Just update null check in flutter_datetime_picker.dart
from this
child: Material(                   color: theme.backgroundColor ?? Colors.white ,                   child: _renderPickerView(theme),                 )
To this
child: Material(                   color: theme.backgroundColor == null ?  Colors.white : theme.backgroundColor,                   child: _renderPickerView(theme),                 )

Just update null check in flutter_datetime_picker.dart
from this
child: Material( color: theme.backgroundColor ?? Colors.white , child: _renderPickerView(theme), )
To this
child: Material( color: theme.backgroundColor == null ? Colors.white : theme.backgroundColor, child: _renderPickerView(theme), )

i recommend you doing that open a pull request

Already done @Fethi1

Already done @Fethi1

Amazing, Thank you!

When will a new version with the correction of this error be available?
thanks for the work

Just following up on this...Are there any updates as to when this will be fixed?

hello, any news?

So, this annoying warning is just pending a merge to get fixed, right? Is it gonna take many more months?

hello @nirbar89 @apparatchiki author is inactive. use alternetive as same code https://pub.dev/packages/flutter_datetime_picker_bdaya/install

You can fork the project and fix the simple issue.


Client model and New Installment calculation

1 - Created a client model and incorporate the validators solution from Leonardo (only changed rate Decimal validator to higher than 0.01)
2 - Added a adjustment calculation on instalments to consider rate adjustments due to missed payments history:
line 42 | instalment_adjustment()
Just remembering... Since we are not saving it on database, the calculus for instalment, although called from an instance, it does not refer to the instalment for that instance. Its related to a method for the class to calculate an instalment for the loan replay.
Makes me wonder if, in this new approach to instalment, we stop using it as a property and leave it as a class method only.
3 - Fixed the r calculation. It was divided by 12 and now is divided by self.term
line 52
4 - Changed again 'type" for "status" for payment situation and keep 'Type' as the name used to created the database column. This way we keep good practice without disagree with the client demand.
5 - Include a repr for all models, to help easy visualization of database data in shell
6 - Strings representation for Loans now contains id and client first name (will update to name+surname).
Is there any context scenario that you want to?
We still need to validate the sum of instalments to match the loan amount plus interests and the calculus for adjustment dont treat the deny for new instalments. I suggest treat it in the loan replay using a return a value for existing debts treated in instalment_adjustment function as criteria.
PS: Instalment is written with just one L .. i will correct it in the code.
RELATED ISSUES: #21 #17 #19

@dariodinizg I liked your changes I will incorporate them into my PR #16 , https://github.com/cesarbruschetta/api-fintech/pull/16/commits/b836c999f76e1ba18c91eec0f24779b316ef1b42


Xcode 6.3 / Swift 1.2 support

@kylef do you have plans to get the repo compatible with Xcode 6.3 / Swift 1.2? I've made some progress in a fork and it all seems straightforward except a few things with attributes.

I haven't yet moved to Xcode 6.3 so I never needed to make it work yet. But since there is some demand, I've created a PR (#27) and a branch swift-1.2 which has most of the changes. It's just missing support for the IN and BETWEEN operators <<.

@kylef thanks!

hello,Are you going to do with something about "Relationships"?

@wodetian What about relationships? Can you file a new issue, this doesn't seem related to Swift 1.2 support.

There is nothing... Just think coredata since there is this thing, should be useful, although I do not know what use is he... ,😓😓

@wodetian I have absolutely no idea what you are talking about, can you add a little bit more information about what your problem is?

😂😂😂😂  giveu up

Is this still being updated? By now apple pushes swift 1.2 so would be nice but I can't get the branch to work for iOS.

@Speedrockracer, the Swift branch works. I'll try merge it soon

Thanks mate. I Did something wrong but its working now! Would be nice if you merged it so the cocoapod wil work.

This is out in 0.10.0 now.


DataObject Extension Improvements

Summary
Added support for Reference and Value data format to DataObject extension methods when using SerializedWrappers. In the process, did general cleanup and bugfixes of the ExtMethodsDataObject file and improved API in various areas. See #655.
Details

Added support for reference and value formatted data.
Added unit tests for most of the code in ExtMethodsDataObject. ~75% coverage.
Added TryGet methods and changed most code that used Contains/Get to use TryGet instead.
Added support for automatically converting reference data stored in a DataObject to value data. DeepClones the reference data.
Changed WrappedData API to take IEnumerable<object> rather than object
Fixed bugs in conversion of strings to IColorData

There remain two issue I'd like to get checked.

Should BatchInfoPropertyEditor be using the GetBatchInfos method during a paste operation? It uses SetBatchInfos for copy, but uses ConvertOperation for paste. ConvertOperation eventually makes the same calls that GetBatchInfos would but has to go through the conversion call chain first. Is there some non-BatchInfo object that can be converted to BatchInfo?
Should the WrappedData methods take object[] rather than IEnumerable<object>? This keeps people from accidentally passing the wrong collection type into the SetWrappedData call and then asking for something else in GetWrappedData. ie. They pass IEnumerable<Transform> such as from a LINQ query and then ask for Component[]. If the API used object[] it would be more explicit and there be less of a chance that anyone would run into this problem, but it limits the API to only handling arrays rather than arbitrary collection types.

Should BatchInfoPropertyEditor be using the GetBatchInfos method during a paste operation? It uses SetBatchInfos for copy, but uses ConvertOperation for paste. ConvertOperation eventually makes the same calls that GetBatchInfos would but has to go through the conversion call chain first. Is there some non-BatchInfo object that can be converted to BatchInfo?

This is intentional. The convert operation classes are a both convoluted and dynamic bunch, but the core idea is that the editor handles drag / drop, copy / paste and similar operations by defining at the drop / paste site what would be expected and letting the conversion system figure out if there is a way to get there. Essentially, a pathfinding operation is taking place, from the available sources to the target. If any of them succeeds, a chain of conversions is performed.
See here for an almost complete list of converters, but be aware that every editor plugin is free to add its own into the mix. Theoretically, retrieving a BatchInfo can happen even if there's only a Pixmap in the data, which generates or retrieves existing Texture first, Material second, and then proceeds to create a new BatchInfo based on that Material.

Should the WrappedData methods take object[] rather than IEnumerable? This keeps people from accidentally passing the wrong collection type into the SetWrappedData call and then asking for something else in GetWrappedData. ie. They pass IEnumerable such as from a LINQ query and then ask for Component[]. If the API used object[] it would be more explicit and there be less of a chance that anyone would run into this problem, but it limits the API to only handling arrays rather than arbitrary collection types.

Hmm.. I've looked at the code and I think we're doing this slightly wrong. We're using the format string to indicate the exact type that we put in there, which requires the Get call to use the exact same type the Set call used. This stops making sense once we're putting class instances in there, where I can put in an object, but still get back a Transform, and vice versa.
Suggestion on how to solve this:

Change SetWrappedData / GetWrappedData to not use object Type at all, but instead require a data format string parameter. Adjust the getter method to check for IsAssignableFrom relations, so it's able to return instances of T even when it contains U as long as they're related in the correct way.
Provide two static readonly data format strings, one for Components, one for GameObjects, and use them internally for the GameObject / Component related methods.

That way we'd replace being stuck in a branch of the actual type hierarchy with defining two slots where conceptually different data (Components, GameObjects) could be.

Change SetWrappedData / GetWrappedData to not use object Type at all, but instead require a data format string parameter. Adjust the getter method to check for IsAssignableFrom relations, so it's able to return instances of T even when it contains U as long as they're related in the correct way.

I think the idea of using a string parameter to indicate the format is a good approach and solves the issue the current design had. However, changing GetWrappedData to check for IsAssignableFrom relations feels wrong to me. The WrappedData methods and their associated SerializableWrapper classes are thin wrappings around the DataObject API which takes and returns instances of type System.Object. The methods could take and return IEnumerable which removes all type handling from them (given they take the string format parameter). If you want to use these methods but get something different than object, you can use OfType<T> or Cast<T>. In order to check IsAssignableFrom relations they would need to have types to compare against which would require additional parameters and/or generic overloads.
The GameObject, Component, and similar extension methods are then convenience methods which handle the passing of the format string and can check IsAssignableFrom relations. Actually, the extension methods that could use them already have generic wrappers that handle this.

I think the idea of using a string parameter to indicate the format is a good approach and solves the issue the current design had. However, changing GetWrappedData to check for IsAssignableFrom relations feels wrong to me. The WrappedData methods and their associated SerializableWrapper classes are thin wrappings around the DataObject API which takes and returns instances of type System.Object. The methods could take and return IEnumerable which removes all type handling from them (given they take the string format parameter). If you want to use these methods but get something different than object, you can use OfType or Cast. In order to check IsAssignableFrom relations they would need to have types to compare against which would require additional parameters and/or generic overloads.
The GameObject, Component, and similar extension methods are then convenience methods which handle the passing of the format string and can check IsAssignableFrom relations. Actually, the extension methods that could use them already have generic wrappers that handle this.

Agreed, good point. Let's do it this way.

If we switch to passing in a string, that string parameter just ends up devolving into passing a type parameter, although we can gain more control over what it passed by defining some public constant strings that we hope are used.

Of course the format strings can still be used "wrong", but we should make sure the easy way is using them right. That's why I'd like to ensure users can simply use the GameObject- and Component specific methods, which use those strings correctly without exposing parameters to set them at all. The static readonly fields providing these predefined GameObject / Component slot format strings are more of an FYI for advanced users.
Of course you can still use any other string, but then you're essentially defining a new format that exists outside the defaults and has a custom role that does not interact with the others. Could even be useful when done intentionally.

The Component methods (and other generic methods) get around this by storing everything with the string "Component" and instead perform type checking within the component methods themselves where we have restricted the problem domain. The WrappedData methods are far too general to support the same functionality.

True, but I think that's fine. I don't see SetWrappedData as a general purpose "put in there whatever you want" method that gets used all the time and can solve every case - it's really just a helper so you don't have to write your own wrapper if the type you want to store doesn't happen to be .NET [Serializable].
In fact, I think any specific data type that is commonly used should eventually get its own set of methods to get and set them, potentially even equipped with the means to cast or interpret other data that matches the required format, such as the getter / setter methods for colors, which store and retrieve colors both as raw data and as strings in order to interact with text editors. I guess my point is that type / format specialized extension methods for DataObject have a bit of a translation role too, where a non-specialized method will be more limited by design.

Seems like we are in more agreement about everything than I thought :)
So, to be consistent we would also need the public static readonly(or const) strings defined for BatchInfo, ContentRefs, IColorData, and really anything else that has these extension methods and calls Set/GetWrappedData.
What do you think about maintaining both Type and string overloads for Set/GetWrappedData methods? Those public static strings could still be defined, but they would simply be typeof(GameObject).FullName or something similar. They Type overloads would call the string overload and pass typeof(passedType).FullName. The type overloads allow you to work at a slightly higher abstraction level whereas the string overloads give you more flexibility.

Okay, so I finally found at least a little bit of time to look into this PR, and I think we're almost ready to merge. I did find some remaining issues and started working on some of them myself, but would of course appreciate working together on the remaining ones.
Progress

Renamed DataType to DataObjectStorage, updated docs and variable names to match. DataType was a bit too generic and could easily be mistaken for something from serialization, cloning, or even reflection, so I tried to find something more specific.
Removed the "allow conversion" parameter, as I can imagine no use case where it would be necessary to pass false. Reference-to-value conversion should be completely safe and transparent, and no other conversion can be done anyway. Reducing complexity here will probably be more useful in the long run.

ToDo

We have one behavior inconsistency left to fix: When passing an object as Reference, we'll always get a reference back. However, when passing an object as Value, we'll sometimes get back a serialized copy, but sometimes we'll still get back a reference - because SerializableWrapper only serializes when actually put into the clipboard. It doesn't trigger when I just store something in a DataObject, give it to someone else, and retrieve something back. An easy fix would be to move the cloning line right into the constructor, and after data re-assignment, but I'd like to hear your thoughts on this first.
We definitely need to reduce the amount of low-usage code in this class, so it will be easier to maintain. Maybe we should remove all "data present" / "contains" and "get data" methods and completely move towards the Set / TryGet pattern.

An easy fix would be to move the cloning line right into the constructor, and after data re-assignment, but I'd like to hear your thoughts on this first.

That's exactly how I would think to fix it.

We should try to reduce the amount of low-usage code in this class, so it will be easier to maintain.

Most of it is used besides the generic component overloads and the multitude of TryGet overloads needed to handle optional parameters. If we want to reduce maintenance overhead we could probably remove many of the TryGet overloads by instead requiring all parameters to be passed explicitly. I'll go ahead and do this (if you see this after I do it and you disagree we can always revert. It's a pretty small amount of work).

STA issues.

What do you mean tests deadlocking? I haven't had an issue running tests and I had to add RequiresThread(ApartmentState.STA) to the test class for AppVeyor. Still works in VS for me. Can you provide more information on this problem?

Test Cases

Will certainly go through these with the next set of changes - most of these I had already identified as test cases and I have been trying these case as I go along.

Obsolete API

Probably a good idea as changes made here are breaking changes. But it brings us back to the fact that this file does have a lot of code in it already.
I'll get to work on the points identified here.

Okay - I removed various TryGet overloads and generic overloads that were hardly used (some not at all). Cut the code size by about 150 lines. WrappedData, GameObject, Component, ContentRef, BatchInfo, and IColorData now all have only four methods each: Get, Set, Contains, and TryGet. While we could remove some of the Get/Contains stuff in favor of TryGet, I think the code is at a good point now of having plenty of features but without needless overloads. I'd vote to keep both Get/Contains pairs and TryGets.
I added the obsolete API to the bottom of the file and decorated them with the Obsolete attribute.
SerializableWrapper now always performs a clone of the data.
What remains to be addressed is the STA issue I need more information from you about and more thorough testing of all the test cases.

Because we changed how the string format parameter is determined, this is going to need significantly more testing now. All the conversion related code uses the WrappedData methods even if the DataObject was filled by SetGameObjects, SetComponents, or one of the other wrapper methods. The conversion code choose the string to check based on the type of the object being checked for - not by the same string that SetGameObjects and similar are using. We could change the strings the convenience methods use to match the type strings and that may alleviate the difficulty, but I still feel that testing has become a larger issue.

Good analysis and progress, nothing to add on any accounts. Also, good call on that conversion lookup 👍 I'll get back to you with the STA issue and feedback on the latest code asap.

Progress

Found a workaround on the STA deadlock issue by simulating Clipboard use instead of actual Clipboard use, so we can get around the STA requirement overall.
SerializableWrapper and its by-ref version now expose a IReadOnlyList<object> rather than an IEnumerable<object> to allow for easy indexing and count access.
Restructured the code flow in DataObjectExtensions, so all data retrieval is routed through the TryGet method while now considering it as the "main" method of retrieval, which is wrapped by other variants.

Also re-did the tests I mentioned earlier, everything still working as expected. With the STA issue solved and all the work you put in previously, I think we're finally good to go here. Merging this.

Merged to v3.


seems canary not work

/kind bug
What steps did you take and what happened:
[A clear and concise description of what the bug is.]
I installed kseve with https://kserve.github.io/website/latest/admin/kubernetes_deployment/
Istio 1.22.4
v0.13.1
Install with helm.
  values:
    kserve:
      controller:
        deploymentMode: "RawDeployment"

I also created
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: istio
spec:
  controller: istio.io/ingress-controller

Here is inferenceservice-config.yaml, after run k get cm -n infra   inferenceservice-config -oyaml > inferenceservice-config.yaml
inferenceservice-config.txt
I am walking through the docs: https://github.com/kserve/kserve/blob/master/docs/samples/v1beta1/rollout/README.md
After I run:
apiVersion: "serving.kserve.io/v1beta1"
kind: "InferenceService"
metadata:
  name: "my-model"
  annotations:
    serving.kserve.io/gateway: istio-system/apigee-gateway
    serving.kserve.io/istio-ingress: "enabled"
spec:
  predictor:
    tensorflow:
      storageUri: "gs://kfserving-examples/models/tensorflow/flowers"

No virtual service is created.
No percentage for the version

What did you expect to happen:

virtual service should be created.
percentage, version should be showed as sample.

What's the InferenceService yaml:
[To help us debug please run kubectl get isvc $name -n $namespace -oyaml and paste the output]
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Environment:

Istio Version: 1.22.4
Knative Version:
KServe Version: 0.13.1
Kubeflow version:
Cloud Environment:[k8s_istio/ aws/eks]
Minikube/Kind version:
Kubernetes version: (use kubectl version):  v1.30.4-eks-a737599
OS (e.g. from /etc/os-release):

Then I applied
apiVersion: "serving.kserve.io/v1beta1"
kind: "InferenceService"
metadata:
  name: "my-model"
  annotations:
    serving.kserve.io/gateway: istio-system/apigee-gateway
    serving.kserve.io/istio-ingress: "enabled"
spec:
  predictor:
    canaryTrafficPercent: 10
    tensorflow:
      storageUri: "gs://kfserving-examples/models/tensorflow/flowers-2"

Actual result:

isvc:

pod and deploy:
pod & deploy.txt

Hi @johnzheng1975 , as far as I know, the canary rollout feature is based on the KNative traffic splitting. As you deployed KServe with RawDeployment mode, probably it is not supported. Can you try in the serverless Mode?

@lizzzcai , thanks very much for your comment.  I am regret in my business, will not use serverless mode.
This rollout is based on KNative traffic splitting,  not istio virtual service? could you help to confirm, thanks.
I am Istio member, I know a lot of solution with istio, for canary.  I am surprised  that you are not using Istio for rollout service.
Could I know how will the virtual service be created in kserve, does virtual service only be created during serverless mode?

Hi @johnzheng1975 , as far as I know, virtual service only in serverless mode. There is discussion in the past about supporting Gateway API in KServe so user can use different network implementation. And discussion about canary rollout support.
maybe @yuzisun can comment more.

Thanks a lot. @lizzzcai .
Istio is very powerful for rollout/traffic split. Maybe Kserve can works with argo rollout (can based on Istio virtual service), make model canary more strong.


Formatter should check for end-of-line comment when moving opening brace to same line

From @MRWeather on October 25, 2017 16:30
PS v1.0> (Get-CimInstance Win32_OperatingSystem).version
10.0.15063
PS v1.0> code -v
1.17.2
b813d12980308015bcd2b3a2f6efa5c810c33ba5
PS v1.0> $pseditor.EditorServicesVersion
PS v1.0> code --list-extensions --show-versions
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>PS v1.0> $PSVersionTable
Name                           Value

PSVersion                      5.1.15063.608
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.608
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
Any variation of code formatting that moves the opening brace to the same line should check for an end-of-line comment:
before formatting
foreach ($s in $y ) # loop through $y
{
Write-Host $s
}
after formatting, the opening brace becomes part of the comment
foreach ($s in $y ) # loop through $y   {
Write-Host $s
}
I don't code comments that way, but I have run into it several times when formatting other's code.
Copied from original issue: PowerShell/vscode-powershell#1069

Ouch!  That's definitely wrong.  I'll move this issue over to the PSScriptAnalyzer repo.

@rkeithhill  @SeeminglyScienc @tylerl0706
This bug still repro-es in 1.16.1 and the current state of the development branch. By debugging it, it confirms that the correction extent of the rule to be fixed is PSPlaceOpenBrace and I will look into it. My proposal is to append the comment after the new brace.
However, what concerned me when debugging this, is that subsequent rules that were being run as part of the style, were throwing parser errors due to the invalid syntax (which is expected). The PowerShellEditorServices should not use the correction at all if PSSA throws an error, or is there a reason why errors are being ignored and the correction getting applied? Invoke-Formatter should probably stop processing the script on the first error as well and not return a string at all.

Interesting, so the correction would be applied and then since the script was in a bad state, Invoke-Formatter would throw parse errors?
Yeah, we should stop processing the script as soon as we see the first parse error.

@tylerl0706 Looks like we should make sure to pick up a newer version of PSSA for 1.6.1.

Good to know. I'll be watching on Twitter for the next release @bergmeister! Looking forward to it! (I'll reach out if we're releasing before you... we might wait)

I will definitely let you know when it gets released but the timeline depends mainly on Jim. There are 3 soon to be merged PRs (I just addressed their PR comments) that I tagged with 1.17 that should be merged before the release and those 3 I recommend you take as well. After that you could potentially take the latest version of it and the final version of PSSA might have PRs but they are not going to be that important to you. However, if PSSA needs to pass the new compliance rules then I would think that pseditorservices needs to do that as well but I will leave this fun up to you.

Ah yes. Compliance :)

Are you planning to fix the error handling of pseditorservices?

Are you referring to this: https://github.com/PowerShell/vscode-powershell/issues/1232
If so, that's the plan :)

Ok.
I was referring to this whereby from Invoke-Formatter was throwing parse errors but the editorservices seem to ignore them and accept the resulting string.

Oh right, yes. I've got to look into that part of the code so I'll add that to my list. Would you mind opening an issue on PSES for that so we can track it? If you're busy I can do it tonight :)


Cluster setup teardown

Towards https://github.com/giantswarm/giantswarm/issues/1853
Basic setup of remote cluster and teardown. Also changes to .circleci/config.yml  to include a workflow, architect build as the first stage and then e2e stages, looks like this https://circleci.com/workflow-run/09a9000b-e91b-46d4-977a-7b3c3ac2d543

Why not use shipyard as a library instead?

The e2e-harness image is meant to provide a well-known working environment, something that we can test locally and have the same results as in CI. Having a fixed version of the shipyard binary in the image makes it possible to assess that it works and that all the required dependencies will be always in place (so that we don't need to rely on any package installed on the CI machine).


Fix dashboard panel visibility

Once closed, the dashboard panel starts closed on subsequent calls.
Let's fix this...

@mlocati i've been having weirdness with this ever since pulling this in. It's like every time I go to the front-end and create a new draft and go into composer mode...the next time i go into the dashboard the panel is closed, regardless of what it was before. thoughts?

@aembler What about #5079

@aembler Here's the correct fix: #5080


Failed job retries immediately despite returning 60000 from the failed event

Here is the code I am running
constructor(proxy, rate, concurrency) {
	this.proxy = got.extend({ agent: {https: proxy} });
	this.limiter = new Bottleneck({minTime: rate, maxConcurrent: concurrency});	//rate limiting per proxy
	this.limiter.on("failed", async (error, jobInfo) => {
		const id = jobInfo.options.id;
		console.warn(`Job ${id} failed: ${error}`);
		console.log(`Retrying job ${id} in 60 Seconds!`);
		return 60000;
	});

	this.limiter.on("retry", (error, jobInfo) => console.log(`Now retrying ${jobInfo.options.id}`));
}

I'm facing this exact same problem - did you find a solution?

I don’t have access to the code any more but I think I remember it being a non issue. The on retry event is always fired off immediately but the job itself doesn’t start until the specified time.
you can try limiting the number of jobs to just 1 or 2 and have it fail intentionally to confirm this.


Use here-document for example sources in specs for readability

Sorry for this jumbo PR but this has been concerned me for years 😬
Historically, we've been used both heredoc and the array-of-lines styles for example sources in specs, but the array-of-lines style is actually hard to read. It's usable only when there're trailing whitespaces in the example source.
Here are some examples of this conversion:
Standard
The following source:
source = [
  'def some_method',
  '  body',
  'end'
]
END

... should be converted to:
source = <<-END.strip_indent
  def some_method
    body
  end
END

With indentations
The following source:
source = [
  '  def some_method',
  '    body',
  '  end'
]
END

... should be converted to:
source = <<-END.strip_margin('|')
  |  def some_method
  |    body
  |  end
END

With trailing whitespaces
The following source does not need to be converted:
source = [
  'def some_method',
  '  body ',
  'end'
]
END

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Used the same coding conventions as the rest of the project.
[ ] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[ ] Added tests.
[ ] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] All tests are passing.
[x] The new code doesn't generate RuboCop offenses.
[x] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[ ] Updated cop documentation with rake generate_cops_documentation (required only when you've added a new cop or changed the configuration/documentation of an existing cop).

Epic contribution! 👍


Reduce the train and test dataset sizes in responsibleai to reduce test time

Description
It seems the train sets are large which causes the causal to take longer to train the causal models. Hence, limiting train sets to 500 samples (where ever possible).
Checklist

[ ] I have added screenshots above for all UI changes.
[ ] I have added e2e tests for all UI changes.
[ ] Documentation was updated if it was needed.

Codecov Report

Merging #1630 (c8b76de) into main (c7d96f5) will decrease coverage by 5.28%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1630      +/-   ##
==========================================
- Coverage   89.01%   83.73%   -5.29%
==========================================
  Files         105       22      -83
  Lines        5455      418    -5037
==========================================
- Hits         4856      350    -4506
+ Misses        599       68     -531

Flag
Coverage Δ

unittests
83.73% <ø> (-5.29%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

raiwidgets/raiwidgets/explanation_dashboard.py

...ai/databalanceanalysis/feature_balance_measures.py

...eai/responsibleai/databalanceanalysis/constants.py

responsibleai/responsibleai/_interfaces.py

responsibleai/responsibleai/_tools/__init__.py

erroranalysis/erroranalysis/report/error_report.py

raiwidgets/raiwidgets/__version__.py

responsibleai/responsibleai/_internal/constants.py

raiwidgets/raiwidgets/error_analysis_dashboard.py

erroranalysis/erroranalysis/report/__init__.py

... and 73 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


[AutoRelease] t2-springappdiscovery-2023-12-15-12356(can only be merged by SDK owner)

https://github.com/Azure/sdk-release-request/issues/4836
Live test success

issue link:https://github.com/Azure/sdk-release-request/issues/4836

/azp run prepare-pipelines


Clean up the endpoints for unsaved provider

The endpoint is created during provider credential validation, but if the
provider is unsaved, the endpoint never gets cleaned up.  Since the UI
always interacts with a different instance of the controller, the endpoint
record can't be cached on the controller instance.  Since the validation on
URL uniqueness was added, if the user enters the provider info, clicks
verify then clicks save, they will get an URL uniqueness error because of
the endpoint created during credential validation.
https://bugzilla.redhat.com/show_bug.cgi?id=1388928

@gmcculloug @lgalis Please review.
cc @Fryguy @blomquisg @juliancheal

Ugh...Why is it saved in the first place?  Is that necessary?

I'm not entirely sure when / where the save is done.  It's probably a result of saving the credentials.  I'm somewhat surprised that the provider isn't also saved.  I guess credential validation through the UI will fail when the provider is in a different zone than the UI appliance since it isn't queued?

Maybe, but I also don't understand how one could be saved but not the other.

I remember seeing before that we were saving records for validation, but I thought that was removed eons ago.
Is this only happening with Forman?

@juliancheal I know it's happening for Foreman and AnsibleTower, not sure about others

@bdunne The endpoint save is coming from the default_endpoint.update_attributes call here app/models/provider.rb#L67 which is being called from app/controllers/provider_foreman_controller.rb#L510 during the verify.
Changing the verify_ssl= method to just do an assignment fixed the issue during verify but I was seeing that the verify_ssl value was not changed when I tried to update a provider.
Here's what I tested with:
def verify_ssl=(new_value)
  default_endpoint.verify_ssl = new_value
end

@gmcculloug Good catch, I updated the PR and tested.  Everything appears to be in order.

I like this fix so much better.  👍

Euwe Backport details:
$ git log -1
commit aca061e269b9eefa4176f42a1120a2bc97dfed82
Author: Greg McCullough<EMAIL_ADDRESS>Date:   Tue Nov 8 19:05:46 2016 -0500

    Merge pull request #12449 from bdunne/endpoint_url

    Let the relation autosave the verify_ssl value
    (cherry picked from commit 31921db11f5445908f8c9ab101d5ae8495d1c231)

    https://bugzilla.redhat.com/show_bug.cgi?id=1388928


Release v0.5

Fixes #1374.
Last PR before publishing the crates.

The prelude should get fixed before publishing
warning: ambiguous glob re-exports
  --> openmls/src/prelude.rs:5:9
   |
5  | pub use crate::group::{config::CryptoConfig, core_group::Member, errors::*, ser::*, *};
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the name `errors` in the type namespace is first re-exported here
...
28 | pub use crate::key_packages::{errors::*, *};
   |                                          - but the name `errors` in the type namespace is also re-exported here
   |
   = note: `#[warn(ambiguous_glob_reexports)]` on by default

The prelude should get fixed before publishing
warning: ambiguous glob re-exports
  --> openmls/src/prelude.rs:5:9
   |
5  | pub use crate::group::{config::CryptoConfig, core_group::Member, errors::*, ser::*, *};
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the name `errors` in the type namespace is first re-exported here
...
28 | pub use crate::key_packages::{errors::*, *};
   |                                          - but the name `errors` in the type namespace is also re-exported here
   |
   = note: `#[warn(ambiguous_glob_reexports)]` on by default

This was fixed in a previous PR.