Getting java.lang.NoSuchMethodException: javafx.application.Platform.startup(java.lang.Runnable) - javafx

I have a tornadofx app that I've moved from an earlier version of Kotlin and Kotlin Coroutines to the latest (1.3 and 1.0.1) When I run it I get the above exception on this line
button("Click to calculate") {
}.setOnAction {
GlobalScope.launch(Dispatchers.UI) { }
}
It's the call to 'launch' that causes the exception. This all worked in the release I was running on previously.
Any help would be appreciated

This is a known bug. Either wait for 1.0.2 where it is hopefully fixed or downgrade to 1.0.0 at the moment where it still works. I did the latter and it suffices to update all the other stuff that needs to be updated (coroutines, etc.), in case you are coming from a pre-1.3-version.

Related

How do I fix the error: Cannot find module '__sveltekit/paths' in sveltekit when migrating to 1.7.2?

I was migrating to sveltekit 1.7.2 from 1.5.3, as there was a security vulnerability. NPM did not tell me that 1.7.2 was a breaking change, so I installed the new version. I found that the latest compatible version was 1.5.6, anything higher resulted in the same error. I don't know why this is an issue, I guess it wouldn't be if you were making a new project, but as I am not doing that, can anyone tell me how to fix this?
Entire error:
Error: Cannot find module '__sveltekit/paths' imported from [path to project]/node_modules/#sveltejs/kit/src/runtime/server/respond.js'
at nodeImport (file:///[path to project]/vite/dist/node/chunks/dep-3007b26d.js:52431:25)
at ssrImport (file:///[path to project]/node_modules/vite/dist/node/chunks/dep-3007b26d.js:52354:20)
at eval (/node_modules/#sveltejs/kit/src/runtime/server/respond.js:5:37)
at async instantiateModule (file://path to project]/node_modules/vite/dist/node/chunks/dep-3007b26d.js:52400:9)
This error tells me that the file "__sveltekit/paths" has either moved, been replaced, or deleted entirely. Does anyone know where the file is now/if it even still exists?
Please note, that I see this error in the browser and in the node console. No other content is rendered at all.

Upgrading Doctrine Migrations

I am getting this warning on my codebase, here's my composer
Package zendframework/zend-eventmanager is abandoned, you should avoid using it. Use laminas/laminas-eventmanager instead.
So I needed to upgrade Doctrine Migrations bundle, but I can't seem to upgrade it, and I can't find an upgrade log.
First I get errors about Doctrine\DBAL\Migrations\AbstractMigration, so I replaced them all to Doctrine\Migrations\AbstractMigration. Now I'm getting
Compile Error: Declaration of Application\Migrations\Version20170927104049::up(Doctrine\DBAL\Schema\Schema $schema) must be compatible with Doctrine\Migrations\AbstractMigration::up(Doctrine\DB
AL\Schema\Schema $schema): void
I asked for a CHANGELOG https://github.com/doctrine/DoctrineMigrationsBundle/issues/296
But anyhelp would be greatly appreciated
The error tells you your function is not compatible with the abstract function, did you forget to add the return type to your function?
make it:
public function up(Schema $schema) : void
{}
You should start by upgrading your packages through composer upgrade - for example, in your composer.lock, you are using ocramius/proxy-manager in a version of that bundle that is nearly three years old, and this requires the abandoned package. The name change from zendframework/zend-eventmanager to laminas/laminas-eventmanager has happened in 2019.
A next step might be to upgrade the constraints such that you require even newer packages. For example, there are much more recent versions of doctrine/doctrine-migrations-bundle or symfony/swiftmailer-bundle, and updating them from time to time helps to avoid problems. As the gap between the installed version and a more recent version gets larger and larger, the upgrading process gets more complex too.
On the other hand: if your code is still working properly, you can simply ignore that warning. It tells you that the given package will not receive any updates after all, but that does not mean you are in danger immediately

Codeception\Test\Test::run(?\Framework\TestResult $result = NULL) must be compatible with

PHP v7.2.3
PHP Unit 8.2.3
Codeception 3.0.2
When I try to run tests I get the following error:
Declaration of
Codeception\Test\Test::run(?PHPUnit\Framework\TestResult $result =
NULL) must be compatible with
PHPUnit\Framework\Test::run(?PHPUnit\Framework\TestResult $result =
NULL): PHPUnit\Framework\TestResult in
/var/com/vendor/codeception/codeception/src/Codeception/Test/Test.php
on line 18
When I look at the definition of PHPUnit\Framework\Test::run I see it specifies a return type but Codeception\Test\Test::run does not and this would appear to be the problem.
I've checked back through the version history of both of these files in the respective git repos and it seem these files have been this way for many versions.
After much searching it doesn't seem anyone else has posted the issue which makes me think I'm missing some key insight.
Any light shed on this issue would be much appreciated, thanks!
In the end a fresh install of Symfony latest version and Codeception presented a working solution.
Since this was initially a port from another symfony 3 application (with an older version of codeception) it's likely that there was a misconfig or incompatible package.
The other possible cause which occurred to me later is that the cli for codeception in previous versions of symfony was run from a general bin directory 'bin/codecept' and now we run directly from 'vendor/bin/codecept' its possible that my CI script was referencing an outdated cli.

About ROS_RMPT_SLAM package compiling issue

While doing catkin_make ROS_MRPT_SLAM, I got following error
In file included from /usr/include/mrpt/base/include/mrpt/utils/CFileGZInputStream.h:12:0,
from /home/ian/catkin_ws/src/mrpt_slam/mrpt_ekf_slam_2d/include/mrpt_ekf_slam_2d/mrpt_ekf_slam_2d.h:11,
from /home/ian/catkin_ws/src/mrpt_slam/mrpt_ekf_slam_2d/src/mrpt_ekf_slam_2d.cpp:7:
/usr/include/mrpt/base/include/mrpt/utils/CStream.h: In member function ‘void mrpt::utils::CStream::WriteVariant(T)’:
/usr/include/mrpt/base/include/mrpt/utils/CStream.h:313:15: error: use of ‘auto’ in lambda parameter declaration only available with -std=c++14 or -std=gnu++14
t.match([&](auto& o) { this->WriteObject(o); });
^
/usr/include/mrpt/base/include/mrpt/utils/CStream.h: In lambda function:
/usr/include/mrpt/base/include/mrpt/utils/CStream.h:313:45: error: no matching function for call to ‘mrpt::utils::CStream::WriteObject(int&)’
t.match([&](auto& o) { this->WriteObject(o); });
I guess it's compatibility matter or something because there were missing header files and so on.
This is the ROS_PACKAGE wiki: http://wiki.ros.org/mrpt_slam
And I just followed instruction from official MRPT website.
If the developer or anyone who is familiar with mrpt toolkit sees this question, may I get some advice about these errors?
By the way, I installed mrpt toolkit using the following website's instruction: http://www.mrpt.org/MRPT_in_GNU/Linux_repositories.
I'm the main author of MRPT and of part of the ROS packages.
Sorry for the mess, but you found us in the transition between the mrpt series 1.5.* and a new mayor rewrite based on C++14 which currently is published in git as mrpt 1.9.9 and eventually will be released as 2.0.0.
This transition must be propagated to the ros nodes, but so far we have upgraded mrpt_navigation only, mrpt_slam is in the to-do list.
So: a solution is to install an mrpt version of the 1.5.* series, and to build the ros packages from sources, paying attention to checking out the branches named compat-mrpt-1.5.
Hope this helps!

Meteor meta:susy package surprising path

I'm trying to use the meta:susy package on my meteor installation. On my iMac there are no problems, but on windows 10 it say:
throw Error("surprising path" + p);
Error: surprising path: /{meta:susy}/susy
I removed the fourseven:scss package, then I added it and the susy:meta package again, but the problem persists.
How can I solve it? I need to use it in my laptop too..
Thank you all!
That's a known issue in 1.3, so use 1.3.1:
meteor update --release=1.3.1

Resources