Add merge methods to MacosThemeData and widget-specific ThemeData classes (closes #183)

Adds missing merge() methods to MacosThemeData and widget-specific ThemeData classes, making it possible to use them properly with any number of user-provided custom properties. This issue was previously discussed in #182 and #183, where if the user didn't explicitly set all properties for a ThemeData the app crashed with a null-check CastError.
Now, customizing a couple of theme properties is possible. Example:
darkTheme: MacosThemeData.dark().copyWith(
  canvasColor: MacosColors.selectedTextBackgroundColor,
  pushButtonTheme: const PushButtonThemeData(
    color: MacosColors.applePurple,
  ),
  tooltipTheme: const TooltipThemeData(
    height: 100.0,
  ),
  macosIconButtonTheme: const MacosIconButtonThemeData(
    backgroundColor: MacosColors.appleBlue,
  ),
  macosPopupButtonTheme: const MacosPopupButtonThemeData(
    highlightColor: MacosColors.appleGreen,
  )),
),

Also fixed some minor errors/typos in the widget ThemeData classes.
Pre-launch Checklist

[x] I have run dartfmt on all changed files
[x] I have incremented the package version as appropriate and updated CHANGELOG.md with my changes
[x] I have added/updated relevant documentation
[x] I have run "optimize/organize imports" on all changed files
[x] I have addressed all analyzer warnings as best I could

LGTM


Unique bubblegum flavours

Each fact going into the evaluators should have a unique flavour of bubblegum attached.

cool :pope: :man: :athletic_shoe:


API auth change. Remove django-braces from requirements.

This change is

Changes Unknown when pulling 9317d50fed44b57f9959af376f3c45faaffe9f1d on ropable:master into ** on parksandwildlife:master**.


TypeScript Declaration file and test

I've added a TypeScript Declaration file, as well as a typescript version of the tests.
I had originally made a pull request for these to DefinitelyTyped, but they wanted to drop the test due to the fixtures setup (which I thought was just a shame). Plus, it is better if the declaration just pulls down with the package.
Let me know what you think!

Coverage remained the same at 94.304% when pulling 388f519e1f3fcfec795b63ea645185797ecaa541 on brianlagerman:master into 00b2c7aaee13fbe0f7fb3be332929a303b2df51d on segmentio:master.

Any change on getting this merged ?

@brianlagerman A few questions that you might be able to help me with :)
Callback error parameter shouldn't be Error | null ?
Can't we add the real signature for Plugin instead of ...args: any[] ?
Thanks for the awesome work, I'm using the typings and they are working really good!

I do have two concerns with this:

What is the purpose of test/typescript.ts? It seems to be duplicating our existing tests.
As I'm not very familiar with Typescript, I'm not particularly comfortable reviewing or maintaining these definitions

@Ajedi32 I think that the content of test/typescript.ts should only use the API and verify that the code compiles correctly. We don't need to write real tests, we have the js ones. Same way https://github.com/DefinitelyTyped/DefinitelyTyped performs validations on typings. What do you think @brianlagerman ?
Regarding your second concern, I don't have issues with helping here with the maintenance of the Typescript side!

@bilby91 The Plugin, Callback, and Ignore types were my biggest headaches getting the definition off the ground, so I'm certainly open to improvements if you see any to be made. I'm relatively sure that the Error must be included if a Callback is provided (I can't find an instance of it being optional, but correct me if you find one). I also ran into issues with the Plugin signature when using some real plugins in practice (although I can't find where those were anymore).
@Ajedi32 The test/typescript.ts is most certainly a port of the current tests in typescript. I made those mostly for myself just as an extra check that the definition was functional. Those tests certainly would not need to be maintained. On the other hand, they do work (see mocha  options) so they could help the maintainers.
I'm not sure how far along the #207 has proceeded, but I would suspect that typescript might be a better fit, although that's a whole other story...

@brianlagerman Maybe I expressed myself wrong, the error is required, what I'm suggesting is changing the signature to Error | null, not to make it optional. It might happen that you do async work in a plugin and you need to execute the callback without an error. At the moment I have to do callback(null as any, files, metalsmith).
I think we can change it to:
declare namespace Metalsmith {
  type Plugin = (...args: ((files: IFileMap, metalsmith: Metalsmith, callback: Callback) => any)[]) => void;
  type Callback = (err: Error | null, files: IFileMap, metalsmith: Metalsmith) => void;
  type Ignore = (path: string, stat: Stats) => void;

  interface IFileMap {
    [index: string]: any
  }
}

Also, I think we can remove the tests and just make it the same way as DefinitelyTyped. Let me know what you think!

