sbt test hangs on UnsupportedClassVersionError

steps
Reproduction repository: https://github.com/gaeljw/sbt-test-hangs

clone the repo in local
make sure to use Java 11 (using jenv or any other way)
run sbt clean test

environment
sbt --version
sbt version in this project: 1.9.7
sbt script version: 1.9.4

java --version
openjdk 11.0.20 2023-07-18
OpenJDK Runtime Environment (Red_Hat-<IP_ADDRESS>.8-1.fc38) (build 11.0.20+8)
OpenJDK 64-Bit Server VM (Red_Hat-<IP_ADDRESS>.8-1.fc38) (build 11.0.20+8, mixed mode, sharing)

problem
The commands hang forever:
sbt clean test
[info] welcome to sbt 1.9.7 (Red Hat, Inc. Java 11.0.20)
[info] loading settings for project global-plugins from plugins.sbt ...
[info] loading global plugins from /home/jourdang/.sbt/1.0/plugins
[info] loading settings for project sbt-test-hangs-build from plugins.sbt ...
[info] loading project definition from /tmp/sbtfuck/sbt-test-hangs/project
[info] loading settings for project root from build.sbt,version.sbt ...
[info]   __              __
[info]   \ \     ____   / /____ _ __  __
[info]    \ \   / __ \ / // __ `// / / /
[info]    / /  / /_/ // // /_/ // /_/ /
[info]   /_/  / .___//_/ \__,_/ \__, /
[info]       /_/               /____/
[info]
[info] Version 2.8.20 running Java 11.0.20
[info]
[info] Play is run entirely by the community. Please consider contributing and/or donating:
[info] https://www.playframework.com/sponsors
[info]
[success] Total time: 0 s, completed 10 nov. 2023 à 13:38:32
[info] compiling 1 Scala source to /tmp/sbtfuck/sbt-test-hangs/target/scala-2.13/test-classes ...
[error] Uncaught exception when running tests: java.lang.UnsupportedClassVersionError: au/com/dius/pact/provider/IProviderInfo has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
[error] sbt.ForkMain$ForkError: java.lang.UnsupportedClassVersionError: au/com/dius/pact/provider/IProviderInfo has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
[error] 	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
[error] 	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1022)
[error] 	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
[error] 	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800)
[error] 	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698)
[error] 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
[error] 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
[error] 	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
[error] 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:527)
[error] 	at java.base/java.lang.Class.forName0(Native Method)
[error] 	at java.base/java.lang.Class.forName(Class.java:398)
[error] 	at org.scalatest.tools.Framework$ScalaTestTask.loadSuiteClass(Framework.scala:408)
[error] 	at org.scalatest.tools.Framework$ScalaTestTask.suiteClass$lzycompute(Framework.scala:416)
[error] 	at org.scalatest.tools.Framework$ScalaTestTask.suiteClass(Framework.scala:416)
[error] 	at org.scalatest.tools.Framework$ScalaTestTask.accessible$lzycompute(Framework.scala:417)
[error] 	at org.scalatest.tools.Framework$ScalaTestTask.accessible(Framework.scala:417)
[error] 	at org.scalatest.tools.Framework$ScalaTestTask.shouldDiscover$lzycompute(Framework.scala:420)
[error] 	at org.scalatest.tools.Framework$ScalaTestTask.shouldDiscover(Framework.scala:419)
[error] 	at org.scalatest.tools.Framework$ScalaTestRunner.$anonfun$tasks$2(Framework.scala:752)
[error] 	at org.scalatest.tools.Framework$ScalaTestRunner.$anonfun$tasks$2$adapted(Framework.scala:750)
[error] 	at scala.collection.ArrayOps$WithFilter.map(ArrayOps.scala:90)
[error] 	at org.scalatest.tools.Framework$ScalaTestRunner.tasks(Framework.scala:750)
[error] 	at sbt.ForkMain$Run.runTests(ForkMain.java:345)
[error] 	at sbt.ForkMain$Run.run(ForkMain.java:192)
[error] 	at sbt.ForkMain$Run.access$100(ForkMain.java:187)
[error] 	at sbt.ForkMain.main(ForkMain.java:178)
[error] 	at sbt.ForkMain.main(ForkMain.java:164)
Warning: Unable to read from client, please check on client for further details of the problem.

Note that I'm well aware of the runtime error due to using Java11 with class files compiled for Java 17.
My concern is that sbt process just hangs doing nothing until stopped with a Ctrl+C.
expectation
I expect the command to fail but exit.
notes
I'm not entirely sure if this is relevant but I ran VisualVM to try to see what the process was doing and the only thread doing something was the following:

Using Test / fork := false prevents the issue but that's not always a possibility.

Thanks for the report!


onCodeSuccess / onCodeFail / correctCode / center Error Text

Added on CodeSuccess and onCodefail ,, and you must provide correct pin
hint :
do not enter correct pin ,, and you can use onEnteredPin =(the same as)= onCodeFail

Looks good, but can you please add a change log message to the change log file.
Also please mention Breaking change as it will affect the working behaviour.

done @awazgyawali


Watch task failed on NLS bundle

Today I was working and notice yarn watch had failed with:
[watch-client    ] [09:21:30] Starting compilation...
[watch-client    ] [09:21:30] 'watch-client' errored after 2.98 min
[watch-client    ] [09:21:30] Error: contents of /Users/connor/Github/vscode/src/vs/workbench/workbench.web.main.nls.js are not a buffer
[watch-client    ]     at /Users/connor/Github/vscode/build/lib/util.js:225:19
[watch-client    ]     at Stream.write (/Users/connor/Github/vscode/node_modules/event-stream/index.js:204:20)
[watch-client    ]     at stream.write (/Users/connor/Github/vscode/node_modules/through/index.js:26:11)
[watch-client    ]     at Stream.ondata (node:internal/streams/legacy:21:31)
[watch-client    ]     at Stream.emit (node:events:518:28)
[watch-client    ]     at Stream.emit (node:domain:551:15)
[watch-client    ]     at drain (/Users/connor/Github/vscode/node_modules/through/index.js:36:16)
[watch-client    ]     at stream.queue.stream.push (/Users/connor/Github/vscode/node_modules/through/index.js:45:5)
[watch-client    ]     at Stream.write (/Users/connor/Github/vscode/node_modules/through/index.js:14:43)
[watch-client    ]     at stream.write (/Users/connor/Github/vscode/node_modules/through/index.js:26:11)
[watch-client    ] error Command failed with exit code 1.
[watch-client    ] info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
ERROR: "watch-client" exited with 1.

Related to ESM/NLS work?

I haven't been able to get this to repro. Weird. And recent commits don't look especially related.
Maybe this is something in swc?
Feel free to close if you don't have any suspects.

The file is removed from our repo.


Facebook not returning events for pages using Pages API

https://stackoverflow.com/questions/49825680/how-can-i-get-the-events-for-a-facebook-page/49825869#49825869
As commented in the former issue Facebook doesn't support returning events for pages using Pages API anymore. The fork from Thorgall doesn't seem to work neither. Still the events are not parsing. (Or I tried it wrongly... but I followed all Thorgall's steps).
Do any chance you could update the event section somehow?
Thanks again for your great plugin.

I have the same problem, in fact everyone will have the same problem. I was hoping to find a fix here too, but after some research it looks like there is no fix because Facebook deprecated the event API edges. The API isn't returning any event feeds, possibly it will work if you get an official app review but the app review process is currently suspended until further notice. Facebook is the problem here, not the plugin.
https://stackoverflow.com/questions/49976691/i-cant-get-events-from-a-facebook-page-even-with-administrator-rights

So is this plugin working right now or not ?

@f3bruary AFAIK, no, like cpfeifer says above. I tried app review and got rejected once. It was not worth the effort for me to continue trying to improve my app review application.
@prinla sorry for the lost time, I'll update that post to make clear that it doesn't work anymore.


🐛 fix(update): removes the requirement of privileged access

Description
This PR fixes the following issues with the rio update command

requires privileged access to update the appimage even when the file is at a non-privileged location
The file move fails with the error: Invalid cross-device link: '/tmp/tmp354y0nsn/rio' -> '/home/ankit/.local/bin/rio'

Testing
01:43:02 pallab@pop-os appimages
→ rio version
rio 0.6.0 / SDK 1.11.1

01:43:06 pallab@pop-os appimages
→ rio update -f
🎉 A newer version (4.0.3) is available.
⚠ Please consider running as a root user.
❌ Failed to update: [Errno 13] Permission denied: '/usr/local/bin/rio'

01:43:13 pallab@pop-os appimages
→ doas rio update -f
🎉 A newer version (4.0.3) is available.
✅ Update successful!

01:43:26 pallab@pop-os appimages
→ doas cp rio /usr/local/bin/

01:43:42 pallab@pop-os appimages
→ sudo rio update -f
🎉 A newer version (4.0.3) is available.
✅ Update successful!

01:43:51 pallab@pop-os appimages
→ rio version
rio 4.0.3 / SDK 1.11.1

I was getting Text file busy exception. It was fixed by adding a remove before the move.
<I> ➜  rio update
🎉 A newer version (4.0.3) is available.
Do you want to update? [y/N]: y
⚠ Please consider running as a root user.
❌ Failed to update: [Errno 26] Text file busy: '/home/ankit/.local/bin/rio'

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


Use Pyro branches in the default manifest

Make the default pro manifest build the Pyro branches of everything rather than Morty. The previous default manifest has been now renamed to morty.xml.
Best regards,
Leon

@OYTIS @patrickvacek @cajun-rat unfortunately I don't have permissions in this git repository to add you as reviewers. Could you please have a look at convenient for you time?
Thanks, Leon


Implement Ligthbox support

This is a good example of a lightbox we can easily integrate: http://ashleydw.github.io/lightbox/

It was also discussed that we could possibly use modals which is what lightbox looks like it is using.

No one has asked about lightboxes for a while. Closing.


nerdfonts: 2.2.1 -> 2.2.2

Description of changes
Bumps nerdfonts to v2.2.2
This includes a revert to 2.1.0 behaviour for non-mono fonts that used to show up as mono in terminal emulators but stopped doing so in 2.2.0
Things done

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)
[x] 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

[x] 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
[x] 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.

Result of nixpkgs-review pr 190154 run on x86_64-linux 1

3 packages built:

koreader
mepo
mepo-x11

Thank you!


Make docker-compose not rely on local volumes

When deploying the docker-compose file on a remote SWARM cluster it (most likely) won't have access to the github repository, hence the default config can not be mapped into the container.
I reckon that either the config is backed into the original container (while volumes_from) could be used by the nginx container or the config is derived from a template (confd/consul-template/...) using environment variables.
I'll try to provide a version that could be deployed remotely, not sure when I'll find the time.

Closing because I think this was resolved by merging #188. If not, please reply and I'll reopen.


Example story board not work

there is no way to use this library? or no proper description how it can be used..... also no such way to see the view

