Update (2020-11-03)
The issue described in the original post is resolved. I have no problems running Raku scripts with:
IntelliJ IDEA 2020.2.3
Comma Community release 2020.10.0
Original post
I program in Raku and I am trying to use Comma Community release 2020.07.0 with IntelliJ IDEA 2020.2 and 2020.2.1 (Community Edition) on Mac OS 10.15.6.
When I try to run a configured script I am getting the error "Error running 'Examples': com/sun/javafx/PlatformUtil" :
I did numerous searches on the web to find suggestions to fix this and nothing I tried worked. So, I reverted to using IntelliJ IDEA 2020.1.4 .
Any suggestions how to get Commaide working in IntelliJ IDEA 2020.2.1 ?
Unfortunately, there's probably not much to be done other than waiting for a newer Comma release.
Ideally, the Comma plugin would Just Work against newer versions of IntelliJ. While JetBrains mostly do a good job of retaining compatibility, or at least of deprecating things in one release and removing them in a later release so there's a chance to keep up, experience tells that if one is touching enough of the platform, there will often be something or other that gets broken by updates. Comma uses a significant amount of the IntelliJ platform API, and evidently something it depended on has changed in an incompatible way.
Related
I am new to UWP. I have just ported a quite complicated WPF app. It took me several weeks to figure out every difference and refactored a lot of code. However when I start to build and run in release mode I get an Access violation exception.
How is this even possible? Aren't debug and release execution supposed to be the same? How can I debug this problem if it occurs only in release?
If I turn native compilation off, the release build runs without a problem. However, when I try to install it on the device, a NetCore 2.2 debug framework is required. What is this debug framework and why cannot I run my release code without it?
I used to develop for AspNetCore and those things can run even on Linux. I really do not understand how is a UWP app cannot run on a Windows 10 tablet without a special debug framework.
I am kind of lost here. Any help or guidance is much appreciated. Thanks
EDIT:
As for the conclusion: I needed to create the app again from scratch. I started copying everything from the old app class by class. It was worth the effort not just because I refactored a lot of code :) but finally found what was causing the crash. I had a dependency in one of my libraries to an older version of System.ServiceModel.Primitives NuGet package. In Debug build, even with Native Compilation, the runtime managed to resolve the package. However, in Release it could not.
It was quite a journey that made me to develop a better software. However I could avoid it by releasing more often from the beginning, or the if the runtime would show more informative error messages about assembly resolution problems.
The .NET Native compilation tends to cause problems for apps and it is recommended to try and run the application frequently in the release mode to catch potential issues as soon as possible. Usually any reflection-related code should be checked well, as those usually are the source of problems.
I would suggest going back in time (if you have some kind of source control) and try earlier builds of your app to pinpoint the time when the app stopped working. Alternatively, you can try commenting out parts of the code until the release build starts working. Finally, it is also possible to create a blank project and sequentially copy code and run it to locate the problem.
.NET Native is an annoying aspect of UWP app development and Microsoft is aware of this - the plan is .NET Native will no longer be required anymore soon (most likely before .NET 5 comes) and later there will be a more predictable replacement.
I am currently tasked with porting an code library over to .NetCore. Fundamentally, this is going fairly smoothly but there is one thing that is causing me concern and that is retaining platform independence.
Core is designed to run on Mac and Linux so I want to ensure that the library will also run on Mac and Linux when I'm done. However, in order to get things working I find myself including a lot of non Microsoft.AspNetCore.* nuget packages. (e.g. System.Diagnostics.Process, System.Net.Http, System.Threading.Thread, etc)
Clearly this won't be a problem on Windows but I do wonder if it would cause problems if say, someone targeting Linux was to include a reference to my library?
If it's not a problem then great but if it is then how do I know which nuget packages will be okay in a multi-platform library? (e.g. Is it only the AspNetCore ones that will work cross-platform?)
The System.* packages are (usually) from https://github.com/dotnet/corefx, and the 99.5% use cases are going to work on macOS and (supported) Linux (distributions) the same as they do on Windows.
There are cases where the System.* packages don't work the way you'd expect them to. Mainly this comes from times that .NET was adding convenience APIs to wrap Windows behavior. So reading a registry key, for example, won't work (and even in a future where the registry API works, it certainly won't be backed by a legitimate hive, so reading obscure values will report key not found). Mostly when an API isn't going to work on Linux/macOS it'll throw a PlatformNotSupportedException, instead of producing some sort of unexpected/wrong result.
So, as long as what you're doing doesn't feel specifically "Windows-y", everything from a netstandard* or netcoreapp* RID should Just Work. And if it doesn't, you can always file an issue at the corefx github project.
I'm developing a SQLite-heavy Windows Phone 8 application and tried to use the latest version, which however seems extremely buggy and randomly fails during INSERT and UPDATE statements with zero-explanation errors (see SQLite 3.8.2 exception on Update statement). For that reason I removed the latest version from the project and entered the one that works correctly.
I published the app to Windows Phone Store after rigorous testing, everything working correctly. However, when it came out, the errors that happened when the newer version was there are happening again. I tested the exact same Release build XAP on my device (via the Deploy tool), and it works perfectly. But after I download the app from Store, once again I get the same issues.
Has someone a way to explain these problems? I repeat, that the exact same XAP that I uploaded I tested and it is working.
EDIT: Additional note - the problems are really random - the same INSERT once works and doesn't another time, although data are valid...
Thank you very much, I'm quite desperate...
The new version of SQLite (3.8.3.1) that was released on 11th April 2014 should resolve any issues, finally :-) . So far I have not encountered the same error again so I suppose it is now fixed.
http://www.sqlite.org/releaselog/3_8_3_1.html
I'm trying to get XCode 4 to symbolicate a crash report. I've googled and followed this link (https://github.com/chrispix/symbolicatecrash-fix) but get stopped. The instructions say "To fix your iOS crash report symbolication, move /usr/local/bin/symbolicatecrash aside and copy in the version in this repo." Well, I cannot find "/usr/local/bin/" on my Mac. I'm new to the Mac world, so I'm sure there's something I'm not understanding. If "/usr/local/bin/" doesn't exist, then where is XCode 4 finding symbolicatecrash? Please point a newbie in the right direction as I have a lot of bugs to be fixing.
Thanks
Tom
that tool has been relocated to /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash in newer version of the SDK
you would run it as:
./symbolicatecrash -A -v [crashlog-filename] MyApp.dSYM
keep in mind this is for iOS only, for OSX see http://developer.apple.com/tools/xcode/symbolizingcrashdumps.html (for the app to contain the symbols "DWARF with dSYM" must be enabled in it's build settings)
you would run it as:
./symbolizecrashlog [application-name] [crashlog-filename] > symbolized.crash
I would like to add that all this usually is done automatically, these manual approaches are for cases when there are issues with the system symbols database as discussed in Xcode 4 failure to symbolicate Crash Log
Has anyone ever bothered about the fact that BizTalk has a lot of annoying deployment/building problems.
For example if I use c# assembly classes to be build/deployed I regularly get sgen.exe errors, which get fixed if I remove them from my assembly, however then some dependencies are giving problems again, which then means I have to rebuild it and restart visual studio because they don't trigger the assemblies otherwise. And yes I always use the build event command:
"C:\Program Files\Microsoft Visual
Studio 8\SDK\v2.0\Bin\gacutil.exe" /i
$(TargetFileName)
I also experience a lot of problems wwith serializing String or Booleans etc while building, which also become fixed after I restart my visual studio solution.
Also when you want to import an .msi file you have to unenlist & remove all running instances to have it deployed decently.
And let's not forget about restarting your host instances, which is an option on your visual studio project but barely ever works so manually restarting your host instances has become more than a routine.
Let's face it, there's a lot of other things which also keep on rising like references problems etc, and I'm sure I can think of a couple more after a day of work.
Does anyone have some tricks regarding these issues? Because I encounter them hourly. I was just wondering if other people encountered these too and maybe solved a couple of these issues.
About restarting host instances, I have found the following "bts-reset" PowerShell script to be extremely useful:
http://winterdom.com/2006/09/btsresetwithpowershell
It doesn't solve the problem, but it's faster to use than restarting host instances from the BizTalk admin console.
Otherwise, I agree with you that deployment is really too complex (especially when you have multiple projects/applications with dependencies between them), but the only "solution" I have is to carefully break down your projects/applications in a way that will minimize the problem.
We installed SP1 for BizTalk yesterday. The performance has improved a lot! Starting our orchestrations used to take ages. Only takes a couple of seconds now!