@bilby91 Ahh, now I follow you. That looks like it would work fine.
The tests certainly can be removed, they're not executed by the build anyway. Just keep in mind that DefinitelyTyped at least compiles the typescript tests to check type compatibility on build. Here the test is purely manual (Travis isn't compiling or running the typescript tests), so if we drop it we'll have, well, nothing. No big deal either way in my eyes, as any problems with the definition file shouldn't (and won't) hold up regular development or builds.

@brianlagerman Cool!
Regarding the tests, I think that we need to add a tsc call against the "test" file in CI, this way we do it in the same fashion. What do you think ?

@bilby91 Well yes, that's what you would need to validate the definition in the build, if that's desired. You would be adding a TypeScript compilation step to the build though, which there isn't now.
I do have another test file that I didn't include which is much more 'DefinitelyTyped' style:
metalsmith-tests.zip
In the end though, so long as the raw index.d.ts file pulls down with the metalsmith package, the benefit is achieved. TypeScript compilation is purely a testing scenario.

@brianlagerman Awesome! That should work! Can you update the typings with my previous suggestions ?
@Ajedi32 Are you okey with adding compilation test during build time in CI ?

I guess this explains why there's no @types/metalsmith package ...

Also, it would be good to test the typings on something like the elevator pitch from https://metalsmith.io/.

@SamB I wasn't going to proceed with this since metalsmith is dead, but as the leg work was already done I decided to just post it to DefinitelyTyped, so you can watch that space to see when it gets released. If you don't feel like waiting, you can just drop the contents of this index.d.zip file into your \node_modules\metalsmith\ folder and you should be good to go....

Well that was fast, @types/metalsmith is now available...


Installing an extension reports EPERM error only in the latest version of VSCode 1.46.x.

I have an extension that is installed selecting its vsix file.  Over the past year or so developing the extension and using many versions of vscode, I never had an issue installing the extension.
Something changed between version 1.45.1 and 1.46.0.  VScode now reports an error installing the vsix,
"EPERM: operation not permitted, open 'c:\Users\kiuser.vscode\extensions\keithley-instruments.klt-extension-1.8.0\package.json'.
Any ideas on how to resolve this?   I can downgrade to 1.45.1 or other earlier versions ,and the installation will work fine.

Can you please enable the log level to trace using the command Set Log Level and provide us the logs from following location:

View -> Open View… -> Log (Shared)

I'm not sure if this will help much. The log shows:
[2020-06-30 08:40:47.479] [sharedprocess] [info] main {"machineId":"22571fa6cf5654bcaea6c4ba3608c30021b61df8b8a2d1d0d44e81b1cfc5d10b","windowId":2}
[2020-06-30 08:41:06.083] [sharedprocess] [info] Installing the extension: keithley-instruments.kult-extension
[2020-06-30 08:41:06.184] [sharedprocess] [info] Extracted extension to c:\Users\kiadmin.vscode\extensions.keithley-instruments.kult-extension-1.8.0: keithley-instruments.kult-extension
[2020-06-30 08:41:06.185] [sharedprocess] [info] Renamed to c:\Users\kiadmin.vscode\extensions\keithley-instruments.kult-extension-1.8.0
[2020-06-30 08:41:06.187] [sharedprocess] [info] Installation completed. keithley-instruments.kult-extension
[2020-06-30 08:41:06.189] [sharedprocess] [error] Failed to install the extension: keithley-instruments.kult-extension EPERM: operation not permitted, open 'c:\Users\kiadmin.vscode\extensions\keithley-instruments.kult-extension-1.8.0\package.json'
[2020-06-30 08:41:27.965] [sharedprocess] [info] Starting to clean up unused language packs.

Here's what the log looks like from 1.46.1:
[2020-06-30 08:53:41.585] [sharedprocess] [trace] ExtensionManagementService#install file:///c%3A/temp/kult-extension.vsix
[2020-06-30 08:53:41.597] [sharedprocess] [trace] Started scanning user extensions
[2020-06-30 08:53:41.607] [sharedprocess] [trace] Scanned user extensions: 3
[2020-06-30 08:53:41.610] [sharedprocess] [info] Installing the extension: keithley-instruments.kult-extension
[2020-06-30 08:53:41.611] [sharedprocess] [trace] telemetry/galleryService:query {"type":"ids","text":""}
[2020-06-30 08:53:41.612] [sharedprocess] [trace] RequestService#request https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery
[2020-06-30 08:53:41.644] [sharedprocess] [trace] Started extracting the extension from c:\temp\kult-extension.vsix to c:\Users\kiadmin.vscode\extensions.keithley-instruments.kult-extension-1.8.0
[2020-06-30 08:53:41.651] [sharedprocess] [trace] [File Watcher (node.js)] [CHANGED] c:\Users\kiadmin.vscode\extensions
[2020-06-30 08:53:41.735] [sharedprocess] [info] Extracted extension to c:\Users\kiadmin.vscode\extensions.keithley-instruments.kult-extension-1.8.0: keithley-instruments.kult-extension
[2020-06-30 08:53:41.737] [sharedprocess] [trace] [File Watcher (node.js)] [CHANGED] c:\Users\kiadmin.vscode\extensions
[2020-06-30 08:53:41.737] [sharedprocess] [info] Renamed to c:\Users\kiadmin.vscode\extensions\keithley-instruments.kult-extension-1.8.0
[2020-06-30 08:53:41.739] [sharedprocess] [info] Installation completed. keithley-instruments.kult-extension
[2020-06-30 08:53:41.742] [sharedprocess] [error] Failed to install the extension: keithley-instruments.kult-extension EPERM: operation not permitted, open 'c:\Users\kiadmin.vscode\extensions\keithley-instruments.kult-extension-1.8.0\package.json'
[2020-06-30 08:53:41.937] [sharedprocess] [trace] [File Watcher (node.js)] >> normalized [CHANGED] c:\Users\kiadmin.vscode\extensions
Installing the same extension in 1.45.1 looks like:
[2020-06-30 08:56:23.704] [sharedprocess] [trace] telemetry/galleryService:query {"type":"ids","text":""}
[2020-06-30 08:56:23.705] [sharedprocess] [trace] RequestService#request https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery
[2020-06-30 08:56:23.741] [sharedprocess] [trace] Started extracting the extension from c:\temp\kult-extension.vsix to c:\Users\kiadmin.vscode\extensions.keithley-instruments.kult-extension-1.8.0
[2020-06-30 08:56:23.747] [sharedprocess] [trace] [File Watcher (node.js)] [CHANGED] c:\Users\kiadmin.vscode\extensions
[2020-06-30 08:56:23.827] [sharedprocess] [info] Extracted extension to c:\Users\kiadmin.vscode\extensions.keithley-instruments.kult-extension-1.8.0: keithley-instruments.kult-extension
[2020-06-30 08:56:23.829] [sharedprocess] [info] Renamed to c:\Users\kiadmin.vscode\extensions\keithley-instruments.kult-extension-1.8.0
[2020-06-30 08:56:23.829] [sharedprocess] [trace] [File Watcher (node.js)] [CHANGED] c:\Users\kiadmin.vscode\extensions
[2020-06-30 08:56:23.830] [sharedprocess] [info] Installation completed. keithley-instruments.kult-extension
[2020-06-30 08:56:23.831] [sharedprocess] [info] Successfully installed the extension: keithley-instruments.kult-extension
[2020-06-30 08:56:24.030] [sharedprocess] [trace] [File Watcher (node.js)] >> normalized [CHANGED] c:\Users\kiadmin.vscode\extensions
[2020-06-30 08:56:24.136] [sharedprocess] [trace] [File Watcher (node.js)] [CHANGED] c:\Users\kiadmin\AppData\Roaming\Code\User\globalStorage
[2020-06-30 08:56:24.137] [sharedprocess] [trace] [File Watcher (node.js)] [CHANGED] c:\Users\kiadmin\AppData\Roaming\Code\User\globalStorage
[2020-06-30 08:56:24.338] [sharedprocess] [trace] [File Watcher (node.js)] >> normalized [CHANGED] c:\Users\kiadmin\AppData\Roaming\Code\User\globalStorage
The steps I followed was"

Install the system version of VSCode 1.45.1.  Delete the extension manually at C:\Users<user name>.vscode\extensions.
Launch VSCode.
Select "Install from VSIX..." in the Extension view.
Select "Install Update" from the Help menu.
Close VSCode.
Repeat steps 1 to 4.

May I know if you are having similar issue with this specific VSIX or also when you install extension from extensions view?

Do you mean installing other extensions? If so, I didn't notice a problem installing a couple other extensions. But, I didn't try many.
What I did notice is that the problem is affected by the read only file attribute of the extension's package.json file.  If I make it write-able and rebuild the vsix, then I can install the extension without the EPERM error.  Changing the attribute back to readonly reproduces the problem.
Our build server creates the VSIX for the extension. Files are read only when they are pulled out from version control .

That explains the error. Is it possible to fix your build server to provide a proper VSIX?

I'm sure not what is proper.  Why would vscode need to modify extension files?  This worked before.

Yeah I see it is working with another stable. Can you please share the VSIX to repro?

I was able to reproduce it using the helloworld-sample project and a couple minor changes to package.json.
All you have to do is change the readonly attribute of package.json.
helloworld-sample.zip

I suppose I requested for the VSIX with readonly package.json so that I can repro and look for fix.
Also, I would like to know how are you generating the VSIX? Are you using VSCE library ?

Everything is in the example attached, including the  vsce command in package.json when you execute "npm run package"

I would request you to please provide the VSIX that is causing this issue?

Ok, I'll attach it next week when I get back to the office.

Vsix in zip file.
helloworld_vsix.zip

To verify, download and install above VSIX and make sure you do not see any errors.


Configuration and integration with configuration HWIOAuthBundle

Hi,
I'm trying to integrate the LexikJWTAuthenticationBundle with HWIOAuthBundle.
Has someone already done it and could share explanations and/or code ?
thanks for your help.

part of the answer in #64


Add reset state command and update README visibility logic

This pull request introduces a new command to reset the state of the "Readme Auto Open" extension and ensures that the README file is only shown once per workspace session unless the state is reset. The most important changes include adding the new command to the package.json file and updating the extension's activation logic to handle the new state.
New command addition:

package.json: Added a new command readmeAutoOpen.resetState to the contributes section, which allows users to reset the state of the README auto-open feature.

State management and command registration:

src/extension.ts: Introduced a new constant readmeStateKey to manage the state indicating whether the README has been seen.
src/extension.ts: Updated the activate function to check the state and set it once the README is shown, ensuring the README is only opened once per session.
src/extension.ts: Added a new function registerResetStateCommand to register the readmeAutoOpen.resetState command, which resets the state and informs the user.

Resolves #3

Based on #11


Change " to ' in JSON files

Not feasible as this'd mean the ' would need to be interpreted by the Python code as meaning " which is overcomplicating things. Also, it doesn't seem possible to have JSON keys and values be surrounded by ' quotes instead of " quotes.


Allow float values in "from" and "to" inputs of integer facet range picker

In the facet range picker, we allow users to input "from" and "to" values to filter based on a range. The inputs are currently tied to the type of column. So if the facet is showing an "int" column, users can only enter integer values in these two inputs.
Does this make sense? Should we allow users to input float numbers? Would this break the ERMrest requests that we're generating?

I did some investigation for this issue and it turns out the request we are sending to ermrest also expects the search values to be of the same type as the column we are searching over.
For instance, I created a table with an integer column with values ranging from 1 to 30. When I modified the inputs in the integer facet range picker to allow for float values, I received a 400 Bad Request response for the following query when trying to search on an integer4 column:
https://dev.derivacloud.org/ermrest/catalog/82106/entity/M:=histogram-faceting:main/int_col::geq::4.5&int_col::leq::9.9/$M@sort(RID)?limit=26

The response:
400 Bad Request
Request malformed. Detail: Invalid int4: "4.5"


Relation fix

Allows for multiple relations that are different ('a=b>=c'). It starts with the last relation and adds the RHS of it to the apply node. Once a different relation is reached, a new apply node is made with the old one as the child. Finally, the LHS of the very first relation is added. Resolves #60

I realize that there is something wrong with the current output, but suggested solution also feels wrong.  Given a < b <= c, the suggested AST (as an s-expr) is:
(< a (<= b c)

The problem with this is that each inequality takes two numeric values and returns a boolean value.  If we gave a, b, and c numeric values and evaluated we'd run into a problem when evaluating the <.
Current the parser does the "right" thing for a < b < c and produces:
(< a b c)

which should be interpreted as:
(a < b) && (b < c)

Following this pattern, the meaning of a < b <= c should be (a < b) && (b <= c).  Arguable, the output for a < b < c should also be (a < b) && (b < c).  When there are more inequality operators this should still produce a reasonable parse tree, e.g. a < b <= c => d > e should produce the following AST:
('and' (< a b) (<= b c) (>= c d) (d > e))

The unfortunate thing which requires more thought is how to avoid repeating symbols more than once in the output.  This is what MathML content markup does.  I can't think of an obviously better way to do this at the moment though.

It definitely felt wrong when I had finished. Do we have a node with the 'and' operation?

Do we have a node with the 'and' operation?

There isn't a way to parse logical operators, yet, but the plan was to support and, or, not, etc. eventually.  Calling build.applyNode('and', [leftOperand, rightOperand]) should do the trick.

I've been a bit busy but I should be able to start working on this again soon.

Should be all fixed now

@SirFurness I'll review this this evening.  Sorry for the delay.

@kevinbarabash You're definitely right. I was originally reversing and unshifting due to a different method I had thought of using. With this method, it really does not need to be reversed and can then just use push instead of unshift (other minor changes needed).


Add a Cast node and modify to attribute but keep roll back to NaN

I create a Cast node. to attribute is undefined initially.
I change to float32, float, Float, Float32, FLOAT, ... etc.
No matter what I put, it show NaN later
I change to 1 and it shows float32 later
I thought I make it.  but when I load new model with netron, it say unknown type "1"
Really don't know how to add Cast properly

Thanks for the feedback! Fixing.

@jjdd88 Hi, I have updated onnx-modifier to try fixing this problem. Welcome to update to the latest version and have a try.

Thanks,  it works.  But a small GUI bug.
After I add a Cast node and add output.  I cannot see the output type from Model property.  I need to save the model and reload it to see it.

After I add a Cast node and add output. I can not see the output type from Model property. I need to save the model and reload it to see it.

Yes, you are right. Instant automatic shape/type inference is not supported in the current version and has been added to the to-do list. Stay tuned!
Thanks for your suggestion.


Clean nodeRemovalController useless log in every reconcile call

In Operator node replacement/removal controller print useless logs every reconcile call. Those spam messages need to be cleaned.

All csi issues is raised in https://github.com/dell/csi-baremetal repository, we dont use issues here.


[core] Upgrade JSS to latest minor version

Updating JSS dependency to the latest minor version (9.8.7).  This solves an issue around namespacing when using multiple JSS instances.
Use cases solved:

In my case, createMuiTheme is called multiple times while using Webpacker.  Workaround requires repetition and additional libraries.

More general issue and resolution in JSS repo here.

[x] I have followed (at least) the PR section of the contributing guide.

Had to restart CI since test_regression failed with 0 exit code and
request to https://api.argos-ci.com/builds failed, reason: socket hang up

https://circleci.com/gh/mui-org/material-ui/61027
Going to investigate if we can exit with non-zero if the argos cli fails.


fix: DEV-2465: Paragraphs data is not loading to QuickView

we were getting an array instead of a string, which caused a js error that prevents the page from working correctly.
solution: I now check if str is actually a string before continuing

Looks good to me! I think the title of this should have been fix: DEV-2465: Paragraphs data is not loading to QuickView as this appears to be a bug not a new feature.

Good catch! i've gone ahead and fixed it


Part of OSFUSE-221: Standardize on S2I for on prem/cloud builds

This change detects a S2I binary builds and installs the binaries to the correct location on the image.  (Works for spring boot apps at least).

[merge]


Handle Sentinel auth, use env vars in HAProxy config

What this PR does / why we need it:

Adds handling of Sentinel auth in HAProxy,
Handles ONLY Sentinel auth being set
Uses env vars in HAProxy config to avoid/fix escaping issues in Redis and Sentinel passwords

Which issue this PR fixes

fixes #133

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] Chart Version bumped
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

@silvpol You'll probably need to bump chart again. Do that, I'll approve. I've fixed the test status checks too.


static/DSP8010_1.0.0/json-schema-oem/RackHD.BootImage.json has extra colon in "ipv4" and "ipv6" fields

When trying to do a POST /Systems/{identifier}/Actions/RackHD.BootImage, we got a response of
{
"name": "Error",
"message": "ValidationError: Additional properties not allowed",
"stack": "Error: ValidationError: Additional properties not allowed\n    at validatePayload (/RackHD/on-http/lib/api/redfish-1.0/systems.js:471:19)\n    at bound (domain.js:287:14)\n    at runBound (domain.js:300:12)\n    at tryCatcher (/RackHD/on-core/node_modules/bluebird/js/main/util.js:26:23)\n    at Promise._settlePromiseFromHandler (/RackHD/on-core/node_modules/bluebird/js/main/promise.js:507:31)\n    at Promise._settlePromiseAt (/RackHD/on-core/node_modules/bluebird/js/main/promise.js:581:18)\n    at Promise._settlePromises (/RackHD/on-core/node_modules/bluebird/js/main/promise.js:697:14)\n    at Async._drainQueue (/RackHD/on-core/node_modules/bluebird/js/main/async.js:123:16)\n    at Async._drainQueues (/RackHD/on-core/node_modules/bluebird/js/main/async.js:133:10)\n    at Immediate.Async.drainQueues [as _onImmediate] (/RackHD/on-core/node_modules/bluebird/js/main/async.js:15:14)\n    at processImmediate [as _immediateCallback] (timers.js:383:17)",
"context": {}
}
Tracked this down to an extra colon in the "ipv4" and "ipv6" fields of NetworkAddress in the schema.  This requires the networkDevices section of the payload to have "ipv4:": rather than "ipv4":
This is the payload we were trying to use:
{       "domain": "hwimo.lab.emc.com",        "users": [{                "password": "onrack",                "uid": 100,                "name": "onrack"        }],        "hostname": "rhel70test",        "osName": "RHEL",        "version": "7",        "repo": "http://<IP_ADDRESS>:8080/rhel/7.0/os/x86_64",        "networkDevices": [{                "device": "ens20f0",                "ipv4": {                        "netmask": "<IP_ADDRESS>",                        "ipAddr": "<IP_ADDRESS>",                        "gateway": "<IP_ADDRESS>",                        "vlanId": "1824"                }        }],        "rootPassword": "1234567",        "dnsServers": [                "<IP_ADDRESS>"        ] }

@jlongever @zyoung51

Other errors I made in the json schema should also be addressed at the same time:

required property definition is missing (defined in redfish.yaml)
BootImage.osName is missing enum definition
@amymullins

Story created in the Gripen backlog to track the errors noted above:
https://www.pivotaltracker.com/projects/1492890/stories/114712497

After changing the payload to have "ipv4:": rather than "ipv4":, the error response went away, and I now get a 202 response, but, both the response body and header contain a reference to an undefined task.
{
<EMAIL_ADDRESS>"/redfish/v1/TaskService/Tasks/undefined"
}
{
"date": "Wed, 02 Mar 2016 13:32:34 GMT",
"via": "1.1 web (squid/3.3.8)",
"x-cache-lookup": "MISS from web:3128",
"x-powered-by": "Express",
"etag": "W/"37-mjH/C6Q+Yqkcn4xy70KYGw"",
"location": "/redfish/v1/TaskService/Tasks/undefined",
"x-cache": "MISS from web",
"content-type": "application/json; charset=utf-8",
"access-control-allow-origin": "*",
"connection": "keep-alive",
"content-length": "55"
}

I'll fix that at the same time, but that is a different issue.  The recent workflow refactor changed the object data structure such that the field that used to be there is now undefined. FYI @benbp

Jeanne had me check a few things and it looks like some of the tasks in the workflow are failing due to lack of OBM settings. I'm going to pursue that next.... as well.

@jgolio FWIW, Gripen has a PR up to automatically setup OBM settings during node discovery.  You may not have to deal with that issue in the future...

ok, that sounds good.

https://github.com/RackHD/on-http/pull/165

Well, I've set the OBM settings, but still I can't seem to get the install to work. I backed off and tried ComputerSystem.Reset and that gave me back the same "undefined" task ID with a 202. Out of curiosity, will the PR above (165) fix the issue for all workflows? I'm assuming so, but just want to be sure I understand. Also, when I get that back, does it mean the task actually started?

Keep in mind I'm not sure how many issues I'm running into are issues with the Redfish API and how many are issues with running in Docker containers. Could very well be both or a combination.

@jgolio The PR above will resolve the 'undefined' task id issue.
A 202 indicates the task was accepted (note that this should probably be changed to a 201...), but does not indicate that the task has actually been started.  Querying the /TaskService with the odata.id will give you the status of the task.

ok, thanks

resolved with https://github.com/RackHD/on-http/pull/165


localTime: true doesn't work, always displaying in UTC

Please tell us about your environment:
winston 3.0.0
node v8.9.4
Linux
ES6/7
What is the problem?
timestamp is printing only in UTC
const logger = createLogger({
    format: combine(
        format(info => {
            info.level = info.level.toUpperCase();
            return info;
        })(),
        timestamp()
    ),
    transports: [
        new (transports.File)({
            filename: logDir + '/general.log',
            level: "info",
            localTime: true,
            format: combine(
                label({ label: logLabel }),
                plainFormat
            ),
            maxsize: '1000000'
        }),
        new (transports.File)({
            filename: logDir + '/error.log',
            level: "error",
            localTime: true,
            format: combine(
                label({ label: logLabel }),
                plainFormat
            ),
            maxsize: '1000000'
        }),
        new (transports.Console)({
            level: "debug",
            localTime: true,
            format: combine(
                colorize(),
                label({ label: blue(logLabel) }),
                colorFormat
            )
        })
    ]
});

What do you expect to happen instead?
Prints time in local time
Other information
OS timezone is NOT in UTC

I don't think localTime is an option.  If it were, it would be an option to the timestamp formatter: https://github.com/winstonjs/logform/blob/master/timestamp.js .  If you'd like to open a PR for logform that adds such an option to the timestamp formatter, we'd be happy to consider it.  (And, feel free to let me know if I'm missing something.)  Thanks!