@sazidIqabal hey, check it https://blog.uptech.team/how-to-implement-expandable-menu-on-ios-like-in-airbnb-3d2bdd97b049

now got it


Make Expression-Eval depend on NodeCoeffSeq[_], not TermGenParams

This is necessary for generation using parallel collections etc., where generation may not be by tg.nodeCoeffSeq
This will however mean a type-parameter passed (or just NodeCoeffSeq[_])

It is better to instead pass a function optionally mapping coefficients to Doubles

It is better to instead pass a function optionally mapping coefficients to Doubles


small fixes to netrw#BrowseX

do not enter dir in Netrw on opening
double quotes after start in WSL not working

See @chrisbra 's comments at 0

thanks

included as of 460799d885feeabd57b4e9336c513e53b2c7c86f


select into temporary table does not work with parameters

Environment

Python: 3.5.2
pyodbc: 4.0.17
OS: Ubuntu 16.04
DB: MS-SQL 2014
driver: FreeTDS

Issue
creating a temporary table from select works when no parameters are used in execute() method. With placeholder and parameter the execution fails silently:
>>>  temptablequery = 'SELECT * INTO #temptable FROM [Specimen] WHERE [AccessionNumber] = ?'
>>>  cur.execute(temptablequery, 'c1')
<pyodbc.Cursor object at 0x7f3626c1c510>
>>> con.commit()
>>>  squery = ('SELECT * FROM #temptable')
>>> cur.execute(squery)
Traceback (most recent call last):   File "<stdin>", line 1, in <module> pyodbc.ProgrammingError: ('42S02', "[42S02] [FreeTDS][SQL Server]Invalid object name '#temptable'. (208) (SQLExecDirectW)")
The same thing does work when I either use a global temporary table (##temptable) or replace the placeholder with a value and do not use execute() with parameter.

@v-chojas Can I get your opinion on this?  Is this because the SQL Server driver wraps parameterized SQL statements with a stored procedure?  That's one of the things I wanted to eventually discuss with you & Luis - it messes up "@identity" also.  It would be great if the SQL Server team could undo that eventually.

I can't speak for FreeTDS, but with Microsoft ODBC Driver for SQL Server, queries with parameters will be executed using one of the system stored procedures, and since stored procedures are executed in a separate scope, temporary tables created there won't be accessible from outside that scope. Instead, you can try creating the table in the outer scope first:
 >>> cur.execute('SELECT * INTO #temptable FROM [Specimen] WHERE 0 = 1' ) # create empty table with appropriate schema
 >>> temptablequery = 'INSERT INTO #temptable SELECT * FROM [Specimen] WHERE [AccessionNumber] = ?'
 >>> cur.execute(temptablequery, 'c1')
 >>> con.commit()
 >>> squery = ('SELECT * FROM #temptable')
 >>> cur.execute(squery)

Thank you for looking at this. Obviously, it is the same with FreeTDS. The proposed way to create the temporary table first and then 'insert from select' works. Now I am wondering why the second query with parameter can access the scope of the temporary table even though it is executed in its own scope, but this is only a matter of my limited understanding.

That is because the query finds the table in the outer scope (i.e. the session), where it was previously created.

I closed the issue as it is not a pyodbc issue.


Configure automated builds for non-master branches

The automated builds for non-master branch do not have the right Dockerfile configured.

All non-master branch builds have been removed.


Difference to Alpine's Anchor plugin

Hi folks,
what is the difference to the Alpine first-party anchor plugin? They say it's based on Floating UI, too? But this plugin seems to have much more features?!
Best, Arne

Yea, it has more features. This plugin was built before the 'anchor' plugin was built.
We use it in Filament PHP.

Thank you for clarification.


Multiple questions: --lib support, tsconfig "extends" option

Hi,
First of all, thanks for typedoc, its great.

Previously I have forgot to mention I am using just --json output, but it probably can't affect questions I have asked bellow.

I would like to ask if the typedoc supports the --lib (or "lib" option in the tsconfig). --lib is not supported directly (there is no way how to pass it to typedoc) and "lib" seems not to be working as tsc reports errors. I am currently using TypeScript 2.5.1 (from typedoc perspective it should be the same as 2.4) with es2015.promise lib and it seems the typedoc is not able to pass the tsconfig correctly to the compiler as it emits number of errors: "Cannot find promise". Compilation itself works well.
Using TypeScript 2.1.4 from C:\Program Files\NodeJS\node_modules\typedoc\node_modules\typescript\lib
Error: Cannot find global type 'Promise'.
...
 An async function or method must return a 'Promise'. Make sure you have a declaration for 'Promise' or include 'ES2015' in your `--lib` option.

Also the tsconfig option "extends" which basically merges two tsconfigs together fails within the typedoc (when I merge everything manually to typedoc.json and pass it as --tsconfig option it works well - except the lib errors ;) ):
TypeError: Cannot convert undefined or null to object
    at TSConfigReader.load (C:\Program Files\NodeJS\node_modules\typedoc\dist\lib\utils\options\readers\tsconfig.js:60:36)
    at TSConfigReader.onDiscover (C:\Program Files\NodeJS\node_modules\typedoc\dist\lib\utils\options\readers\tsconfig.js:31:18)
    at C:\Program Files\NodeJS\node_modules\typedoc\dist\lib\utils\events.js:256:33
    at triggerApi (C:\Program Files\NodeJS\node_modules\typedoc\dist\lib\utils\events.js:106:13)
    at Options.EventDispatcher.trigger (C:\Program Files\NodeJS\node_modules\typedoc\dist\lib\utils\events.js:250:13)
    at Options.read (C:\Program Files\NodeJS\node_modules\typedoc\dist\lib\utils\options\options.js:73:14)
    at CliApplication.Application.bootstrap (C:\Program Files\NodeJS\node_modules\typedoc\dist\lib\application.js:37:22)
    at CliApplication.bootstrap (C:\Program Files\NodeJS\node_modules\typedoc\dist\lib\cli.js:32:49)
    at CliApplication.Application [as constructor] (C:\Program Files\NodeJS\node_modules\typedoc\dist\lib\application.js:33:15)
    at new CliApplication (C:\Program Files\NodeJS\node_modules\typedoc\dist\lib\cli.js:29:23)

I am merging these files:
tsconfig.common.json:

{
  // TypeScript 2.1 compiler configuration
  // COMMON CONFIGURATION (DEBUG/RELEASE)

  "compileOnSave": true,
  "compilerOptions": {
    // output file (single js file will be generated)
    "outFile": "../../js/ajs.js",
    // target ECMA version
    "target": "es5",
    // libs to be used during compilation
    "lib": [ "dom", "es2015.promise", "es5" ],
    // moule system to be used (none, AMD, CommonJS, UMD, System, ES2015)
    "module": "none",
    // don't emit any output when compilation fails
    "noEmitOnError": true,
    // don't emit BOM
    "emitBOM": false,
    // preserve const enums (don't delete from generated code)
    "preserveConstEnums": true,
    // implicit any
    "noImplicitAny": false,
    // TSX/JSX compilation support
    "jsx": "react",
    // ajs.debug.tsx is the React.js replacement but for Ajs debugging purposes only
    "reactNamespace": "AjsDebugTsxFactory"
  },
  "include": [
    "./src/**/*"
  ]
}

tsconfig.Debug.json
{
  // TypeScript 2.1 compiler configuration
  // DEBUG CONFIGURATION

  "extends": "./tsconfig.common.json",

  "compilerOptions": {
    // generate .d.ts declaration file
    "declaration": true,
    // generate source maps
    "sourceMap": true,
    // remove comments
    "removeComments": false
  }

}

tsconfig.json
{ "extends" : "./tsconfig.Debug.json" }

I've been tracking the tsconfig support on #301. You can see the related issues and PRs there.

Great, thanks for links. I plan to take a look on these two issues but I am quiet busy with Ajs and AjsDoc so don't know when I'll find time for it. Hopefully till end of February.

+1

I'm going to close this issue in favour of #301.
@danielweck Please refrain from "+1" or other meaningless comments. It doesn't really change anything for maintainers other than adding noise. If you'd like to contribute productively, we're open to accepting PRs or discussions on solving the issue. The other issue with "+1" is that I don't even know what the "+1" is for - did you want the --lib feature? Or extends? I'm pretty sure extends already works, but if it doesn't you could start by adding a comment with information on what doesn't work instead of "+1".
@aciccarello We should look into making those tests easier to add, extends is something we should be able to quickly add to our current suite of tests.


chore: add owners for tls and observability teams interfaces

Add owners field for observability team's and TLS team's interfaces.

see https://github.com/canonical/charm-relation-interfaces/pull/168#issuecomment-2314981570. comment applies here as well.

Closing this PR in favor of https://github.com/canonical/charm-relation-interfaces/pull/182 which has a cleaner history.


Makefile: build eraser fixes

see my comment here: https://github.com/Azure/eraser/pull/52#issuecomment-897239809


scheduler: add more nil-check code in adjacent_region

What problem does this PR solve?
Fix potential nil panic in adjust-region scheduler after pd leader changed. related pr is https://github.com/pingcap/pd/pull/1250
What is changed and how it works?
Just two nil check.

Thanks @lerencao
can you add a test to simulate nil store here?


Upgrade slack-client to ^2.0.2