The OmniSci tests fail with "libjvm.so: cannot open shared object file" error

System information

OS Platform and Distribution: Ubuntu 22.04.1
Modin version (modin.__version__): 0.15.0+123.g9fe020ba
Python version: 3.8.13
Code we can use to reproduce:
pytest modin/test/storage_formats/omnisci/test_internals.py

Describe the problem
The  OmniSci tests fail with "libjvm.so: cannot open shared object file" error. The root cause of the issue is openjdk  17.0.3   h85293d2_2  from conda-forge package, that has a different libraries location. The expected library path is lib/server/libjvm.so, but the actual path is lib/jvm/lib/server/libjvm.so.

Fix is here - https://github.com/conda-forge/hdk-feedstock/pull/5

Fix is here - conda-forge/hdk-feedstock#7

The issue has been resolved.


wootility: 3.5.12 -> 4.4.5

Things done
Update wootility to 4.4.5, add hardware.wooting.xinput (supersedes #105370).

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

I just got a my Wooting 60HE and am very interested in this PR but my nix foo is still lacking to be able to review the changes.
I've tried testing the changes like so:
# configuration.nix

{ config, lib, pkgs, ... }:
{
  imports = [
    # ...
    (import "${fetchTarball "https://github.com/davidtwco/nixpkgs/archive/wootility-4.4.5.tar.gz"}/nixos/modules/hardware/wooting.nix")
  ];

  disabledModules = [ "hardware/wooting.nix" ];

  hardware,wooting.enable = true;

  # ...
}

Doing a sudo nixos-rebuild switch results in the following output though:
building Nix...
building the system configuration...
error: A definition for option `services.udev.packages.[definition 1-entry 2]' is not of type `path'. Definition values:
       - In `/etc/nixos/configuration.nix': [ ]

Am I doing it wrong or is there a bug in the PR?
P.S.: The newest version of Wootility is 4.4.9 by now.


Project-Specific Settings for Multiple Projects

Hi,
I have two Atom projects (each in different folders): Dev, Prod. In each folder, there is a different .ftpconfig file for each corresponding project with different FTP settings based on whether it is in Dev or Prod.
Unfortunately, remote-ftp doesn't seem to recognize the multiple project config files, and instead only pulls from the first Dev config file.
How can I accommodate multiple settings for multiple projects within remote-ftp?

Also experiencing same issue.


Refactor external DNS to be provider neutral

Signed-off-by: Dinar Valeev<EMAIL_ADDRESS>

@kuritka  done

@ytsarev yes, it was

commit message updated


Figure out how to modify RetrieveLoop to catch up with latest DA height faster

Currently, the RetrieveLoop in Block Manager is responsible for retrieving blocks from the DA layer. It maintains a local version of the DA height, retrieves blocks from that height once every DA block time (~15 seconds) and increments that height. This retrieve mechanism is used for hard confirmations of blocks.
We'd like RetrieveLoop to keep up with the latest DA height faster to eliminate this lag.  One way to do this would be to get the latest height, and then retrieve from all heights until that latest height starting from the last height checked plus one. Something similar happens in BlockRetrieveLoop currently. Although, we do not have a way to query the DA layer for the latest height in the DA interface so it's not straightforward implement this.
The submitBlocksToDA method does have access to the height that the blocks were published on which is more in sync with the DA layer than the local height so we could use that but this would only keep the height updated for a block producer and not validating full nodes which do not submit blocks to the DA layer. We should figure out an alternative way to pull blocks from all DA heights until the latest height for all types of nodes.

@Manav-Aggarwal i think our previous discussion on inner-looping and retries (https://github.com/rollkit/rollkit/pull/1056#discussion_r1290341238) is relevant here. we could re-introduce some form of retries to reduce the lag.


Broker. Replace agent<->broker registration using a https approach

Fixed when https://github.com/vrandkode/marshmallows/issues/30


Dasb 105 initial version csv structure function app

Changes to commit initial draft of csv structure validation for CSV Raw File and MUltipart file

Closing as it's no longer relevant to current project scope.


Updated shuffle implementation to use better hash function

Fixes https://github.com/thrust/thrust/issues/1256 by changing the hash function from taus88 to use wyhash. Adds test for a random distribution of numbers

@djns99 @RAMitchell Just checking in -- it looks like you two have been iterating on this PR, just let me know when you're ready for me to do a final review and start testing/landing it.

@djns99 I'm happy with your current approach using murmurhash, did you have anything else you wanted to add? Would be good to have a couple of comments with references for CephesFunctions and murmerhash. Please also check the licenses are compatible i.e. we are allowed to use their code in this way.

@djns99 I'm happy with your current approach using murmurhash, did you have anything else you wanted to add? Would be good to have a couple of comments with references for CephesFunctions and murmerhash. Please also check the licenses are compatible i.e. we are allowed to use their code in this way.

I probably wont have time to do this in the next few days. However, I am still having difficulty obtaining sufficiently random results, even if I increase the number of rounds. Some preliminary investigations indicate that it is likely the murmur hash function with insufficient randomness, however it is a significant improvement over the current results even at 8 rounds.
I would also note that it could be a test bug since I would expect a high enough number of rounds to pass.
As for licensing, cephes was taken from the NIST suite for testing randomness, which according to https://csrc.nist.gov/Projects/Random-Bit-Generation/Documentation-and-Software is in the public domain. I took murmur hash from the smhasher repo, the licensing information there say it is also in the public domain.

Ok, I think the key thing is for us to make the next toolkit release (11.1?). Let's catch up next week on this.

@RAMitchell I have done a bit of work on this and decided to use the RC5 encryption algorithm https://doi.org/10.1007/3-540-60590-8_7. This uses a 12-20 round (I have it set to 12 at present) feistel network using data dependent rotations on an w-bit register. The only shortfall of this is that it requires us to round to a power of 4 instead of 2. However, it means we can make some guarantees about the strength of our internal function (i.e. any errors are due to an insufficiently random key).
There are still some issues with the test I am in the process of diagnosing
As for licensing, the patent for the algorithm expired in 2015 https://patents.google.com/patent/US5835600A/en so I believe this means we are allowed to use it.

Test issues are resolved.

I'm a bit confused, current code still uses nearest power of two in get_cipher_bits.

Note the change to
m >>= 2u;

This counts the number of pairs of bits now, with w representing one half of the feistel block

I see, thanks! Nearest power of four is not ideal from a performance perspective but I think we are still much faster than alternatives and robustness is priority one.

performance perspective

In theory we could modify the RC5 algorithm slightly and use modulus by a different amount for each register to allow for a power of two instead of 4. However, this would likely require a more comprehensive analysis of the problem to ensure the correct behaviour is maintained, so I dont believe this is the place for this optimisation. There are a range of other candidate ciphers available to consider, but RC5/RC6 (though RC6 rounds to a power of 16) was the main one I found that explicitly supports a variable cipher width.

@djns99 let us know when you are ready for final review.

If we are ok with RC5 I don't think there is anything left to do at present. So we should be good to go ahead with review and merge.

Whatever implementation you two decide on is fine with me, but it sounds like there are some possible concerns with licensing, too?
Can someone summarize the potentially problematic portions of the current PR, along with their licenses, patents, and other IP concerns?

There are two parts that potentially have licensing/IP issues. The first is the Cephes functions used in the test suite, which are directly taken from a NIST test suite for random numbers.
The second potential problem is the round function used for the Feistel Network, of which there are currently two options: RC5 and MurmurHash2

As for licensing, cephes was taken from the NIST suite for testing randomness, which according to https://csrc.nist.gov/Projects/Random-Bit-Generation/Documentation-and-Software is in the public domain. I took murmur hash from the smhasher repo, the licensing information there say it is also in the public domain.

The Cephes functions are fine as is Murmur Hash if we go that route to the best of my understanding.

As for licensing, the patent for the algorithm expired in 2015 https://patents.google.com/patent/US5835600A/en so I believe this means we are allowed to use it.

If we go for RC5 (my preferred function @RAMitchell ) then it is covered by an expired patent, with the implementation being my own (based off the original paper https://doi.org/10.1007/3-540-60590-8_7). My understanding is the expired patent means the algorithm is in the public domain, so it is acceptable to use as we have here, however I don't know enough to say for sure.
To the best of my knowledge there are no other licensing/IP issues.

I'm going to have one of the NVIDIA open source lawyers look at this.

@djns99 @RAMitchell I haven't been able to get a straight answer on this from our lawyers, and I get the feeling that the only way this patch will move forward is by rewriting it to avoid anything that is known to be associated with a non-NVIDIA owned patent.
Would you be willing to submit a different implementation that avoids the patent-related algorithms?

Ok, we will look at rewriting with a different hash. @djns99 if you don't have time, I will take a stab at it later this week.

@RAMitchell it would be good if you can. I suspect going back to MurmurHash2 will probably work now I have fixed the tests. Just a bit less academic backing behind it's quality. Should also be able to go to power of two instead of 4 again

Thanks. Sorry about this, but it's the only way to get this moving again in a reasonable amount of time.

Replaced by #1309 due to IP concerns.


add ctrader

https://ctrader.com
ctrader is a forex trader
there is https://help.ctrader.com/ctrader-id/delete
but it says just email us

Hello @sinagun ,
This repo has been dormant for years, I suggest you submit your PR/issue on our maintained fork over at https://github.com/jdm-contrib/jdm

Hello@tupaschoal
oke thank you😊


Max distance between same elements in Python

Have you read the Contributing Guidelines on Pull Requests?
YES
Description
Let say an array is given with repeated elements, we have  to find the maximum distance between two occurrences of an element.
eg:
[1, 1, 2, 2, 2, 1]
ans : 5 (between two ones first and last)
Distance for 1 is: 5-0 = 5
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
Fixes : #6296
(Write your answer here.)

@ankitaggarwal23 please review

@ankitaggarwal23 done


I am using envoy for doing a LAN Manager HTTPS connection to a router but it it getting crashed

I was using envoy version envoyproxy-envoy:v1.18.2 and for that I was able to do a successful HTTPS connection through LAN manager but I upgraded it to envoyproxy-envoy:v1.24.0 and it's giving me a 400 BAD Request errror.

If you're reporting an actual crash, please report it to<EMAIL_ADDRESS>To debug an unexpected 400, I recommend enabling access logs including the %RESPONSE_CODE_DETAILS% operator. You could also try enabling debug logging.


Cookbook Unable to Install Windows Features on Chef Client 14

Preface
As per https://docs.chef.io/release_notes.html#what-s-new-in-14-0-202
windows_feature
Use the windows_feature resource to add, remove or entirely delete Windows features and roles. This resource calls the windows_feature_dism or windows_feature_powershell resources depending on the specified installation method, and defaults to DISM, which is available on both Workstation and Server editions of Windows. This resource was ported from the windows community cookbook.

Note
These resources received significant refactoring in the 4.0 version of the windows cookbook (March 2018). windows_feature resources will now fail if the installation of invalid features is requested, and support for installation via server servermanagercmd.exe has been removed. If you are using a windows_cookbook version less than 4.0, you may need to update cookbooks for Chef 14.

Cookbook Versions
IIS Cookbook Version: 6.8.1
Windows Cookbook Version: 4.2.1
Chef-client version
14.0.202
Platform Details
Windows Server 2016 Core
Scenario:
We are attempting to install IIS using the latest Chef Client (14).
Note that the prior Chef Client (13.8.5) works as expected.
Steps to Reproduce:
A simple runlist will demonstrate the issue: 'recipe[iis]'
Expected Result:
IIS should get installed.
Actual Result:
Convergence fails with the following messages:
Compiling Cookbooks...
Converging 2 resources
Recipe: iis::default
  * windows_feature[IIS-WebServerRole] action install[2018-04-23T12:50:05-06:00] INFO: Processing windows_feature[IIS-WebServerRole] action install (iis::default line 25)

    * windows_feature_dism[IIS-WebServerRole] action install[2018-04-23T12:50:05-06:00] INFO: Processing windows_feature_dism[IIS-WebServerRole] action install (C:/opscode/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.0.202-universal-mingw32/lib/chef/resource/windows_feature.rb line 83)

      ================================================================================
      Error executing action `install` on resource 'windows_feature_dism[IIS-WebServerRole]'
      ================================================================================

      RuntimeError
      ------------
      The Windows feature iis-webserverrole is not available on this version of Windows. Run 'dism /online /Get-Features' to see the list of available feature names.

      Resource Declaration:
      ---------------------
      # In C:/opscode/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.0.202-universal-mingw32/lib/chef/resource/windows_feature.rb

       83:           declare_resource(subresource, new_resource.name) do
       84:             action desired_action
       85:             feature_name new_resource.feature_name
       86:             source new_resource.source if new_resource.source
       87:             all new_resource.all
       88:             timeout new_resource.timeout
       89:             management_tools new_resource.management_tools if subresource == :windows_feature_powershell
       90:           end
       91:         end

      Compiled Resource:
      ------------------
      # Declared in C:/opscode/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.0.202-universal-mingw32/lib/chef/resource/windows_feature.rb:83:in `run_default_subresource'

      windows_feature_dism("IIS-WebServerRole") do
        action [:install]
        default_guard_interpreter :default
        declared_type :windows_feature_dism
        cookbook_name "iis"
        feature_name ["iis-webserverrole"]
        all true
        timeout 600
      end

      System Info:
      ------------
      chef_version=14.0.202
      platform=windows
      platform_version=10.0.14393
      ruby=ruby 2.5.1p57 (2018-03-29 revision 63029) [i386-mingw32]
      program_name=C:/opscode/chef/bin/chef-client
      executable=C:/opscode/chef/bin/chef-client

[2018-04-23T12:50:05-06:00] INFO: Running queued delayed notifications before re-raising exception

    ================================================================================
    Error executing action `install` on resource 'windows_feature[IIS-WebServerRole]'
    ================================================================================

    RuntimeError
    ------------
    windows_feature_dism[IIS-WebServerRole] (C:/opscode/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.0.202-universal-mingw32/lib/chef/resource/windows_feature.rb line 83) had an error: RuntimeError: The Windows feature iis-webserverrole is not available on this version of Windows. Run 'dism /online /Get-Features' to see the list of available feature names.

    Resource Declaration:
    ---------------------
    # In c:/chefinstall/.chef/local-mode-cache/cache/cookbooks/iis/recipes/default.rb

     25:   windows_feature feature do
     26:     action :install
     27:     all !Opscode::IIS::Helper.older_than_windows2012?
     28:     source node['iis']['source'] unless node['iis']['source'].nil?
     29:   end
     30: end

    Compiled Resource:
    ------------------
    # Declared in c:/chefinstall/.chef/local-mode-cache/cache/cookbooks/iis/recipes/default.rb:25:in `block in from_file'

    windows_feature("IIS-WebServerRole") do
      action [:install]
      default_guard_interpreter :default
      declared_type :windows_feature
      cookbook_name "iis"
      recipe_name "default"
      all true
      feature_name "IIS-WebServerRole"
    end

    System Info:
    ------------
    chef_version=14.0.202
    platform=windows
    platform_version=10.0.14393
    ruby=ruby 2.5.1p57 (2018-03-29 revision 63029) [i386-mingw32]
    program_name=C:/opscode/chef/bin/chef-client
    executable=C:/opscode/chef/bin/chef-client

[2018-04-23T12:50:05-06:00] INFO: Running queued delayed notifications before re-raising exception

Running handlers:
[2018-04-23T12:50:05-06:00] ERROR: Running exception handlers
Running handlers complete
[2018-04-23T12:50:05-06:00] ERROR: Exception handlers complete
Chef Client failed. 0 resources updated in 07 seconds
[2018-04-23T12:50:05-06:00] FATAL: Stacktrace dumped to c:/chefinstall/.chef/local-mode-cache/cache/chef-stacktrace.out
[2018-04-23T12:50:05-06:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2018-04-23T12:50:05-06:00] FATAL: RuntimeError: windows_feature[IIS-WebServerRole] (iis::default line 25) had an error: RuntimeError: windows_feature_dism[IIS-WebServerRole] (C:/opscode/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.0.202-universal-mingw32/lib/chef/resource/windows_feature.rb line 83) had an error: RuntimeError: The Windows feature iis-webserverrole is not available on this version of Windows. Run 'dism /online /Get-Features' to see the list of available feature names.

just to confirm it isn't similar to this issue? https://github.com/chef-cookbooks/iis/issues/315
It does appear Chef 14 changes windows_feature and this might need to be looked at, i am away on business and don't know if i'll have time to look at this so just trying to accumulate more data.

I'll review #315 now and see if its related.

thank you, i appreciate the assistance on this and patience.

I performed an install of .NET 4.7.1 via the .NET Framework 4.7.1 offline installer for Windows (NDP471-KB4033342-x86-x64-AllOS-ENU.exe).
Rebooted
Started the example chef run with the single item in the runlist 'recipe[iis]'

The issue is still present.  The error that is produced in both scenarios is also slightly different.  I think these are different issues, but definitely around the same features.
The resource used to process the role within this cookbook looks correct.  I'll generate a sample that calls windows_feature directly and try to rule out the IIS cookbook completely next.  I'll post an update soon.
Thanks!

Yep this is just broken in Chef 140.202.  I'm able to reproduce the issue outside of the IIS cookbook.
This is enough to cause the issue:
windows_feature 'IIS-WebServerRole' do
  all true
  action :install
end

I'll head over to  that repo next and get a bug submitted.  Feel free to leave this open for reference/search as I suspect we'll see this reported until the bug is addressed within the chef client.

will do! thanks a ton for the due diligence and effort.

I've submitted the issue (https://github.com/chef/chef/issues/7177) to the chef-client repo.

the resolution in the attached issue is to switch to the 64 bit installer, https://github.com/chef/chef/issues/7177

actually @joshburt do we need to add install_method :windows_feature_powershell if on windows server 2016?

@EasyAsABC123 Yes you do, dism is still the default install method for windows_feature across all platforms.


Modeler design

Fixes #358, fixeds #362.

For the updates in this PR to work as expected, https://github.com/ProcessMaker/vue-form-elements/pull/36 needs to be merged and published, and then updated in spark-modeler to point to those new updates.
For the new design to work well in spark, https://github.com/ProcessMaker/spark/pull/1804 needs to be merged.
Some notes:

The columns might be different sizes when viewed in spark. This is because the bootstrap grid layout / columns are fluid, and will expand and shrink based on the available width. To get around this, we'd need to set a max-height or use custom CSS to hard-code the widths. It works and looks fine this way, but let me know if you want this changed.
(Related to the above) The padding to the left of the inspector is slightly less than the padding to the right of the control panel. This is to give the inspector more space and also to match the changes made to the screen builder. Padding can easily be adjusted, but the point above must be considered.

@velkymx
What do you think about reducing the font-size for the control labels and adding tool-tips?


NewNetworkInjection cannot be performed on Power Platform environment because of the governance configuration

Hi,
I'm running in on this issue. It seems to he a governance configuration over at Power Platform Environment but I can't find what setting.
Linking of vnet policy did not start for environement ***** Error: {   "StatusCode": 400,   "StatusDescription": null,   "Headers": [     {       "Key": "Date",       "Value": "Fri, 02 Aug 2024 12:12:30 GMT"     },     {       "Key": "Cache-Control",       "Value": "no-store, no-cache"     },     {       "Key": "Strict-Transport-Security",       "Value": "max-age=31536000; includeSubDomains"     },     {       "Key": "x-ms-islandgateway",       "Value": "GA00000IL"     },     {       "Key": "x-ms-request-id",       "Value": "westeurope:2ec10d50-2b5a-4a7b-a30a-5b3cbf5c39e3"     },     {       "Key": "x-ms-correlation-request-id",       "Value": "30825dbe-66ce-4cef-a37e-fa1bf84411a9"     },     {       "Key": "x-ms-correlation-id",       "Value": "30825dbe-66ce-4cef-a37e-fa1bf84411a9"     },     {       "Key": "Server-Timing",       "Value": "x-ms-igw-upstream-headers;dur=1080.9,x-ms-igw-req-overhead;dur=0.7"     },     {       "Key": "X-Content-Type-Options",       "Value": "nosniff"     },     {       "Key": "x-ms-service-request-id",       "Value": "e4924964-3d75-4b5e-937e-47d221a2d6f9"     },     {       "Key": "x-ms-activity-vector",       "Value": "00"     }   ],   "Error": {     "code": "InvalidLifecycleOperationRequest",     "message": "NewNetworkInjection cannot be performed on Power Platform environment because of the governance configuration.",     "detailUrlType": "NotSpecified"   },   "Message": "NewNetworkInjection cannot be performed on Power Platform environment because of the governance configuration.",   "Internal": {     "Version": {       "Major": 1,       "Minor": 1,       "Build": -1,       "Revision": -1,       "MajorRevision": -1,       "MinorRevision": -1     },     "Content": {       "Headers": "[Content-Length, System.String[]] [Content-Type, System.String[]]"     },     "StatusCode": 400,     "ReasonPhrase": "Bad Request",     "Headers": [       "[Date, System.String[]]",       "[Cache-Control, System.String[]]",       "[Strict-Transport-Security, System.String[]]",       "[x-ms-islandgateway, System.String[]]",       "[x-ms-request-id, System.String[]]",       "[x-ms-correlation-request-id, System.String[]]",       "[x-ms-correlation-id, System.String[]]",       "[Server-Timing, System.String[]]",       "[X-Content-Type-Options, System.String[]]",       "[x-ms-service-request-id, System.String[]]",       "[x-ms-activity-vector, System.String[]]"     ],     "TrailingHeaders": [],     "RequestMessage": {       "Version": "1.1",       "VersionPolicy": 0,       "Content": "System.Net.Http.ByteArrayContent",       "Method": "POST",       "RequestUri": "https://api.bap.microsoft.com/providers/Microsoft.BusinessAppPlatform/environments/b4192d6e-fb29-e80a-a638-ea18b7009b54/enterprisePolicies/NetworkInjection/link?&api-version=2019-10-01",       "Headers": "[User-Agent, System.String[]] [Authorization, System.String[]] [Accept-Encoding, System.String[]]",       "Properties": "",       "Options": ""     },     "IsSuccessStatusCode": false

Activate Managed Environments on Power Platform Environment to fix this.

Activate Managed Environments on Power Platform Environment to fix this.


IP issue and redirect issue

fixing issue with ip not beeing detected on newer PHP versions
changed the redirect when deleting files from UI

Nice work!
Thanks for the contributions


Exclude extra Tomcat libraries when overriding base version.

I have not been able to test this given the requirements for mongo and the like.  The logic does work in a 7.1.0 build.gradle in an overlay built from initializr.

Looks like this exists already:
https://github.com/apereo/cas-overlay-template/blob/94a2c24cbaef1cf56fdbf312c3a7d62868af3c46/gradle/springboot.gradle

Ah geez that's what I get for not updating my wrapper.  Thanks!


minor: isNull

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Don't error if guest calls proc_exit with exit code 0

Fixes #321.
The issue, as discussed there, is that Zig build-exe generates a module that calls WASI proc_exit.  This is realised in Wasmtime as a trap, and any trap is realised in Rust as an error.  This PR rather recovers the trap and checks whether it was a benign exit.
This needs to be backported to WAGI.  I think it's not needed for the Spin executor but would appreciate other folks' thoughts on that!

Wha! Good find! That is not what I would have expected to be the root of Zig's error.


Updated "Contact Email" in Different Pages

Hey @Priyaaa1  | Issue Closes #497
I have updated the "Contact Email" with<EMAIL_ADDRESS>on the following Pages:
Contact Us

FAQ

Legal Pages: Privacy Policy, Terms and Conditions

Additionally, I have made sure after the users click on the mail id it will redirect them to the Mail Window.

@MastanSayyad there's one more wrong mail written in Privacy Policy page.

thank you for leeting me know @Priyaaa1

@Priyaaa1 actually there were two emails that needed to be get updated, I have done the changes,Thank you!!


Support  binding.gyp as a lifecycle script in allow-scripts

as documented here
https://docs.npmjs.com/cli/v10/commands/npm-rebuild
the presence of binding.gyp is to be treated as an install script equivalent and get run as such

[ ] implement detection of the binding.gyp as an install script
[ ] introduce a minimal implementation of running it via the existing library that runs things... or add the npm's own implementation if it's separated into a lib.

This may make the changes I made in #748 unnecessary


Removing 109-page-long nuclide list from API docs

What is the change?
Removing 109-page-long nuclide list from API docs
Why is the change being made?
I can find no one anywhere who tells me they have ever referred to this table. Thus, it is unused an unneeded.  Also, this does not belong in the API docs, it is not part of the API.

Checklist

[X] This PR has only one purpose or idea.
[X] Tests have been added/updated to verify any new/changed code.

[X] The code style follows good practices.
[X] The commit message(s) follow good practices.

[X] The release notes have been updated if necessary.
[X] The documentation is still up-to-date in the doc folder.
[X] The dependencies are still up-to-date in pyproject.toml.

@keckler Please note, the docstring I removed was under a .. only:: html directive, so this only affects the HTML version of the docs and not any downstream PDF docs that are created.


Integration fails to load

Hello,
I just have updated Supervisor to the most recent version 2024.11.3. Im running Dyson 1.4.2 and the integration doesn't load anymore.
Core
2024.11.1
Supervisor
2024.11.3
Operating System
13.2
Frontend
20241106.2
The error logs show this entry:
2024-11-11 15:50:29.775 DEBUG (Thread-144 (_thread_main)) [custom_components.dyson_local.vendor.libdyson.dyson_device] Disconnected with result code 0
Any help would be much appreciated.
Thanks,
Andreas

Also seeing an error since upgrading to 2024.11, wondering if its related ->
heres a dump from the log
Error unloading entry MyDyson<EMAIL_ADDRESS>(GB) for dyson_local Traceback (most recent call last):   File "/usr/src/homeassistant/homeassistant/config_entries.py", line 850, in async_unload     result = await component.async_unload_entry(hass, self)              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   File "/config/custom_components/dyson_local/__init__.py", line 181, in async_unload_entry     device: DysonDevice = hass.data[DOMAIN][DATA_DEVICES][entry.entry_id]                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^ KeyError: 'xxxxxxx...'

Not sure if it was an issue on the Dyson site. Back up and running again without any updates on my side. Closing the issue.


Produce JSON results even when a suite's init function reports SKIP or FAIL

Also tidy-up some surrounding code.
Signed-off-by: Kévin Petit<EMAIL_ADDRESS>

We are ok with this change.
Thanks,
Balaji Calidas
Qualcomm


tests: net: socket: getaddrinfo: fix resource leak

Fix resource leak detected by coverity by adding missing
zsock_freeaddrinfo(res) calls.
Coverity-CID: 219527
Fixes #32919
Signed-off-by: Guðni Már Gilbert<EMAIL_ADDRESS>

According to this site: https://man7.org/linux/man-pages/man3/getaddrinfo.3.html

The freeaddrinfo() function frees the memory that was allocated for the dynamically allocated linked list res.


PMT cylinder location flag

Knowing the location of each PMT in the detector is important in the fiTQun tuning for the creation of the scattering table and the time pdfs.
There is a flag implemented in WCSim which should specify this information:
https://github.com/WCSim/WCSim/blob/9019993b4fb87645036ae1e67e97080adc10d8e3/include/WCSimRootGeom.hh#L30
But when checking the values for WCTE detector, what you get is the same value (1) for every PMT.
The reason comes from two wrong assumptions in the code that sets this value:

The central PMT has an mPMT-PMT-id equal to 19 (nID_PMTs), but it should be 1
The cylinder is assumed to be vertically oriented in Z, but WCTE is Y oriented.

https://github.com/WCSim/WCSim/blob/9019993b4fb87645036ae1e67e97080adc10d8e3/src/WCSimConstructGeometryTables.cc#L288

The central PMT has an mPMT-PMT-id equal to 19 (nID_PMTs), but it should be 1

The central mPMT ID is 1 in WCTE, but 19 in other detectors.

The cylinder is assumed to be vertically oriented in Z, but WCTE is Y oriented.

This is true for other nuPrism type detectors.


Add logo to docs folder and README

Proposed logo in in #22!
Can edit if needed. :smile:

:green_apple:

:green_apple:


Adding a fresh coat of paint.

Life is grand - especially when you have css.
These changes include.

Add dark theme
Animate cover
Update typographic styles / use system font stack

/ok-to-test

/lgtm


Docs.MS Release Updates for azure_search_documents

Update docs metadata and targeting for release of azure_search_documents

Docs Build status updates of commit 06cc86b:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-services/latest/search-documents-readme.md
:warning:Warning

Details

docs-ref-services/latest/search-documents-readme.md

Line 2, Column 1: [Warning-ms-prod-and-service] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 9, Column 16: [Warning-ms-prod-technology-invalid] Invalid value for 'ms.technology': 'azure' is not valid with 'ms.prod' value 'azure'.
Line 2, Column 1: [Suggestion-description-missing] Missing required attribute: 'description'.
Line 50, Column 1: [Suggestion-table-syntax-invalid] Table syntax is invalid. Ensure your table includes a header and is surrounded by empty lines.
Line 74, Column 146: [Suggestion-preserve-view-not-set] Did you mean to link to a specific version? If so, add &preserve-view=true to the URL: https://docs.microsoft.com/cli/azure/search/service?view=azure-cli-latest#az-search-service-create
Line 434, Column 1: [Suggestion-duplicate-alt-text] Alt text 'Impressions' is duplicated. Within an article, alt text must be unique.
Line 442, Column 1: [Suggestion-duplicate-alt-text] Alt text 'Impressions' is duplicated. Within an article, alt text must be unique.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


libsass: "got unexpected keyword argument(s) 'image_path'"

When trying to use the libsass filter, I get the following error:
TypeError: compile() got unexpected keyword argument(s) 'image_path'

It appears that libsass (as in the C++ library) hasn't supported image_path for nearly a year (https://github.com/sass/libsass/pull/834) and now the latest version of libsass-python has dropped support for arbitrary kwargs in compile (https://github.com/dahlia/libsass-python/issues/109) - thus causing an error as image_path isn't a valid kwarg.
Installing libsass<0.10 works around this issue.

I see this has already been fixed in master.

I'm still have this issue using Flask-Assets, that installs the latest assets version (0.11.1) but still has an old version. The only solution for me was to install using the following command:
pip install git+git://github.com/miracle2k/webassets.git

I've same issue here with last version 0.12.3. It's not happening with .9.3 for example.

Using webassets==0.11.1 here, this error is not shown when using it with libsass==0.9.3 but it's shown again with last version of libsass (0.12.1), so it's probably on libsass' side. Take a look: https://github.com/sass/libsass/pull/834


[Bug] When you use https in the URLs you get a weird "failed to fetch" error in the extension and the web worker.

To Reproduce

Load clean extension from a build from main
Use https://localhost:3901 https://localhost:3903 in the boot and agent URL boxes as instructed (also https://<IP_ADDRESS>:3901 and https://<IP_ADDRESS>:3903 work as localhost isn't supported by the extension but somehow the loopback IP is???)
Get the weird errors below.

Input to URLs

Stack trace in extension

Console output of web worker
Background script loaded
index.ts-dc7dd268.js:53 Signify Browser Extension installed
index.ts-dc7dd268.js:53 Message received from browser extension:  ui--authentication-check-agent-connection
index.ts-dc7dd268.js:53 Signify client is not connected undefined
index.ts-dc7dd268.js:53 Message received from browser extension:  ui--authentication-generate-passcode
index.ts-dc7dd268.js:53 Message received from browser extension:  ui--authentication-boot-connect-agent
index.ts-dc7dd268.js:53 TypeError: Failed to fetch
    at Gu.boot (index.ts-dc7dd268.js:53:23720)
    at Object._ [as bootAndConnect] (index.ts-dc7dd268.js:53:30879)
    at async KS (index.ts-dc7dd268.js:53:40417)
_ @ index.ts-dc7dd268.js:53Understand this errorAI
index.ts-dc7dd268.js:53 Message received from browser extension:  ui--authentication-check-agent-connection
index.ts-dc7dd268.js:53 Signify client is not connected null

To Resolve

An appropriate error should be displayed on the client and a proper console log output for errors in the extension and web worker.

build env
Chrome: Version 130.0.6723.92 (Official Build) (64-bit)
Build Extension from main commit: 2799a162ae1b93bc54c284f1833aa4077e58e876

@daidoji thank you for reporting this.
I am wondering how https is supposed to work with localhost.
Have you created a local secure tunnel so that localhost can be accessed with https?
Are you able to visit https://localhost:3903/health in your browser?
In my case, I can access http://localhost:3903/health in my browser and following agent_url and boot_url work for me in browser extension:
agent_url: http://localhost:3901 OR http://<IP_ADDRESS>:3901
boot_url: http://localhost:3903 OR http://<IP_ADDRESS>:3903
But https scheme does not work and that is expected as we might need to setup certificates for that I assume.
Thoughts?

Sorry, we used https unwittingly because we assumed keria would at least use self-signed tls as a baseline security measure.
This bug's intention though wasn't necessarily used to get https to be enabled for the extension, but rather for the extension to throw a better error message or dialogue on URLs that aren't working properly.  "Failed to fetch and a strange stack trace in the error logs" don't seem like a great combination for the end user.

Sorry, we used https unwittingly because we assumed keria would at least use self-signed tls as a baseline security measure.
This bug's intention though wasn't necessarily used to get https to be enabled for the extension, but rather for the extension to throw a better error message or dialogue on URLs that aren't working properly. "Failed to fetch and a strange stack trace in the error logs" don't seem like a great combination for the end user.

Thank you for the details. I agree that "Failed to fetch" error can be replaced with a more user friendly statement. But this is thrown natively by browser when fetch request fails (could be due to several reasons)

Perhaps, we can implement a custom handler for that case. But I got the point that it is related to "Failed to fetch" rather an https problem.
Thanks


Question

AttributeError: 'NoneType' object has no attribute 'seek'.You can only torch.load from a file that is seekable. Please pre-load the data into a buffer like io.BytesIO and try to load from it instead.
How to solve this problem!Please!!!!!For helping !!!!!!

hello！did you solve this problem？i have met it too. If you find the way, could you tell me how to solve it? thank you ！！！

No,i have not solved it yet...
------------------ 原始邮件 ------------------
发件人:                                                                                "nnzhan/Graph-WaveNet"<EMAIL_ADDRESS>发送时间: 2020年9月1日(星期二) 晚上9:33
收件人<EMAIL_ADDRESS>抄送: "蓝"<1050776794<EMAIL_ADDRESS>主题: Re: [nnzhan/Graph-WaveNet] Question (#17)
hello！did you solve this problem？i have met it too. If you find the way, could you tell me how to solve it? thank you ！！！
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I gave up the test.py and use the testing part in the train.py to reach my goal.

i think we need to set the defults parameters of checkpoint in test.py

i think we need to set the defults parameters of checkpoint in test.py

Yes, just add '--checkpoint ./garage/XXX.pth', and test.py can run correctly.

i think we need to set the defults parameters of checkpoint in test.py

thanks.I will try it later!

i think we need to set the defults parameters of checkpoint in test.py

Yes, just add '--checkpoint ./garage/XXX.pth', and test.py can run correctly.

ok  i will try it !thanks

i think we need to set the defults parameters of checkpoint in test.py

Yes, just add '--checkpoint ./garage/XXX.pth', and test.py can run correctly.

ok i will try it !thanks

i think we need to set the defults parameters of checkpoint in test.py

Yes, just add '--checkpoint ./garage/XXX.pth', and test.py can run correctly.

i think we need to set the defults parameters of checkpoint in test.py

Yes, just add '--checkpoint ./garage/XXX.pth', and test.py can run correctly.

I don't quite understand how to do it. Can you be more specific？thanks

i think we need to set the defults parameters of checkpoint in test.py

Yes, just add '--checkpoint ./garage/XXX.pth', and test.py can run correctly.

ok i will try it !thanks

I don't quite understand how to do it. Can you be more specific?thanks


--stats-error-details true causes webpack to never exit if cache is used

Bug report
What is the current behavior?
If all of these conditions are true:

cache: { type: 'filesystem', ... } option is used
the cache is fresh
--stats-error-details true is passed to CLI

Then webpack will never complete, and will get stuck after the final "success" log:
(... more stats ...)
Entrypoint main 56.9 KiB (293 KiB) = static/runtime~main.bundle.89bd23eb.js 1.53 KiB static/vendors.bundle.ecaefaad.js 55.1 KiB static/main.bundle.60c2d488.js 340 bytes 3 auxiliary assets
cached modules 359 KiB (javascript) 3.71 KiB (runtime) [cached] 63 modules
webpack 5.23.0 compiled successfully in 2876 ms
^[[A^C

Dirtying app files, removing cache config, or removing the debug --stats-error-details true command fixes the issue
If the current behavior is a bug, please provide the steps to reproduce.
Same as above ⬆.
What is the expected behavior?
webpack does not get stuck forever :) and either cleanly exits or reports an error
Other relevant information:
webpack version:  5.23.0
Node.js version: 12.20.2
Operating System: macOS 10.15.7
Additional tools: n/a

FWIW I am also having this no-exit-after-success problem, haven't pinned it down yet.

I run into this if I set stats.all to false


Add backup, restore, and node cloning automation

This change adds support for

Backup - DB SQL dump, data, and systemd untis are backed up in a tarball
Restore - system id wiped of Mastodon files, tarball is restored to / and database is initialised from SQL dump
Remote features - designated backup user with ssh keys worked into provisioning automation
Node cloning - deploy a new node that clones a live node, e.g. for vertical scaling, switching hosting providers, etc.

See the updated README for more information.
A .gitignore was added mainly aiming at preventing committing a backup key to the repo.
A few changes and fixes are included for issues encountered during work on this PR:

Grafana dashboards are now downloaded (from the main branch of this github repo) instead of being included in the user data. This works around a user data size limitation encountered during testing.
mastodon public/ directory ownership was fixed. Wrong ownership prevented user uploads (e.g. posts with pictures, avatars, custom emojis)
Initialising the DB on first start-up was removed from the mastodon-db service file to prevent operational mistakes, and made explicit in re_initialise.sh

Automation tested on Azure.

Did a test deployment, backup, restore, and a node clone - everything works. Thank you for the review!


Check Date and Collection fields in Formidable

The Date and Collection fields in a Formidable form must be verified correctly.
Right now, they generate a verification error.

Fixed with v1.3


Not clear that JDK immutable factories are more "modern" than Guava immutable collections

Almost everything we had in Guava that made its way into the JDK came out better in the JDK, and I really appreciate that your tool helps our users get rid of that junk!
But, immutable collections didn't, so unless you define "modern" by "release date" then I'm not sure it really applies to this case.
Couple major advantages of the Guava collections over the newer JDK factories:

The set and map have deterministic (insertion-ordered) iteration, instead of randomized order, which produces flakiness (while still being better than undefined ordering, I'll note).
They have a far richer set of construction paths, including builders, and a few other features like ImmutableSet.asList().
(the big one) They are public types that guarantee immutability, which make for nicer field types and return types than the general-purpose ones like List.

This enables static analyzers to disallow modifications at compile-time. In spirit, it's nearly as though the modification methods are not even there. (I don't know which tools beyond Error Prone are doing this, but the API makes it possible.)
It's not every developer's job to remember when to make a "defensive copy"; just do what the compiler tells you.

The JDK factories have a few advantages as well, especially for code that isn't otherwise using Guava at all. But I don't think a fine-grained discussion of which "wins" overall should be necessary; I think the fact these major trade-offs exist mean that the Guava types are not legacy, and the JDK factories not more modern.
What do you think?

Just as an extra data point from a company other than Google itself: we have configured the plugin to indeed disable these patterns. Currently our full set of exclusions is as follows:
<exclusionPatterns>
    <!-- The plugin suggests replacing Guava's
    immutable collection factory methods with
    `java.util.{List,Map,Set}.{copyOf,of}`, but those
    methods don't allow one to convey immutability at
    the type system level. -->
    <exclusionPattern>com/google/common/collect/Immutable(List|Map|Set)\.(copyOf|of):.*</exclusionPattern>
    <!-- The plugin suggests replacing usages of
    Guava's `Iterables` class with
    `java.util.stream.Stream` equivalents, but the
    alternative is often more verbose, requiring
    unnecessary conversions to and from streams. -->
    <exclusionPattern>com/google/common/collect/Iterables\..*</exclusionPattern>
</exclusionPatterns>

(Now Iterables I'm not sure I'd have gone to bat for. :-))

The set and map have deterministic (insertion-ordered) iteration, instead of randomized order, which produces flakiness

This is not an advantage. Because of new JDK factories we discovered few bugs in our code that dependent on the order.
Random iteration order was introduced for a reason.

And just another point.
Most usages of Immutable Collections from guava are just pure and simple creation of given factories, because it is easier to do it e.g. inline during field initialization.
And for those it is pretty valid for modernizer to report them, in other cases one can use excludes.
So besides the system level "Immutable*" I don't see major benefits.
There wasn't a single case that I converted that was troublesome.

@krzyk Randomized collection ordering is a topic that we've been discussing lately for unrelated reasons. Can you explain what kinds of bugs you fixed when you switched from guaranteed order to randomized order? Traditionally, the bugs we've heard of are from switching from one non-guaranteed order to another, as we often see with classes like HashMap during JDK upgrades.

(Maybe you had code that copied a HashSet into an ImmutableSet, so you were indirectly depending on the non-guaranteed order of HashSet? In that case, Set.copyOf calls your attention to the problem now, while ImmutableSet.copyOf would break only when you upgrade the JDK and see a change in HashSet ordering -- or maybe just when your prod code inserts different values that your tests.)

tl;dr: I plan to remove these violations before the next release.  I appreciate all the comments on this issue and am documenting my current thinking below.

I feel I did not present this well at all.

Sorry I was not ignoring this exactly but I hoped that the community would surface some consensus since I lack a strong opinion.  I added the violation in d26cc7c5d6f6bc08ed305397ce149716f1d21c70 in 2014 without too much thought.  Since then the project grew several configuration knobs that remove the need to recommend every possible recommendation and users can add any violations they want.

The set and map have deterministic (insertion-ordered) iteration, instead of randomized order, which produces flakiness (while still being better than undefined ordering, I'll note).

I consider this a small win for Sets since users should only rely on ordering for List types.

They have a far richer set of construction paths, including builders, and a few other features like ImmutableSet.asList().

Noted that Immutable* have more construction paths although modernizer only warns about the of variants.  Although I imagine that most users would prefer to use all or no Immutable* for consistency and not a combination of Java and Guava types.

(the big one) They are public types that guarantee immutability, which make for nicer field types and return types than the general-purpose ones like List.

This is a clever use of deprecation annotations but encouraging use of Guava types in public interfaces is probably a bad idea, especially for libraries that should avoid coupling.  There are decades of debate about the warts of the Collection type hierarchy and possible remedies which I am sure you understand better than me.  I will note that Sets.of also returns Set and that the Immutable* variants easily decay to mutable Collections.
My motivation to remove these violations is to reduce the perceived false positive rate for users and thus provide the most utility for the broadest cross-section of users out-of-box.  Thus I plan to remove these violations before the next release.

I feel I did not present this well at all.

Sorry I was not ignoring this exactly but

(No, I mean I really think I did present it poorly :-))

in 2014

jawdrop.

(the big one) They are public types that guarantee immutability, which make for nicer field types and return types than the general-purpose ones like List.

This is a clever use of deprecation annotations but encouraging use of Guava types in public interfaces is probably a bad idea, especially for libraries that should avoid coupling.

Well, the surface area of released libraries is a small minority of collection usages. For the within-Google data point here, we return these types from public methods hundreds of thousands of times, and it works out well. The compile errors aren't even the best part, but since people are generally so hyped about "List shouldn't even have add()", it hits home with them as being the next best thing we can do.
The actual best part goes deeper than that: an immutable implementation means a bad thing won't happen, but an immutable type means you won't have to even worry about a bad thing happening, and the difference really helps. I alluded to this re: "defensive copies".

There are decades of debate about the warts of the Collection type hierarchy and possible remedies which I am sure you understand better than me.

Those things will never be remedied in Java itself, so I think what we do is just the next best thing anyone can.

Well, the surface area of released libraries is a small minority of collection usages. For the within-Google data point here, we return these types from public methods hundreds of thousands of times, and it works out well. The compile errors aren't even the best part, but since people are generally so hyped about "List shouldn't even have add()", it hits home with them as being the next best thing we can do.

I will readily admit that I have a limited vantage point since I exclusively work on Java libraries.  I appreciate your feedback since I spend more of my time using C++ these days, both inside Google and otherwise.


VCF header preservation

Pervasive bug in svtyper and several scripts that removes unrecognized header info (FILTER, weird ##GATKCommandLine= stuff, etc).
Need to be more permissive in header fields, while preventing duplication of header info IDs.

https://github.com/cc2qe/svtyper/commit/48a4d4e22037b1dcf2c87d3f17fcba97f430bdff


Clicking on an operator in the workflow detail interface causes the URL to change

In the workflow detail interface, clicking on a preview operator will cause the URL to change.
URL before clicking an operator:

URL after clicking an operator:

After discussion, we can disable "highlighting an operator" and "highlighting a link" on preview pages


Update set-up-scaling-script.md

Azure Portal has changed text, so updateing this doc to reflect

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

@Heidilohr Could you review the proposed update to your article? Thanks!

Closing no longer required


Backup solution: Expire date of backup

An expire date for backup would be great, and important.

Are you talking about the EXPIREDATE option in the backup command?
https://docs.microsoft.com/en-us/sql/t-sql/statements/backup-transact-sql
Could you elaborate a bit on how you would use it?

Hello,
yes, i mean this option:
{ EXPIREDATE ='date' | RETAINDAYS = days } Specifies when the backup set for this backup can be overwritten. If these options are both used, RETAINDAYS takes precedence over EXPIREDATE.
Best regards
Christian
From: Ola Hallengren<EMAIL_ADDRESS>Sent: Monday, June 10, 2019 7:50 PM
To: olahallengren/sql-server-maintenance-solution
Cc: Weber, Christian; Author
Subject: Re: [olahallengren/sql-server-maintenance-solution] Backup solution: Expire date of backup (#150)
Are you talking about the EXPIREDATE option in the backup command?
https://docs.microsoft.com/en-us/sql/t-sql/statements/backup-transact-sql
Could you elaborate a bit on how you would use it?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/olahallengren/sql-server-maintenance-solution/issues/150?email_source=notifications&email_token=AKPJGLPJ273Z6UCRRXANWGTPZ2H5RA5CNFSM4FZRFPI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKTVKA#issuecomment-500513448, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKPJGLPY5IUCA6CGRTCDATDPZ2H5RANCNFSM4FZRFPIQ.


PERF: Avoid repeated recursive calls when getting forward-filled close

Instead of recursively calling DailyHistoryAggregator.closes until we find a non-nan close, we can instead call load_raw_arrays once, and find the value from the returned array.

Coverage increased (+0.005%) to 87.469% when pulling f4e91f8cf76698847d3106b83eb5700118b3a8b2 on speedup-daily-history-aggregator-closes into a006b4bbab1f4d92724bfa268b92f0a4f1868e54 on master.

@yankees714 do you have profiles/timings of this change using a contract which fits in the happy case (i.e. the last minute of the day is not nan.) as well as the worst case that this is fixing?
(I am slightly worried about incurring cost of creating arrays in cases that they are not needed.)
Depending on those results, we may want to have the logic assume best case and get the last value, and then assume the worst if it is nan.

Think I may have mis-interpreted @ehebert's question here at first - the case where the minute passed to closes() has a non-nan close should not be effected. We do see a bit of a slowdown where the value is nan and the value for the previous minute is non-nan (~180 µs -> ~220 µs), but we don't think this is significant enough to add extra logic.

Coverage decreased (-0.05%) to 87.465% when pulling 7b4a15ba2beea5cf9c82675c0a970a6d914df8ae on speedup-daily-history-aggregator-closes into 8a672be7e7403f2885177dad3fa275e004d268d0 on master.

Coverage increased (+0.005%) to 87.519% when pulling a4c69afa204cda33b9d743681b8d9dea973a297c on speedup-daily-history-aggregator-closes into 8a672be7e7403f2885177dad3fa275e004d268d0 on master.

Coverage increased (+0.005%) to 87.519% when pulling a4c69afa204cda33b9d743681b8d9dea973a297c on speedup-daily-history-aggregator-closes into 8a672be7e7403f2885177dad3fa275e004d268d0 on master.

@yankees714 The new test looks good to me, though it would be nice to be able to share a lot of that code. What do you think of moving the test into the existing MinuteToDailyAggregationTestCase suite and creating a shared helper function? Also, is there any way to use this test to compare the old behavior to the new? (i.e. does it fail or is it just slower, in which case I'm not immediately sure how to compare)

@dmichalowicz Good call on sharing a helper function - I was initially tentative to include both the futures and equities setup in the same test case, but I like the way it came out.
For the behavior comparison, the new test fails on master (with the max recursion depth exceeded issue).

Coverage increased (+0.005%) to 87.519% when pulling 8cafb69d583f4bbe190cf8259b665e60a58eee83 on speedup-daily-history-aggregator-closes into 8a672be7e7403f2885177dad3fa275e004d268d0 on master.

The shared test looks great, nice work. This PR looks good by me, unless @ehebert had any other comments

Coverage increased (+0.005%) to 87.519% when pulling f4f2048a68a36febb1f68c40980f05b2ade3bf75 on speedup-daily-history-aggregator-closes into 8a672be7e7403f2885177dad3fa275e004d268d0 on master.


Change the way the main provoc function works.

The interfaces requires data frames with particular formatting and column names. This is not acceptable.
Ideally, the provoc function should take something like a formula argument similar to a binomial glm, e.g.,
provoc(
    formula = cbind(count_column_name, coverage_column_name) ~ B.1.1.7 + B.1.617.2,
    data = mydata,
    mutation_defs = astronomize(),
    by = "sra"
)

where the user can specify the lineages however they want. If they supply a matrix with column names corresponding to their lineages it should work, otherwise it should use a built-in set of definitions (currently astronomize(), but this can change). The lineage definition will be joined with mydata according to the relevant mutations, potentially giving a warning if there aren't many mutations in common (in practice, there are very few mutations used in lineage definitions, so the warning cutoff may need to be quite low).
If mutation_defs is NULL, then the function should check the column names of mydata.
cbind(count, coverage) ~ . should check for known definition names in mydata and simply use those as the definitions. If ambiguous, return an error.
Note that count_column_name in cbind(count_column_name, coverage_column_name) is interpreted as a column in mydata - it doesn't need to be a vector in the user's environment. This will require some knowledge of parsing formulas in R.
Currently, the function looks for a column labelled "sample", then applies the model to each sample separately. This should be replaced by a by argument, which allows the user to specify a column of their choosing (in this example, mydata$sra). This may be multiple columns, such as location and date, which uniquely define each sample.
Ideally, the output should be an object of class provoc.

Hi @DBecker7, thank you for your suggestions. I agree with your improvements, here are some possible improvements to make it more adaptable and user-friendly:

Implement formula arguments to allow users to specify their count, coverage columns, lineages
Check for definition names for how we handle lineage definitions, ie. check mydata when mutation_defs is NULL
Error handling for ambiguous definitions and warnings for mutation overlap
Replace sample with by argument to let users define samples using their own column names
Make sure the output of the function is returning an object of class provoc

Let me know what you think about these improvements, and if I should alter my approach


TensorFlow 2.0

These tutorials were developed in 2016-2017 for early versions of TensorFlow and modified slightly when the TensorFlow API changed during the following years. But TensorFlow has recently seen a major upgrade in late 2019 to v. 2.0 with many breaking API changes. I will eventually go through the tutorials and see if it makes sense to upgrade some of them to support TensorFlow 2.0, but the new TensorFlow version is currently too buggy and unstable.
The last TensorFlow version that I know worked with all the tutorials (unless described in the Notebooks) was TensorFlow v. 1.9.0. Unfortunately that version is not available anymore. You can try installing TensorFlow v. 1.14.0 but not everything may work.
pip install tensorflow==1.14

When I made these tutorials 3 years ago, TensorFlow was very poorly designed and documented. That is why I felt these tutorials were necessary. I pleaded with the Google developers to focus more on API design. But the person in charge of API design was extremely stubborn and demanded that TensorFlow had a very low-level API. This resulted in maybe 5 high-level API's being developed independently. Eventually the Keras API became the winner. Finally after 3 years, the Google developers have understood, that a good API is important, so they have made Keras the default builder API for TensorFlow 2.0 along with other API changes.
But I am not convinced that TensorFlow 2.0 is going to the last major reworking of the TensorFlow API, and it may not be worth the time and effort for me to continue updating these tutorials every time the Google developers decide to change the TensorFlow API.
I have heard that PyTorch is much better designed than TensorFlow, although I haven't tried PyTorch myself, as I have been working on completely different things for a while. But you could try using PyTorch instead of TensorFlow and see how you like it.

Thanks for the update

Several of the tutorials have now been updated to work with TensorFlow 2. Some of the tutorials have to run in "v. 1 compatibility mode". Other tutorials simply cannot run in TF2 and would take too much effort to convert, so you will have to run them with an older TF1 version.

Several of the tutorials have now been updated to work with TensorFlow 2. Some of the tutorials have to run in "v. 1 compatibility mode". Other tutorials simply cannot run in TF2 and would take too much effort to convert, so you will have to run them with an older TF1 version.

Hi, great work with the tutorials. Yours is the best tutorial I found on this subject for absolute AI beginners, all others on Github seem to assume a lot more knowledge TF knowledge. I discovered it was possible to run the "07 Inception Model" tutorial in TF2 making the following change to line 58 of inception.py: replace "import tensorflow as tf" with  "import tensorflow.compat.v1 as tf"
Haven't tried this with any other of your TF1 tutorials, but hopefully this might help someone who is new to this and just wants to get something working quickly.
Thanks


feat(dependency): add support to specify resolve order

Resolves: https://github.com/python-poetry/poetry/issues/5852

[x] Added tests for changed code.
[x] Updated documentation for changed code.

https://github.com/python-poetry/poetry/pull/6011#issuecomment-1250358696


bug(menu, drag and drop): host-context does not work on menu or drag and drop components

Is this a regression?

[ ] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
No response
Description
When using :host-context() with a menu or drag and drop component item, the styling is not applied.
Reproduction
Steps to reproduce:

Place a class called "parent-class" on a parent div
Place a class on the specific item that should be styled (when an ancestor component has the selector of .parent-class)
Apply
:host-context(.parent-class) {
.item-class {
// some styling
}
}

See stackblitz for menu component: https://stackblitz.com/edit/angular-shpfzq?file=src/app/menu-overview-example.scss
See stackblitz for drag and drop component: https://stackblitz.com/edit/angular-vwsq5v?file=src/app/cdk-drag-drop-connected-sorting-group-example.css
Expected Behavior
Styling should be applied when using :host-context() with an ancestor element's selector.
Actual Behavior
Styling is not applied to menu or drag and drop component items when using :host-context() with an ancestor element's selector.
Environment

Angular: 14.0.0
CDK/Material: 14.2.5
Browser(s): Chrome
Operating System (e.g. Windows, macOS, Ubuntu): Windows

None of the Angular Material components use shadow DOM. Given that :host-context is meant to select the shadow host, this seems to be working as expected to me.

The way the Angular docs describe :host-context it behaves as a sort of "ancestor" selector.  And this works great for light/dark theme applications, where we apply a theme class to the body, and then use :host-context in our component styles to change the colors for the applied theme.  That all works great in non-dialog use-cases.  But for dialog's we end up having to put those definitions in our styles.scss.  I always assumed it's because dialogs are created in a different part of the dom that disrupts that from matching correctly.  But I didn't think it was a lack of shadow dom issue.


browser-ppx: process stritems

Allows to do things like:
module T = struct
  type t = Js.Json.t
end [@@platform js]

module U = struct
  type t = string
end [@@platform native]

Both platform or browser-ppx can be used as the attribute tag (this change applies to every existing preprocessing of browser-ppx as well).

usage of context free

I took a stab at this too. It seems non-trivial because context-free:

only supports extensions, not attributes, so we should change the API somehow to adapt to that
it expects to return something from the rule function, but we need to erase nodes fully from the ast (Some / None)

I am not sure how to work around that 🤔


Compression methods is not working?

Trying write file to archive with compression method set (UZKCompressionMethod.none), but this file in the final archive still have deflated (UZKCompressionMethod.default) compression method.
Example code:
let archive: UZKArchive = try! UZKArchive(url: url)
try! archive.write(data, filePath: path, fileDate: nil, compressionMethod: UZKCompressionMethod.none, password: nil, progress: nil)
Then we can see compression method of file in archive:
archive.listFileInfo().first!.compressionMethod
that will be .default, not .none

Thanks for noticing this, @denis-ionov. I don't change compression methods personally, but I'll write some test cases and see if this is a problem in the archival or in the listing.

@abbeycode I found that problem is in the method implementation - Default compression method passed to next write function call, instead of compression method parameter. Fix this by using "next" write method with overwrite parameter.

Thanks for digging into it! I would welcome a pull request to address this, or else I'll fix it as soon as I have some availability.

I merged your pull request into the v1.9 branch. Thanks for the contribution!


Git: Adopt FileSystem Provider

Fixes #55110
Issues:

[x] Diff editor doesn't seem to listen on changes for the left document
[ ] Opening the HEAD version of a file does call watch but doesn't seem to react on file events
[x] Opening the Changes and HEAD of a file then closing HEAD will close both editors
[x] The HEAD version of a file should persist on reload. The tab appears for a while but it goes away pretty soon after reload. https://github.com/microsoft/vscode/issues/84799
[ ] The tab of the HEAD version of a file looks the same as the file itself, we need to find a way to distinguish them.

Opening the HEAD version of a file does call watch but doesn't seem to react on file events

Solution: Git should wait for the first status call to complete, before returning a stat/read.

@joaomoreno I landed a change on master that diff editors no longer close when closing any of the 2 editors inside. I hope this works fine, we gotta check for regressions.


Publish 7.4-20220115014319+0000

Publish 7.4-20220115014319+0000

@bot-gradle test and merge

OK, I've already triggered a build for you.