The slack-client package has finally fixed the broken ws dependency so theoretically hubot-slack can now be installed on node >= 0.11.  This is a major version change and will likely require changes to this package.  (Or, I'd really like to run my hubot install on a not-ancient version of node.)

#276
And I'm using it on node 4 because I did not know it could not. What's the problem with >= 0.11?

I just cross checked platforms and this issue appears to be specific to Windows. Further details are in #199 . But the issue you referenced is earlier, so I'll close this one in favor of that one. Thanks!


feat!: align types with React Router

Aligning types with those used in React Router to remove the confusion around LoaderArgs/LoaderFunctionArgs etc.
See the changeset for the details and this comment for the desired state

Typed as any

@brophdawg11 I would argue that we should update RR to use unknown instead
https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html#any
Since that would be a breaking change on the RR side, I think it would be best to rename ActionArgs to ActionFunctionArgs and LoaderArgs to LoaderFunctionArgs and implement it here like
export type AppLoadContext = unknown;

export type DataFunctionArgs<Context = unknown> = {
  context: Context;
  params: Params;
  request: Request;
}

Once we also updated this in RR (this should be done in a major version), we can remove it here and just re-export RR types as you wanted to do in this PR

I'd prefer not to replace one set of duplicated types with another.  If any is truly not what we want, I'd rather just keep it as is in Remix today I think.
I think naming the exports the same if they aren't identical is more confusing since then LoaderFunctionArgs is different depending on where you import it form.  With VSCode auto-complete very often incorrectly recommending react-router-dom higher than @remix-run/react in the list - folks may end up with the wrong one unknowingly.  I think the current state of LoaderArgs/LoaderFunctionArgs is actually a benefit if they're different.
FWIW we have chosen any specifically before.  Using unknown is certainly stricter and "better" from a TS purist point of view, but it also feels sometimes like when we type something as unknown, we force all consumers to be purists as well.  I'll defer to @mjackson and @ryanflorence on any official preference though.

I'd rather just keep it as is in Remix today I think

The thing is: if we want to make it unknown at some point, that would be a breaking change, as unknown requires an explicit type check, any doesn't require anything at all
I get the idea of any being "easier to use", but imo that would people give a wrong feeling of (type) safety, so I think we should go with unknown, even if that means people will be forced to do extra checks
Isn't the whole thing about Remix "we learn you how to do it the proper way"?
Having the extra checks is "the proper way", so the way to go imo

I don't have a strong preference either way really, I just would like us to be consistent on types we don't know - stuff the user hands to us somewhere and we provide back to them elsewhere - context, loaderData, handle, location.state (I'm sure there are other's I'm not thinking of at the moment).
The current state is:

React Router
Remix

Context
any
{ [key: string]: unknown }

useLoaderData
unknown
any (via generic)

handle
any
any

location.state
any
any (inherited)

So do we:

Align on any today since it's the smallest change and also does not require a breaking RR change?

We can add a generic to DataFunctionArgs so folks can type it stronger than any
Then in the near future we can export new types based on unknown, deprecate the any ones, and drop the any ones in the next major version of both RR and Remix

Or, move Remix to unknown in v2, and follow the deprecation path to move RR to unknown in v7

This means we'll be exporting duplicate types (LoaderFunctionArgs will be different in Remix than it is in React Router - but maybe only in the default value for the generic)

I'd personally go with option 2 since I think that's where we eventually want to be.

Unsure what's going on in CI - but worried it might be a weird node_modules cache issue.  Maybe closing/re-opening will clear something up...

CI failure seems to be due to https://github.com/shelljs/shelljs/issues/1133


Fix changed-files for cases where no python files changed

Problem
When a PR contains no changed python files, but changed-files is set to true, ruff will run on all files, including ones not changed.
Solution
Pass the input through to the script and short circuit to success in cases where both the flag is set and no python files were changed.

@ffernandez92 can you please approve and merge this PR

not stale


[tests-only] [full-ci] Bump commit id for tests 2022-01-25

Only some line numbers needed to change in expected-failures because some core API feature files have been modified.

@ishank011 this passes CI and can be merged. I don't think that there is any CI problem in master.
The dependabot PRs could be rebased, and see if they pass.


[Server Crash]: Attempted to load class net/minecraft/client/player/LocalPlayer for invalid dist DEDICATED_SERVER

This was a strange one to figure out. After manually pulling mods out on the server side, found out that this mod seems to be the culprit. The bottom of the log file points to a different mod failing but reading it over, many mods are failing and the server loops on just one before it eventually stops. No crash report is created.
The server seems to continue to load and then stops. An issue pops up near the start of the server
Attempted to load class net/minecraft/client/player/LocalPlayer for invalid dist DEDICATED_SERVER
I'm not confident this is the cause, but removing blockcarpentry-1.19.2-<IP_ADDRESS>.jar from the modlist on the server only allows the server to load. Could be some type of conflict? Any ideas?
debug.log
latest.log

Uhhh... I tried to add cross-compatibility between Apotheosis and Blockcarpentry in regards to the Eterna-Stuff when a frame block is given enchanting power. I guess I forgot to check for whether it happens on server or client side ...
I'll look into it. For now please use <IP_ADDRESS> instead. Sorry for the inconvenience

Problem should be fixed now in version <IP_ADDRESS> (which is uploading right now on curseforge). Thanks again for reporting!
Regards, Manu


not working with reality

Hi there
i think it not working with reality config
please recheck with relality
thanks

Hi there i think it not working with reality config please recheck with relality
thanks

The plugin uses xray 1.8.1 and has the ability to connect to reality
I compared the configuration made by vrayNG and flutter_v2ray and both of them have the same output.
According to these things it should work properly

so when i connecto to reality
it print this error : E/getV2rayServerDelay( 6623): go.Universe$proxyerror: infra/conf/serial: failed to parse json config > infra/conf: VLESS users: "flow" doesn't support "xtls-rprx-vision" in this version


ifconfig not found cs go server

i am trying to run a cs go server on the panel but it seems like it can't find ifconfig,so it will crash
here's the log
http://hastebin.com/ukaqocacaw.sql

/cc @parkervcp

Oh i solved this by adding apt-get install -y net-tools to srcds docker Image but now cs go server gets stuck at assigning ip(it fails)

I am unable to reproduce this on my system, and did not encounter any issues while downloading CS:GO though the container.
I am going to assume that these issues are most likely due to the method that you used to move files, and could be either permissions or missing files entirely.


Support latest supabase js v2 (and fix useRealtime & useSubscription)

useSubscription and  useRealtime are completely broken right now because the signature for subscription has changed in v2.  See https://supabase.com/docs/reference/javascript/subscribe

Adding a note: I believe useSignIn is also broken.
Breaking changes: https://supabase.com/blog/supabase-js-v2#new-auth-methods


Macos update!

We should be able to build this project under mac with this update.

Hi, nice work!
but I still have problem building this.
I get
toka@a tinyinst-rs % cargo build --release
   Compiling tinyinst v0.1.0 (/Users/toka/tinyinst-rs)
warning: Generating Bridge files. and building for /Users/toka/tinyinst-rs/target/release/build/tinyinst-15611e53ec155fe2/out/Tinyinst
error: could not find native static library `xed`, perhaps an -L flag is missing?

The following warnings were emitted during compilation:

warning: Generating Bridge files. and building for /Users/toka/tinyinst-rs/target/release/build/tinyinst-15611e53ec155fe2/out/Tinyinst

and there's no xed library when I looked into TinyInst's directory after I followed their build instruction.
Did you see this error too?

Hi, nice work!
but I still have problem building this. I get
toka@a tinyinst-rs % cargo build --release
   Compiling tinyinst v0.1.0 (/Users/toka/tinyinst-rs)
warning: Generating Bridge files. and building for /Users/toka/tinyinst-rs/target/release/build/tinyinst-15611e53ec155fe2/out/Tinyinst
error: could not find native static library `xed`, perhaps an -L flag is missing?

The following warnings were emitted during compilation:

warning: Generating Bridge files. and building for /Users/toka/tinyinst-rs/target/release/build/tinyinst-15611e53ec155fe2/out/Tinyinst

and there's no xed library when I looked into TinyInst's directory after I followed their build instruction. Did you see this error too?

No but i think if you do cargo build --release -vv, you might see that if you dont run under developer powershell or environment without msvc, xed won't compile. i tried to compile Tinyinst on regular powershell and it will give you the same result.

Hi, nice work!
but I still have problem building this. I get
toka@a tinyinst-rs % cargo build --release
   Compiling tinyinst v0.1.0 (/Users/toka/tinyinst-rs)
warning: Generating Bridge files. and building for /Users/toka/tinyinst-rs/target/release/build/tinyinst-15611e53ec155fe2/out/Tinyinst
error: could not find native static library `xed`, perhaps an -L flag is missing?

The following warnings were emitted during compilation:

warning: Generating Bridge files. and building for /Users/toka/tinyinst-rs/target/release/build/tinyinst-15611e53ec155fe2/out/Tinyinst

and there's no xed library when I looked into TinyInst's directory after I followed their build instruction. Did you see this error too?

sorry i read your question wrong. If xed isn't on third party it means it didnt git submodule update --init --recursive to pull down dependencies.

Hi, nice work!
but I still have problem building this. I get
toka@a tinyinst-rs % cargo build --release
   Compiling tinyinst v0.1.0 (/Users/toka/tinyinst-rs)
warning: Generating Bridge files. and building for /Users/toka/tinyinst-rs/target/release/build/tinyinst-15611e53ec155fe2/out/Tinyinst
error: could not find native static library `xed`, perhaps an -L flag is missing?

The following warnings were emitted during compilation:

warning: Generating Bridge files. and building for /Users/toka/tinyinst-rs/target/release/build/tinyinst-15611e53ec155fe2/out/Tinyinst

and there's no xed library when I looked into TinyInst's directory after I followed their build instruction. Did you see this error too?

here are some screen shot

yup windows works, but on macos I can't find xed lib

Um, ok. I got it. xed is intel's xed
I'm testing this on m1mac so xed is not supposed to be there
https://github.com/googleprojectzero/TinyInst/blob/master/CMakeLists.txt#L121

Now this builds for me.
If this change is good for you too, then let's merge
Are you developing with x64 macos btw?

Now this builds for me.
If this change is good for you too, then let's merge
Are you developing with x64 macos btw?

as long as it works on windows after the new commit i am okay with merging. And yes I was developing on x64 macos

Okay let's merge


Default colorscheme for mili files produces materials using black as the color

Describe the bug
Have parallel problem run using "Diablo" . These are closed-side problems.  The problem has upwards of 200 materials.  Combine the "mili" files using xmilics and then create the "mili" Visit file using makemili_driver.  Now open the problem and you get a lot of materials with black as the color, when you plot "filled boundary".  If I manually change the color scheme.  Default color scheme seems really bad.
Helpful additional information

Did VisIt crash:
Did you get wrong results:

To Reproduce
Steps to reproduce the behavior. For example:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Additionally, please attach a (zipped) sessionfile to this ticket to easily reproduce (In the viewer, use File->Save Session).
Expected behavior
A clear and concise description of what you expected to happen.
Attachments

Can you reproduce the bug on our test data?

If so, which file?
If not, access to your data would be very helpful. If the data set is small, please zip and upload it as an attachment. If it is large, please provide instructions for how we can contact you to obtain this data.

Please attach a (zipped) sessionfile to easily reproduce (In the viewer, use File->Save Session).
Please attach any screenshots relevant to understanding the issue.

Desktop

OS and version: [e.g. Ubuntu 14.04]
VisIt Version: [e.g. 2.13.3]
Server info (if applicable):

Additional context
Add any other context about the problem here. Attach any (zipped) relevant files, such as data, configurations, sessionfiles, etc.

Mili files can specify colors for materials, so that may be related to this.

The workflow here, xmilics and makemili_driver seems a bit antiquated...like maybe the new approach to using mili in parallel is either unknown to the user or maybe doesn't work. Either way, we should understand why.

Hi Mark,
My experience recently using makemili_driver on parallel files is not good, especially on the closed side (where the driver for parallel files seems broken).
I’m all for the parallel makemili_driver otherwise.  I used to Visit in parallel on mili files all the time before the switch to the new plugin.  Now it just doesn’t work on parallel databases on the closed side.
Kevin Durrenberger put a ticket in on that quite some time ago, with no response.
Jerome
From: Mark C. Miller @.>
Sent: Tuesday, April 20, 2021 6:04 PM
To: visit-dav/visit @.>
Cc: Solberg, Jerome M. @.>; Author @.>
Subject: Re: [visit-dav/visit] Default colorscheme for mili files produces materials using black as the color (#5640)
The workflow here, xmilics and makemili_driver seems a bit antiquated...like maybe the new approach to using mili in parallel is either unknown to the user or maybe doesn't work. Either way, we should understand why.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://urldefense.us/v3/__https:/github.com/visit-dav/visit/issues/5640*issuecomment-823701215__;Iw!!G2kpM7uM-TzIFchu!kqrzInzRDQIHVVueBgBJ8gh4QHmRk_1qoruEQcnG9YnKeV3ltU8fRBvhoYuzg2ia7w$, or unsubscribehttps://urldefense.us/v3/__https:/github.com/notifications/unsubscribe-auth/ANWLMLECZ3AOO5I6H3STZRDTJYP73ANCNFSM43JDIJ4A__;!!G2kpM7uM-TzIFchu!kqrzInzRDQIHVVueBgBJ8gh4QHmRk_1qoruEQcnG9YnKeV3ltU8fRBvhoYtIvWhwUA$.

My experience recently using makemili_driver on parallel files is not good, especially on the closed side (where the driver for parallel files seems broken).

Ok, thanks for explanation. So, you were kinda sorta forced into using xmilics because makemili_driver on parallel files is not working for you?

Yes.  On the closed side it crashes with segmentation faults/errors, on the files I am trying.
On the open side for the smaller cases that I tried it on recently, it works.  I might have had trouble sometime in the past, but most of the big problems I run are on the closed side.
The users have batch scripts that run ‘xmilics’ then run ‘makemili_driver’ on the combined file, which is why this is not regularly an issue for them on the closed side - that’s so they can view the combined file with Griz, which they still need to do if/until ‘Grizit’ capability exists in Visit.
Jerome
From: Mark C. Miller @.>
Sent: Wednesday, April 21, 2021 12:18 PM
To: visit-dav/visit @.>
Cc: Solberg, Jerome M. @.>; Author @.>
Subject: Re: [visit-dav/visit] Default colorscheme for mili files produces materials using black as the color (#5640)
My experience recently using makemili_driver on parallel files is not good, especially on the closed side (where the driver for parallel files seems broken).
Ok, thanks for explanation. So, you were kinda sorta forced into using xmilics because makemili_driver on parallel files is not working for you?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://urldefense.us/v3/__https:/github.com/visit-dav/visit/issues/5640*issuecomment-824297146__;Iw!!G2kpM7uM-TzIFchu!ggmPZFDXwBL5OnnsUs6YkNZDmEGZ-1KRh7d5AinO_ThzggTTymIlx4REbHSJS3pC2Q$, or unsubscribehttps://urldefense.us/v3/__https:/github.com/notifications/unsubscribe-auth/ANWLMLENMBRDNJDILAEAY6DTJ4QIHANCNFSM43JDIJ4A__;!!G2kpM7uM-TzIFchu!ggmPZFDXwBL5OnnsUs6YkNZDmEGZ-1KRh7d5AinO_ThzggTTymIlx4REbHQJOBC__Q$.

@solberg2  I tried to search for a related ticket from Kevin but didn't finding anything (my search might not be great). if possible, would be good to have that ticket and those details connected here.

Hi Cyrus,
From what I understand, Kevin communicates this stuff to Alister and he is the one who submits the tickets.
Whether or not there is a ticket, it is still true that the SCF version of makemili_driver doesn’t work for parallel files, and actually the “old” version makemili_serial doesn’t work at all.
Jerome
From: Cyrus Harrison @.>
Sent: Friday, April 23, 2021 12:44 PM
To: visit-dav/visit @.>
Cc: Solberg, Jerome M. @.>; Mention @.>
Subject: Re: [visit-dav/visit] Default colorscheme for mili files produces materials using black as the color (#5640)
@solberg2https://urldefense.us/v3/__https:/github.com/solberg2__;!!G2kpM7uM-TzIFchu!h4_NeKAlxvB2-GvqlOLrBZbG8zuOR-tmwYOwhsfco-x8VUVXVbEgNKC36sRj_RwMaw$ I tried to search for a related ticket from Kevin but didn't finding anything (my search might not be great). if possible, would be good to have that ticket and those details connected here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.us/v3/__https:/github.com/visit-dav/visit/issues/5640*issuecomment-825880018__;Iw!!G2kpM7uM-TzIFchu!h4_NeKAlxvB2-GvqlOLrBZbG8zuOR-tmwYOwhsfco-x8VUVXVbEgNKC36sTs4CbHeA$, or unsubscribehttps://urldefense.us/v3/__https:/github.com/notifications/unsubscribe-auth/ANWLMLDLKTBGC74WDMETBBLTKHEY3ANCNFSM43JDIJ4A__;!!G2kpM7uM-TzIFchu!h4_NeKAlxvB2-GvqlOLrBZbG8zuOR-tmwYOwhsfco-x8VUVXVbEgNKC36sSVKFylaA$.

 He gave me the file on quartz, so I can give it to someone to take a look at it. I was able to reproduce the behavior. I looked in the ".mili" file, and I didn't see any color information in the file. Looking at the filled boundary plot, the colors came from the levels color map, but they were definitely assigned in a somewhat random manner, with black being in the mix. Normally the colors are always assigned in a consecutive manner from the color map.

What I found is that the color map is “grayed out” upon first plotting, but you can click it and choose the default colormap, and then things are fine.
From: Eric Brugger @.>
Sent: Thursday, April 29, 2021 3:51 PM
To: visit-dav/visit @.>
Cc: Solberg, Jerome M. @.>; Mention @.>
Subject: Re: [visit-dav/visit] Default colorscheme for mili files produces materials using black as the color (#5640)
Doug Faux also reported a problem with a bunch of the materials being colored black from a filled boundary plot. He gave me the file on quartz, so I can give it to someone to take a look at it. I was able to reproduce the behavior. I looked in the ".mili" file, and I didn't see any color information in the file. Looking at the filled boundary plot, the colors came from the levels color map, but they were definitely assigned in a somewhat random manner, with black being in the mix. Normally the colors are always assigned in a consecutive manner from the color map.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.us/v3/__https:/github.com/visit-dav/visit/issues/5640*issuecomment-829645576__;Iw!!G2kpM7uM-TzIFchu!hXhiV6h5m2TI57OYvPgV_r5AH9A5nm9ArnPYPBkxz6vs9WzobWSLXuOWA9Cc7ezihQ$, or unsubscribehttps://urldefense.us/v3/__https:/github.com/notifications/unsubscribe-auth/ANWLMLA7CJPOW7PIXDOGLEDTLHPHDANCNFSM43JDIJ4A__;!!G2kpM7uM-TzIFchu!hXhiV6h5m2TI57OYvPgV_r5AH9A5nm9ArnPYPBkxz6vs9WzobWSLXuOWA9ALcgmwdg$.

Thanks for the workaround. I'll let Doug know. We will still fix this behavior, it is definitely wrong.

I wonder if this is a config file problem. Can someone test by running VisIt with -noconfig on the command line that launches VisIt?

Hi Eric,
I took a quick look at the ticket. If the issue is that the material colors are chosen randomly when they aren’t specified in the .mili file, this is a very easy fix (this is intentionally triggered on line 3869 of avtMiliFileFormat.C). It sounds like the colors should be incremental? I’m assuming this means 0->255, starting at 0?
Alister

On second thought, I don’t think that my 0->255 logic makes sense… I guess I’d need some more insight to what “incremental” means in this context.

I think the fix is that if the colors are not chosen it should use the default colormap (e.g. just do what the workaround does), like it did for earlier version of Visit/the mili plugin.  Not sure whether the behavior changed because of the new Visit or the new plugin, they came around at the same time.
From: Eric Brugger @.>
Sent: Wednesday, May 5, 2021 7:16 AM
To: visit-dav/visit @.>
Cc: Solberg, Jerome M. @.>; Mention @.>
Subject: Re: [visit-dav/visit] Default colorscheme for mili files produces materials using black as the color (#5640)
On second thought, I don’t think that my 0->255 logic makes sense… I guess I’d need some more insight to what “incremental” means in this context.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.us/v3/__https:/github.com/visit-dav/visit/issues/5640*issuecomment-832723977__;Iw!!G2kpM7uM-TzIFchu!jHcG2IVIDta7FE1SpARtFC9pdwvmgM6324PLsRtv92TGcsRJntBsBHLsWtDQsHDshw$, or unsubscribehttps://urldefense.us/v3/__https:/github.com/notifications/unsubscribe-auth/ANWLMLGLB3OXV3EJ7WOENSLTMFHK5ANCNFSM43JDIJ4A__;!!G2kpM7uM-TzIFchu!jHcG2IVIDta7FE1SpARtFC9pdwvmgM6324PLsRtv92TGcsRJntBsBHLsWtABwc9K-Q$.

I agree. I don't think we need to set the colors at all. If we don't set them, VisIt will use the defaults.


Bad Request - Malformed Algorand transaction

Every time I am running the swap example it throws "Bad Request - Malformed Algorand transaction".
Thank you in advance.

I was using a different account that I intended to use. Sorry.


refactor(connector): [Noon] Remove Default Case Handling

Type of Change

[ ] Bugfix
[ ] New feature
[ ] Enhancement
[x] Refactoring
[ ] Dependency updates
[ ] Documentation
[ ] CI/CD

Description

Addresses Issue #2277
Modified crates/router/src/connector/noon/transformers.rs

Convert NotImplemented to NotSupported in default case

Additional Changes

[ ] This PR modifies the API contract
[ ] This PR modifies the database schema
[ ] This PR modifies application configuration/environment variables

Motivation and Context

How did you test it?

Checklist

[x] I formatted the code cargo +nightly fmt --all
[ ] I addressed lints thrown by cargo clippy
[ ] I reviewed the submitted code
[ ] I added unit tests for my changes where possible
[ ] I added a CHANGELOG entry if applicable

Hey @SagarDevAchar ,
The changes you made is right but you also have to fill the default cases for WalletData (line - 248) Please fill the matching arms for that too.

@swangi-kumari got it!

Hey @SagarDevAchar  ,
Pls address the CI fails
Run cargo +nightly fmt for formatting.
and cargo run --features openapi -- generate-openapi-spec for validating generated openApi spec file. And commit it.

@swangi-kumari

Pls address the CI fails

Will do!

and cargo run --features openapi -- generate-openapi-spec for validating generated openApi spec file. And commit it.

I cannot seem to get cargo run --features openapi -- generate-openapi-spec or cargo clippy to run successfully
I am stuck with errors like:
error[E0432]: unresolved import `core::any::Demand`
.
.
error[E0432]: unresolved imports `core::any::Demand`, `core::any::Provider`
.
.
error[E0425]: cannot find function `request_ref` in module `any`
.
.

How do I resolve this?
Is there a different version / build of rust I need to be using? (My rustc version is 1.75.0-nightly)

@SagarDevAchar You don't necessarily need the nightly toolchain for compiling our code, please use the stable toolchain for the purpose. For formatting code alone, you can use the nightly toolchain using the command cargo +nightly fmt.
And I checked the changes in this PR, I don't think you need to specify the generics for the return type (Ok::<NoonPaymentData, E>(...)), only using Ok(...) should suffice.

@SanchithHegde

@SagarDevAchar You don't necessarily need the nightly toolchain for compiling our code, please use the stable toolchain for the purpose. For formatting code alone, you can use the nightly toolchain using the command cargo +nightly fmt.

Got it!

And I checked the changes in this PR, I don't think you need to specify the generics for the return type (Ok::<NoonPaymentData, E>(...)), only using Ok(...) should suffice.

Well, on router compilation with just Ok(...), the toolchain gave out errors stating the need for type annotations for Result

Hence, I have added the type annotations to Ok(...) as Ok::<NoonPaymentData, errors::ConnectorError>(...) and the CI Checks succeed. Please review and let me know of any changes necessary!

Hey @SagarDevAchar  ,
Thanks a bunch for all your contributions! We've got a little something for you to show our appreciation.
Just take a moment to fill out this form, and get ready for some awesome swag coming your way.
Thanks!


Goto forbidden by Go

Go has more strict rules regarding what goto jumps are valid.
cxgo currently doesn't reflow goto automatically. So "bad" goto will fail to compile in Go.
There is a workaround implemented in cxgo as one of the "ugly" ways to make the code compile. This workaround will completely flatten the code in a specified function.
We can try to implement a proper reflow algorithm, since those kind of goto statements are quite common.

Solving the structured control flow problem once and for all is a good article for anyone wanting to solve this issue


Playlist features

Added option to increase timer resolution.
Defaults to false with 500ms timer.

@istnv can you explain the logic you changed @480?  I'm may not be following it correctly, so I want to make sure its doing what you're expecting it to.

Reading through after some sleep.
It should be (!(IS_STOPPED) && (self.hires))
I'll have another patch in a while.
I also found another way to get the player out of sync with the modules internal playlist so I'm working on that.

Sounds good ... just drop all that here.

Should be ready, now.
Playlist optimization was too aggressive and missed changes if the playlist was re-sorted.


Executor compute

Add executor.compute method
    def compute(self, *args, sync=False):
        """ Compute dask collections on cluster

        Parameters
        ----------
        args: iterable of dask objects
            Collections like dask.array or dataframe or dask.value objects
        sync: bool (optional)
            Returns Futures if False (default) or concrete values if True

        Returns
        -------
        Tuple of Futures or concrete values

        Examples
        --------

        >>> from dask import do, value
        >>> from operator import add
        >>> x = dask.do(add)(1, 2)
        >>> y = dask.do(add)(x, x)
        >>> xx, yy = executor.compute(x, y)  # doctest: +SKIP
        >>> xx  # doctest: +SKIP
        <Future: status: finished, key: add-8f6e709446674bad78ea8aeecfee188e>
        >>> xx.result()  # doctest: +SKIP
        3
        >>> yy.result()  # doctest: +SKIP
        6
        """

cc @broxtronix

This depends on a small change within dask.  https://github.com/blaze/dask/pull/869

Cool!  I just pulled in the changes to both Blaze and Distributed.  The new compute() methods works as described, returning a Futures object (or list of them) instead of a finished computation.  Futures are nice.
Progress bar doesn't work quite yet, but I imagine you are still working on that.  Currently this:
results = executor.compute(*colormapped_images);
distributed.diagnostics.progress(results)

produces this error:
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-19-4febf5eb5c1f> in <module>()
      4 #with distributed.diagnostics.progress(colormapped_images, notebook = False):
      5 results = executor.compute(*colormapped_images);
----> 6 distributed.diagnostics.progress(results)

/Users/broxton/anaconda3/lib/python3.5/site-packages/distributed-1.5.0-py3.5.egg/distributed/diagnostics.py in progress(futures, notebook, multi)
    349             bar = MultiProgressWidget(futures)
    350         else:
--> 351             bar = ProgressWidget(futures)
    352     else:
    353         bar = TextProgressBar(futures)

/Users/broxton/anaconda3/lib/python3.5/site-packages/distributed-1.5.0-py3.5.egg/distributed/diagnostics.py in __init__(self, keys, scheduler, minimum, dt)
    260 class ProgressWidget(Progress):
    261     def __init__(self, keys, scheduler=None, minimum=0, dt=0.1):
--> 262         Progress.__init__(self, keys, scheduler, minimum, dt)
    263         from ipywidgets import FloatProgress
    264         self.bar = FloatProgress(min=0, max=1, description='0.0s')

/Users/broxton/anaconda3/lib/python3.5/site-packages/distributed-1.5.0-py3.5.egg/distributed/diagnostics.py in __init__(self, keys, scheduler, minimum, dt)
     88             if time.time() > start + 1:
     89                 raise ValueError("Keys not found: %s" % str(keys -
---> 90                     scheduler.in_play))
     91
     92         self._start_time = default_timer()

ValueError: Keys not found: {(<Future: status: finished, key: finalize-80bbba60de0d198544e88b92df8d7d4a>, <Future: status: finished, key: finalize-323d0068d294131624212d74c376877d>, <Future: status: finished, key: finalize-b66f2cf495a2e2ce1a830bb055a5452d>, <Future: status: finished, key: finalize-d2cc247a160c5e4ddac4723f2e44a59a>, <Future: status: finished, key: finalize-6dde2f2942c0d30afb37b5a5ffc7eb60>, <Future: status: finished, key: finalize-2552974878a62eac0585b123ca6ceebb>, <Future: status: finished, key: finalize-6d8141e4f47e9862088dcbe06ac17077>, <Future: status: finished, key: finalize-5d068359e49c6c6b458a3dbf8ca0fb46>, <Future: status: finished, key: finalize-f7b8a73fd99733268dffef45f8e246ae>, <Future: status: finished, key: finalize-e36c0052c4df250eded67712aa2c4b85>, <Future: status: finished, key: finalize-93fc3b0b117a18697f9900f1b1dcef19>, <Future: status: finished, key: finalize-57417635ed2ec08158e2674508622c74>, <Future: status: finished, key: finalize-cc6a6e8f7137887dbbe90a6b32c02b23>, <Future: status: finished, key: finalize-40d9b640e5a97bf1889e70935fd5ce31>, <Future: status: finished, key: finalize-7d034e511efbcb605e4278e271aaede2>, <Future: status: finished, key: finalize-edf3e6fdd5495c03988eaf850aca4a04>, <Future: status: finished, key: finalize-ebe3305c8b34a685b74ea3fede6dfbba>, <Future: status: finished, key: finalize-92a3518df496a74f94da903b187e9974>, <Future: status: finished, key: finalize-dbe0e6af1336a7e6710606d06d6f86e0>, <Future: status: finished, key: finalize-29440e905e7a633ec50f86fe8f6ef07d>)}

although
distributed.diagnostics.progress(results[0])

does indeed work!  (So, it's just the list of Futures that doesn't quite work yet.)

Ah, progress only expands out sets and lists, not tuples.  Compute produces tuples.
I'll have to change one or the other to make the design more consistent.
The following should work immediately though
>>> progress(list(results))

I also recommend playing with the multi=True option
>>> progress(list(results), multi=True)

It's a bit fancier and also a bit less tested.

Compute now returns a list.  Progress uses multi=True by default.

Oh, this is also a deeply nested problem.  One sec, fix coming up.

Aha!  That's an easy workaround, and does indeed fix the immediate problem.  Beautiful asynchronous progress bars in the notebook are working for me!  Amaze-balls!
Two minor things:

Setting multi = True didn't seem to work for me yet.  It doesn't generate any progress bar at all in my example computation (same as before, with colormapped images), perhaps because I haven't specified which functions I'd like to track?  That looks like something that the lower level API for MultiProgress and MultiProgressWidget accept as their func arguments?  An ideal default would be to track all unique functions involved with the computation, but I realize that may be a bit difficult to set up.  I'd be totally happy specifying functions to track by hand if that's easiest for now.

I was having fun creating multiple asynchronous progress bars for the same set of results (of course!), and notice that the progress bars seem to only track portions of the computation that have not yet completed.  That is, if I create a progress bar after half the computation is complete on the cluster, it still starts at zero and counts up to 100%.  I think I'd like it better if it noticed that 50% of the computation was finished, and started at 50% then counted up to 100%.   Again, this is not a super must-have, and I'd be totally content with it as-is.  The ability to monitor computations without locking up notebook execution is already seriously amazing!  Thanks!!

The default splitting function aligns well with how dask names things.  If you're using dask like naming conventions (tuples, strings with hyphens) then it should come out ok.  I'll take a look at what's going on with MultiProgressBar.
Nested futures supported in a recent commit.

Current policy is to track all keys on which the futures depend that have not yet been completed.  This is less convenient if you start fresh computations all the time and more convenient if you're basing novel computations off of old ones.  I'm not sure which policy is best long term.  It sounds like there is at least value to supporting the "all keys policy."  Will add in a bit

Definitely no rush on that one.  I think both policies have their merits, and I can adjust my expectations on what the progress bars are displaying.
Regarding the MultiProgressBar, I wonder if it may be having trouble because I am nesting pretty much all of my do() statements inside list comprehensions:
from dask.imperative import do, value

test_images        = [ do(compute_test_image)(z) for z in MOVIE_Z_SAMPLES ]
amplitude_ranges   = [ do(amplitude_range)(im) for im in test_images ]
phase_ranges       = [ do(phase_range)(im) for im in test_images ]

colormapped_images = [ do(colormap_and_combine)(*args) for args in zip(test_images,amplitude_ranges, phase_ranges) ]

I need to run out for a bit, but will be glad to continue testing things out later this evening.  Again, thanks for the quick turnaround today!

By default dask.do will name keys by func-hash so you'll have names like
compute_test_image-147287245425

MultiProgressBar will split on the hyphen, and grab out the name compute_test_image.  Let me clean some things up though.

Also out for a bit.

I recommend checking in sometime after late tomorrow morning.

Sounds great!  Again, no rush at all.  This is super non-critical.  Thanks!

Oh, if you're in the mood to try things out I'm pretty happy to keep facilitating that and maintain a tight feedback loop.  This feedback is really valuable.
ProgressBars are more sturdy now.  A fair amount of the behavior is now tested.  Additional play-testing is quite welcome.

Still pushing on this a bit.  Turns out simultaneously managing the Jupyter and distributed event loops is a bit tricky.

Roger that.  I've been following along and watching the progress.  Just ping me when things converge and I'll happily take it out for a spin!

With recent changes I think that this is again ready to go.

Alrighty!  This is definitely very close to working for me.  When I run
results = executor.compute(*colormapped_images)
distributed.diagnostics.progress(results, multi = True)

I do now get multiple dynamically updating progress bars.  Instead of a few progress bars for amplitude_range, colormap_and_combine and other functions, I instead see hundreds of them, one for each individual function call.  So, for example, I see hundreds of progress bars for
amplitude_range-0130d7d0-fdba-435e-8ee8 [1/1]
amplitude_range-02324839-ac9c-451c-88c2 [1/1]
colormap_and_combine-092a8635-ad06-4362-82c6 [1/1]
colormap_and_combine-0a8e767a-d67f-443b-a4d3 [1/1]
...and many more...

OK, we'll have to tweak the split key function.  One moment please.

See https://github.com/blaze/distributed/commit/c7c7c32d5bc19833379a68b0f9ea684ceddf77d6

Out of curiosity, how did hundreds of progressbars perform?
We should probably group everything after the top ten or so

Bingo!  Works like a charm now.  Thank you!
Rendering hundreds of progress bars worked surprisingly well.  There was a brief pause of a few seconds as the web browser got its act together for the initial rendering of the new elements of the DOM, but after that it remained surprisingly responsive.  I agree, though... probably best to cap the number of progress bars at 10-20 just to prevent crazy numbers of them.  (Also, I wonder what happens if you use anonymous functions intermixed with do() statements... probably these would each get their own progress bar?)
In any case, this is awesome... having the progress bars broken out by function already gives me some additional insight into the real-time execution of the algorithm.  For example, when one function is blocked waiting for results from other functions, its progress bar pausees.  Some functions clearly run faster than others, hinting at functions that might need to be sped up.  Progress for early algorithms finishes up sooner than progress for functions with many dependencies.
Best of all, these progress bars help me to remain in the notebook context, rather than switching my attention out a separate web console to monitor the status of my jobs.  And I can keep on computing in the notebook while this computation happily & asynchronously cranks away in the background.  Simply. Amazing.
The formatting of the progress bars could use a little improvement, just to justify and align them for better readability.  Some HTML + CSS magic is all that is needed there.  If you want, I'd be willing to try my hand at sprucing up the progress bars.  I could create a new PR after you merge in this one.  It would be a fun (if modest) way for me to get my hands dirty in the distributed codebase.

That sounds great.  I'd be quite happy to leave visual design to others.  If you can bang on this for a little while I'll appreciate it.  I'm going to merge in some other work over at https://github.com/blaze/distributed/pull/38 and then merge this on top of it.  Shooting for end of day.

And by "bang on this" I mean, subject progressbars to sufficiently varied load to verify that they don't need any fundamental changes and never crash.

Sounds great.  I'll put the progress bars through a few more tests and see how they do.

Ok, after testing this out a bit I haven't encountered any huge problems.  The one minor thing I noticed is that the HTML progress bar is suppressed for some reason in cells where you also use the %%time cell magic.  Normally you would only need one or the other, so this probably won't come up too often.  Indeed, %%time doesn't even make much sense now that functions are asynchronous and returning immediately.  However, this could be a potential point of confusion if users are expecting their progress bar to appear and it doesn't due to cell magic.
Aside from that it all works great.

This appears to be an IPython notebook thing.  The following cells also don't display the progressbar:
%%time
from ipywidgets import FloatProgress
f = FloatProgress(min=0, max=1)
f.value = 1.0
f

Glad to hear things are working well.  I'll write up some docstrings, maybe a little documentation and then merge this once tests pass.  Thanks gain for your continued feedback and testing on this.
If you do want to play with layout and such, the relevant class is MultiProgressWidget, and you're looking for self.bars, self.texts, and self.widget.  Functions like _update should give you a pretty good idea of how to manipulate things.
https://github.com/ipython/ipywidgets/blob/master/examples/notebooks/Index.ipynb

Sounds great.  I'll take a crack at styling the progress bars tomorrow once you've merged all of this in.  Perhaps I'll find a way to work around the cell magic issue and/or I'll file an iPython bug.
Thanks again for investing time in this!

OK, I'm going to merge this.  As a warning this does introduce a slight race condition.    I think I know what the issue is though; I'll fix this tomorrow in separate work.


[git] mark all files in the gen folders as auto-generated

Problem
Changes in the auto-generated ZAP files hinder the review process.
Change overview
This PR ensures that GitHub does not load the diff from auto-generated ZAP files in the pull request by default. This is achieved by marking all files in the gen folders as auto-generated using the official GitHub's library called linguist. While this is not a perfect solution, it may increase the focus on important logic changes during code review.
Testing
Manually modified few files in gen folders and a few not auto-generated and inspect Github's diff view.
Check it here: https://github.com/LuDuda/connectedhomeip/commit/66538f1db25c936b420c7f84f62a3499b8d8cd25

@LuDuda @vivien-apple We have some auto-generated stuff not in "gen" folders too that might be worth applying the same treatment to.


Update nrf pacs

Ok, this change to USB should be alright. I checked that the variant is correct for each


[Event Request] Report 87 - Change Publisher OnAfterCopyGenPostingSetup

In this request
#311 (comment)
it was asked for a Publisher containing the flags to trigger which area (Sales / purchase / inventory / manufacturing) should be copied

The Publisher was added in the meantime, but the flags are missing.
==> Please add them - otherwise the Publisher doesn't make sense.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


g2p branch needs updating

The g2p branch should be updated by merging from master before the initial code drop. See #882 for example.

updated from master

Can you make a PR with this update please @bwalsh? We need to have the g2p feature branch in this repo level with master. See #882 for an example of how this works.

Done in #927


Improve repo structure

great! merged

@Unitech
Remember to update the build settings on docker hub
Your welcome
That way we shouldn't update the folder name each time the nodejs team release a new version and the documentation is always up-to-date 👍

Done.
That make sense :+1:


Ensure network protocol compatibility to taker 0.5.0 and 0.5.3

It seems the API changes for support ETHUSD broke backwards compatibility in an unexpected way:
2022-08-09 14:12:29
{"timestamp":"2022-08-09T14:12:29.904465676Z","level":"DEBUG","fields":{"message":"Failed to process maker offers: Failed to decode maker offers.: JSON error: missing field `leverage` at line 1 column 391: missing field `leverage` at line 1 column 391","peer":"12D3KooWEsK2X8Tp24XtyWh7DM65VfwXtNH2cmfs2JsWmkmwKbV1"},"target":"xtra_libp2p_offer::taker","span":{"err":"Failed to decode maker offers.","name":"fallible task handle_error"}}

2022-08-09 14:11:29
{"timestamp":"2022-08-09T14:11:29.926697913Z","level":"DEBUG","fields":{"message":"Failed to process maker offers: Failed to decode maker offers.: JSON error: missing field `leverage` at line 1 column 391: missing field `leverage` at line 1 column 391","peer":"12D3KooWEsK2X8Tp24XtyWh7DM65VfwXtNH2cmfs2JsWmkmwKbV1"},"target":"xtra_libp2p_offer::taker","span":{"err":"Failed to decode maker offers.","name":"fallible task handle_error"}}

2022-08-09 14:10:29
{"timestamp":"2022-08-09T14:10:29.86286764Z","level":"DEBUG","fields":{"message":"Failed to process maker offers: Failed to decode maker offers.: JSON error: unknown variant `EthUsd`, expected `BtcUsd` at line 1 column 76: unknown variant `EthUsd`, expected `BtcUsd` at line 1 column 76","peer":"12D3KooWEsK2X8Tp24XtyWh7DM65VfwXtNH2cmfs2JsWmkmwKbV1"},"target":"xtra_libp2p_offer::taker","span":{"err":"Failed to decode maker offers.","name":"fallible task handle_error"}}

2022-08-09 14:09:29
{"timestamp":"2022-08-09T14:09:29.833906787Z","level":"DEBUG","fields":{"message":"Failed to process maker offers: Failed to decode maker offers.: JSON error: unknown variant `EthUsd`, expected `BtcUsd` at line 1 column 76: unknown variant `EthUsd`, expected `BtcUsd` at line 1 column 76","peer":"12D3KooWEsK2X8Tp24XtyWh7DM65VfwXtNH2cmfs2JsWmkmwKbV1"},"target":"xtra_libp2p_offer::taker","span":{"err":"Failed to decode maker offers.","name":"fallible task handle_error"}}

2022-08-09 14:08:59
{"timestamp":"2022-08-09T14:08:59.833733485Z","level":"DEBUG","fields":{"message":"Failed to process maker offers: Failed to decode maker offers.: JSON error: missing field `leverage` at line 1 column 390: missing field `leverage` at line 1 column 390","peer":"12D3KooWEsK2X8Tp24XtyWh7DM65VfwXtNH2cmfs2JsWmkmwKbV1"},"target":"xtra_libp2p_offer::taker","span":{"err":"Failed to decode maker offers.","name":"fallible task handle_error"}}

Here's the query to reprocude.

I'm tackling this with #2680. The new protocol will be incompatible, but I will make sure that the old one doesn't suffer from these problems by:

[ ] Only allowing broadcasting offers of BTCUSD.
[ ] Reintroducing the leverage field in the offer.

This should have been fixed in #2680, but let's monitor this.


Fixed encoding guessing: only search for meta tags in HTML bodies

Description
Real world issue: https://www.youtube.com/s/desktop/245f415e/jsbin/desktop_polymer_inlined_html_polymer_flags.vflset/desktop_polymer_inlined_html_polymer_flags.js
This JavaScript file contains a matching meta tag and the encoding ended up being a literal backslash \ which I passed along to codecs.lookup(enc).name. The added check will catch html and xhtml.
I think we want to rewrite/improvie the guessing anyway with better tests, e.g. #4415
Checklist

[ ] I have updated tests where applicable.
[x] I have added an entry to the CHANGELOG.

I don't think we should rely on a content-type header being set, that's precisely the point here - the content type is specified in the HTML only. To me it looks like we should much rather improve our detection heuristic to not trigger on your file?
While we're at it, we should also reduce the search to the first 1024 bytes by using re.match(r".{0,1024}")... :)

I don't think we should rely on a content-type header being set, that's precisely the point here - the content type is specified in the HTML only

Could you point to some real world test-case here? I thought we're only looking at the meta tag because of the encoding, not because of the content-type. I don't think any browser beyond Internet Explorer does any content-type sniffing aynmore so if there is no content-type header it will never be upgraded to HTML and hence the meta tag does not have any effect. But maybe I'm missing a use-case here?

To me it looks like we should much rather improve our detection heuristic to not trigger on your file?

I'd say it has to be html in content_type or content_type is None, that should catch all cases? In my case it's correctly served as JavaScript so there is absolutely no reason to sniff a different content-type (which this code doesn't, it just tries to guess the encoding).

While we're at it, we should also reduce the search to the first 1024 bytes by using re.match(r".{0,1024}")... :)

Yes, especially since that YouTube JavaScript has 7.7 MB :smile:

Could you point to some real world test-case here? I thought we're only looking at the meta tag because of the encoding, not because of the content-type. I don't think any browser beyond Internet Explorer does any content-type sniffing aynmore so if there is no content-type header it will never be upgraded to HTML and hence the meta tag does not have any effect. So why should mitmproxy do it? But maybe I'm missing a use-case here?

If you have a proper content-type header, that header could/should already set the charset (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type#directives). So assuming a proper HTML content type is slightly optimistic. That being said, I have no idea what modern browsers are doing.
I know that requests has given up at some point and now exclusively relies on chardet. Not sure what's the current state, but that used to have terrible performance. Chromium apparently does something similar with https://opensource.google/projects/ced. Firefox has an even newer thing: https://hsivonen.fi/chardetng/.

It could be html in content_type or content_type is None, that should catch all cases?

That sounds good to me! We can then also do the same "is None" for the CSS rule right below. :)

that's precisely the point here - the content type is specified in the HTML only

That's not necessarily true, e.g. <meta charset="utf-8"> without http-equiv.

I think one option that https://github.com/mitmproxy/mitmproxy/issues/4415#issuecomment-768345919 is missing is to try decoding inside text and if it fails transparently fall back to latin-1. Does that make sense? This would be useful regardless of what method we're going to use to detect the charset to make sure that text always works. And if the charset was correct or if you never even access text then there is no downside.

One issue with the chardet approach that neither Google, nor Firefox or request have: in mitmproxy bodies are not immutable. So there might be a content-type header with a funny charset but the body does not use funny characters. Now chardet boldly claims this is latin-1 or utf-8. And now someone uses the text setter and we update content with utf-8 bytes and mitmproxy forwards the HTML to the browser. The browser sees the content-type header and might break the utf-8 characters inside the body, depending on what they actually do :sweat_smile:
I think other projects don't suffer from that, because the bodies are immutable. If you're scraping or analyzing dumps you only care about being able to read the bodies properly, not write them.

that's precisely the point here - the content type is specified in the HTML only

That's not necessarily true, e.g. <meta charset="utf-8"> without http-equiv.

My previous comment wasn't phrased well. What I meant is: Ideally everyone would also have proper Content-Type headers, but in practice we check for the meta tag because people can't get their headers right.
You may also "enjoy" reading https://www.w3.org/International/questions/qa-html-encoding-declarations.en.

I think one option that #4415 (comment) is missing is to try decoding inside text and if it fails transparently fall back to latin-1. Does that make sense?

That's actually a neat idea. 👍 Latin1 is quite terrible, but in contrast to UTF-8 it's wonderfully bijective. 😁
We do need to make sure that we also re-encode it properly in set_text then. For all instances where we fall back to decoding with latin1, we need to also then re-encode with latin1. That probably means refactoring _guess_encoding to not take arguments and always return an encoding that can be used to decode the current body.

One issue with the chardet approach that neither Google, nor Firefox or request have: in mitmproxy bodies are not immutable. So there might be a content-type header with a funny charset but the body does not use funny characters. Now chardet boldly claims this is latin-1 or utf-8. And now someone uses the text setter and we update content with utf-8 bytes and mitmproxy forwards the HTML to the browser. The browser sees the content-type header and might break the utf-8 characters inside the body, depending on what they actually do 😅

Yes, that's also a good point. I'd generally be leaning heavily towards not using chardet anyways, it's just another dependency for relatively little benefit.

I don't think we should rely on a content-type header being set, that's precisely the point here - the content type is specified in the HTML only

Since this just came up again, could you please double check what you said there? I think the point here is that the content-type header does not specify a charset. Not that the content-type is missing completely. Without a content-type header we should just straight up assume application/octet-stream and force latin-1. Anything else would be insane. Unless you have a convincing argument and a real world URL to proof it (one you didn't host yourself or a someone your know or is related to you).
Here's how I'm currently wrapping _guess_encoding in my addon. I need to normalize the encoding name and make sure it doesn't crash. I never use text at all, Node.js only passes content back and forth, that's why I need to make sure I can properly decode it on the other end.
def __guess_encoding(self, message: mitmproxy.http.Message, content: bytes) -> str:
    enc = message._guess_encoding(content)

    try:
        # Normalize the name, e.g. latin-1 becomes iso8859-1 or UTF8 becomes utf-8.
        enc = codecs.lookup(enc).name

        # If we detected a more specific encoding than iso8859-1, make sure the bytes actually decode with it.
        if enc != "iso8859-1":
            try:
                codecs.decode(content, enc)
            except ValueError:
                enc = "iso8859-1"
    except LookupError:
        # Could not look up and normalize the name, fall back to iso8859-1.
        enc = "iso8859-1"

    return enc

I am happy with this so far, as it is robust (e.g. the GIF with charset=UTF-8 will fall back to iso8859-1). But now we need to improve our heuristics to get some better results.
Ideas:

Missing content-type -> early exit latin-1
Content-type has charset -> done, we trust it (but make sure it actually decodes, evil UTF-8 GIFs beware)
Otherwise check the content-type for known types and apply heuristics, e.g. for HTML look at meta tags, for CSS look at @charset, for JSON force UTF-8, for other known TEXT (xml, svg, plain, ...) types look at BOM.
If the above fails add some defaults, e.g. JavaScript as UTF-8 (but make sure it decodes and doesn't crash)

Without a content-type header we should just straight up assume application/octet-stream and force latin-1

I will soften this up a bit, as it makes sense to look for BOM. Chances that it is a text file is much higher than that your random binary blob starts with BOM.
But it's complicated.
Also see https://github.com/codeprentice-org/sniffpy
Which doesn't concern charset/encoding at all, just the mime type. Did I say it's complicated? We need a third party.

Refs https://github.com/mitmproxy/mitmproxy/issues/5152


BDI: Cannot use autonumber field as Contact Custom Unique ID

Because an autonumbered field cannot be included in the field mapping, if you attempt to use it to match contacts (Contact Custom Unique ID) you get an error like this "SObject row was retrieved via SOQL without querying the requested field: Contact.ConstituentID__c" when you process the batch - it is fine on a dry run.

Hi @Filikin,
We don't provide support via GitHub. Please could you instead post this on the Power of Us Hub NPSP group here: https://powerofus.force.com/s/group/0F980000000CjReCAK/nonprofit-success-pack
Thank you,
Michael

hi Michael,
so are you saying that this isn't a bug?
regards,
Eamon

From: mbeaty-sf<EMAIL_ADDRESS>Sent: Wednesday 14 October 2020 18:17
To: SalesforceFoundation/NPSP<EMAIL_ADDRESS>Cc: Eamon Kelly<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [SalesforceFoundation/NPSP] BDI: Cannot use autonumber field as Contact Custom Unique ID (#5946)
Hi @Filikinhttps://github.com/Filikin,
We don't provide support via GitHub. Please could you instead post this on the Power of Us Hub NPSP group here: https://powerofus.force.com/s/group/0F980000000CjReCAK/nonprofit-success-pack
Thank you,
Michael
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/SalesforceFoundation/NPSP/issues/5946#issuecomment-708542266, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAGGNJ4JZO77W2QZOFPL2RLSKXMLNANCNFSM4SQY6YLQ.


Potential history corruption through different processes/FileBackedHistory instances

As soon as the FileBackedHistory reaches it capacity, writes are not performed via appending, instead the history loaded into memory at the initialisation of the FileBackedHistory will be written with the new entries of the particular instance. If two processes or instances are alive at the same time the last one to drop will overwrite the previous additions.
https://github.com/nushell/reedline/blob/b242a030aac7f0176fce0e68c89c8ad6a3655ba1/src/history/file_backed.rs#L246-L254

seems like a shared rolling log type infrastructure would help. either that or have someone finish my db-backed-history - LOL.

That's a great suggestion if we want to keep a human greppable file! But yeah I was fantasizing about the ability to rank the history hints by usage frequency, so we may want to go the same route as IPython with sqlite

We'll definitely (eventually) have a sqlite backed history. I'm just not sure when. there are lots of things I want to do with it.

Could it be trait so that we can ship with a file or a db?

History is already a trait object. but the current setup would lead to some duplication when it comes down to navigation.


LCDColor & adding PlaydateEx module on main package

I'm proposing the enum ColorStyle to use LCDSolidColor or LCDPattern in the Graphics methods. For example:
let bitmap = Graphics.newBitmap(width: 100, height: 100, colorStyle: .solid(.colorBlack))
let newSprite = Sprite(bitmap: bitmap)

Also, using patterns:
let squares: LCDPattern = (
    0xF0, 0xF0, 0xF0, 0xF0, 0x0F, 0x0F, 0x0F, 0x0F,
    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
)
let bitmap = Graphics.newBitmap(width: 100, height: 100, colorStyle: .pattern(squares))
let newSprite = Sprite(bitmap: bitmap)

It also works on Graphics methods, like:
mySprite.withImage {
    Graphics.fillRect(x: x - 25, y: y - 25, width: 50, height: 50, colorStyle: .solid(.colorClear))
    Graphics.fillEllipse(
         x: x - 25, y: y - 25,
         width: 50, height: 50,
         startAngle: startAngle, endAngle: endAngle,
         colorStyle: .solid(.colorBlack))
}

Trying to minimize the impact of newer changes that Playdate module could bring to this package, I implemented a new module called PlaydateEx where I propose to add the extensions to the original module.
If you want to use the PlaydateEx module, add these lines to the Makefile file right after the include (line 4):
SWIFT_FLAGS_DEVICE += -module-alias PlaydateEx=playdateex_device
SWIFT_FLAGS_SIMULATOR += -module-alias PlaydateEx=playdateex_simulator

# MARK: - Build PlaydateEx Overlay Swift Module
build/Modules/playdateex_device.o: $(REPO_ROOT)/Sources/PlaydateEx/*.swift
	$(SWIFT_EXEC) $(SWIFT_FLAGS) $(SWIFT_FLAGS_DEVICE) -c $^ -emit-module -o $@

build/Modules/playdateex_simulator.o: $(REPO_ROOT)/Sources/PlaydateEx/*.swift
	$(SWIFT_EXEC) $(SWIFT_FLAGS) $(SWIFT_FLAGS_SIMULATOR) -c $^ -emit-module -o $@

And modify these lines:
build/game_device.o: Sources/*.swift | build/Modules/playdate_device.o

By:
build/game_device.o: Sources/*.swift | build/Modules/playdate_device.o build/Modules/playdateex_device.o

And:
build/game_simulator.o: Sources/*.swift | build/Modules/playdate_simulator.o build/Modules/playdateex_simulator.o

By:
build/game_simulator.o: Sources/*.swift | build/Modules/playdate_simulator.o

This looks interesting, what was the rationale behind this?

I'm assuming the original repo will have many changes, so I want to not infer and have new features in another module.
Related to the LCDColor, I just wanted to implement a parallax background, and this went to create a bitmap and deal with the OpaquePointer...


Removed option from minder history list.

Summary
Option --rule-name was meant to be used as filter on rule names, but we decided not to implement it for now as its usefulness is still under discussion.
Change Type
Mark the type of change your PR introduces:

[ ] Bug fix (resolves an issue without affecting existing features)
[ ] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[X] Refactoring or test improvements (no bug fixes or new functionality)

Testing
The option was unused.
Review Checklist:

[X] Reviewed my own code for quality and clarity.
[ ] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[ ] Included tests that validate the fix or feature.
[X] Checked that related changes are merged.

coverage: 54.311%. remained the same
when pulling 3b9a8b1addd0411eed5396916f4d1bd1fdec015e on fix/remove-unused-history-list-option
into fb8bd92f86e89f02416ed66a263e92b3b2f56c41 on main.


standardization

python convert_recordings.py --project=/path/to/data --name=16kHz --format=wav --sample=16k --split= etc.
creates a subfolder converted_recordings next to recordings/
converts all records to a given profile inside of this subfolder. A profile is the set of parameters that define the output codecs and format :

profile = {
  'sample': 16000,
  'split':'15:00:00',
  'format': 'wav',
  'codec': 'pcm_s16le',
  'extra_flags': ''
}

creates a profile.csv file at the root of the subfolder with every parameter defining the profile
creates a conversion_table.csv file at the root of the subfolder with two columns : original_filename as specified in the recordings table and converted_filename as created by the conversion script

TODO:

find out what pcm_s16le corresponds to

for splitting, this should work : https://unix.stackexchange.com/questions/1670/how-can-i-use-ffmpeg-to-split-mpeg-video-into-10-minute-chunks


Doesn't appear on lastest FORGE webui

Describe the bug
Doesn't appear on lastest FORGE webui
To Reproduce
Steps to reproduce the behavior:
start server i guess?
Expected behavior
idk

someone fixed it here
https://github.com/lllyasviel/stable-diffusion-webui-forge/issues/1358

Thanks, I pushed the changes


M4 :: CPU/GPU temperatures are wrong

Thanks for awesome utility!
On mac mini m4 I see strange CPU/GPU temperature. My first thougth was that temps are mixed: CPU <-> GPU (because GPU on heavy load but  only CPU temp is quite high). But 9.8C suspicious low for room environment (25C as usual).

macmon debug > mac-mini-m4-macmon.log

mac-mini-m4-macmon.log

Hi, @iDoka. Apple has changed the keys that hold the temperature values. As far as I understand, it is currently unknown which keys are responsible for what.
There's a thread here where community are trying to figure it out: https://github.com/exelban/stats/issues/2249
I'll leave issues open, maybe I'll find something.

Hi @vladkens
Thanks for your comment.
If you need to try something on the M4 HW env to fix temperature issue, just ping me in this issue.

I have a M2 Ultra Studio and I'm always getting 0 CPU power reading. Should I open another issue?

Hi, @i0ntempest. Yes, open please new issue and attach macmon debug output to it.

Hi @iDoka.
If you have a change, can you test this apps:

https://www.tunabellysoftware.com/tgpro/
https://crystalidea.com/macs-fan-control (https://github.com/crystalidea/macs-fan-control/issues/786).

They both reported that they support the new socket.

Also your terminal window looks small, so the GPU temp value may be clipped. Given that you have a GPU utilisation of 100%, the real displayed value is 79 or 89.
But it's still not clear to me if you have any GPU value at all. In the log you provided, no Tg values in the SMC list, so the temp value should be 0.
I have released version v0.5.1 with the full list of T keys. Can you please also attach new log file.

Hi @vladkens
thanks for update. I will do macmon debug > mac-mini-m4-macmon.log after updating macmon in brew. Now only v0.5.0 is available.
BTW, you are right - my window was not so wide enough and GPU temp was clipped (my bad!).

https://www.tunabellysoftware.com/tgpro/
https://crystalidea.com/macs-fan-control

Thanks for sharing links for alternatives,  to be honest:  my mac mini m4 has headless setup and I have only SSH connection to its, so macmon and asitop only suitable for this case.

v0.5.1:  /opt/homebrew/bin/macmon debug > mac-mini-m4-macmon.log
mac-mini-m4-macmon.log

A couple of interesting things:

GPU temp is gone (just disappeared).
RAM usage differs than reported asitop (not critical for me, but interesting)

UPD: v0.5.1 shows GPU temp seems correct (no temp shows for GPU when it in idle/stdby):

UPD: v0.5.1 shows GPU temp seems correct (no temp shows for GPU when it in idle/stdby):


Sprite images with linear gradients

I'm trying to use cm-chessboard with SVG images that use a linearGradient. This works fine using Firefox, but on all other browsers that I tried the gradients are not displayed. To illustrate the problem I have attached a modified version of chessboard-sprite-staunty.svg in which the white pawn has been replaced by a draughts piece with a gradient. And here is a link to how I'm using it in practice: https://10x10.org/analysis/2021/nk5-8a.html.
This probably isn't a bug in cm-chessboard, but I thought it might be worth mentioning it. I've googled for sprites and linear gradients, and found some hits that suggest browsers sometimes have trouble finding the definitions of linear gradients. If someone knows a solution for this problem that would be highly appreciated! Otherwise I will try to work around it by replacing the gradients with something else.
sprite.zip

You're free to close this issue of course, but you might want to add a note to the documentation stating that SVG images with linear gradients are unsupported.

This is cool, that you managed to change the number of fields and the figure set to a whole new game. Ist the modified code also available as Open Source?

Unfortunately it still doesn't work with the current version. Only Firefox renders the linear gradients correctly.
My changes are open source, see https://github.com/wiegerw/cm-draughtsboard. It would be great if some of this could be integrated into cm-chessboard. I've done the following steps:

Rename Chessboard and ChessboardView to Board and BoardView, and make them independent from chess (this is not entirely finished yet).

Add attributes rows and columns to the BoardView class, and use them where appropriate. This makes it possible to use boards of arbitrary dimensions.

Use indices instead of square coordinates in markers and the corresponding events. I've done this because the square coordinates are strings in chess notation, and I had to convert them back to indices everywhere.

What I haven't done yet is to make the field numbering work. I didn't see an easy way to make the existing code work for boards of arbitrary dimensions.

I can imagine that 1) and 3) are not practical, but it should be easy to integrate 2). If needed I can help with that. Besides that the construction of a Board may need to be adapted such that board states of different games can be used. Currently I have hard coded the usage of DraughtsboardState in the Board class.


Response with empty body

I try to simulate a HTTP's 204 response without body. Both
return OHHTTPStubsResponse(data: "".dataUsingEncoding(NSUTF8StringEncoding)!, statusCode: code, headers: nil)

and
return OHHTTPStubsResponse(data: NSData(), statusCode: code, headers: nil)

gives me null value as a response so I can't check for XCTAssertNilassertion. Is there another way?

Hello,
I have tested the same code you have posted and the OHHTTPStubsResponse instance created is not nil.  Can you show more code how you are doing it ?

It's not about creating nullable OHHTTPStubsResponse object, I guess you misunderstood me. I was talking about nullable response body within OHHTTPStubsResponse object.
The case is the following: I Alamofire to make requests, it's logics puts the response into NSData? instance, but if I use the examples I posted in original post, the value of that NSData is not nil, but length = 0. I am not sure if it's their issue or OHHTTPStubs's...
P.S.
I can handle it by additional checking if response.length > 0 anyway

Hello,
let data = NSData()
XCTAssertEqual(data.lenth, 0)

The data object is not nil but it contains no data :).
Just test if the length of the body is equal to 0, hope that i answered your question :).
(In OHHTTPStubsResponse i think that you can test with the dataSize property if it's equal to 0 or no).

It wasn't my question...
I'm just trying to understand: should I treat that behavior as a bug or not. Optional values were introduced exactly for these purposes and to me it looks like an issue - if data object contains no data it should be nil..

That's intended design in OHHTTPStubs to not make the NSData optional. That is to mimic the actual behavior and design of Apple's URL Loading System. And that's because it does not make sense to make a difference between "nil = no data" and "empty NSData".
So I'm not sure why Alamofire accept nil NSData in its design while an empty NSData conceptually means the same so the input domain is over-defined and two different input exist to represent the same case. If your server replies with a 204: No Content do you expect the NSData received to be nil or empty? Given both could match, keeping both possibilities (making it nullable) just makes cases confusing.
In fact that's also why Apple revised all their frameworks recently to annotate the Cocoa Framework and change some methods which previously returned nullable NSString, NSData or NSArray to now always return a non-nullable empty objects (empty NSString, empty NSArray, empty NSData, …) instead. Because both could represent the same but having to test both cases instead of just one every time you use the API was a PITA.

So I guess it's mostly Alamofire's issue/feature rather then OHHTTPStubs's...

Indeed.
I wouldn't say it's a bug in Alamofire, rather a different design choice. I prefer to be aligned with Apple and to avoid having multiple values representing the exact same case, but maybe Alamofire has its rationale for making it optional? Or maybe they didn't think it through yet, and asking them might trigger a debate and reflection about why they allow a nil NSData while an empty one already represent the same thing.

Just checked Alamofire's default serialization sources. They use SerializationResult<NSData, ErrorType> for every single serializer, so that's why final result is not nil but has a length of 0. I guess we can close the issue since it can be handled by additional check at client-side.


Make default commit message configurable

Currently the default commit message (for when the VSS check-in message is blank) seems to be hard-coded to "Vss2Git".
I prefer to not have "Vss2Git" but something else e.g. "-".
Thus requesting to make the default message configurable.
It is also possible to commit with an empty message in GIT.
The parameter for that is --allow-empty-message.
Then a default message won't even be needed.

The commit message now defaults to blank. It's not configurable from the UI, but blank seems to be what most people want.

@trevorr: If you want it I have a branch will allow setting defaults with UI.
Branch: SetDefaultCommentByUI
Commit: 02bdb7a6f8593c818d84e04336ab302764b4709b


jdk 17 code compilation for kork

jdk 17 code compilation for kork

The build seems to be failed due to unavailability of SNAPSHOT version of spinnaker-gradle-project on nexus internal repo. This has to be resolved to get a proper build. We will work and try to host customized version of spinnaker-gradle-project. Meanwhile merging this code for developer's usage assuming, no other build failure.


After removing last port fw the public nic on a VPC is removed which comes back non-functional

Scenario:

create VPC
create VM
create port forward to port 22
verify ssh works
remove the vm (or the port forward)
observe eth1 is now gone
create a new vm with a new port forward
device eth1 comes back
default gw / iptables rules are missing
both routers are in UNKNOWN state

run /opt/cloud/bin/master.py --master to force a master
run /etc/init.d/cloud-early-config start to trigger a reconfigure
...and it starts to work again.

Integration test written: See #98

The test above passes on KVM and fails on XenServer, so this issue is hypervisor specific.

Work-around: deploy your VPC on KVM.