How can I fix that:
Command:
$ ceylon format source/com/example/helloworld/*
Exception:
Exception in thread "main" java.lang.NoSuchMethodError: ceylon.language.runtime_.getMaxArraySize()Lceylon/language/Integer;
at ceylon.collection.Hashtable.<init>(Hashtable.ceylon:35)
at ceylon.collection.Hashtable.<init>(Hashtable.ceylon)
at ceylon.collection.HashMap.$default$hashtable(HashMap.ceylon:31)
at ceylon.formatter.options.Spaces$cache_.<init>(IndentMode.ceylon:62)
at ceylon.formatter.options.Spaces$cache_.<init>(IndentMode.ceylon)
at ceylon.formatter.options.Spaces.<init>(IndentMode.ceylon:59)
at ceylon.formatter.options.FormattingOptions.$default$indentMode(FormattingOptions_generated.ceylon:355)
at ceylon.formatter.options.FormattingOptions.<init>(FormattingOptions_generated.ceylon)
at ceylon.formatter.options.loadProfile_.loadProfile(profiles.ceylon:79)
at ceylon.formatter.options.loadProfile_.loadProfile(profiles.ceylon)
at ceylon.formatter.options.commandLineOptions_.commandLineOptions(formattingOptions.ceylon:125)
at ceylon.formatter.options.commandLineOptions_.commandLineOptions(formattingOptions.ceylon)
at ceylon.formatter.run_.run(run.ceylon:285)
...
I think I have to re-install the formatter. But which version?
For no reason the following command works:
ceylon run ceylon.formatter source/com/example/helloworld/*.ceylon
Where is the difference and how can I fix it.
ceylon.language.runtime used to be implemented in hand-written Java code. In this code, getMaxArraySize() accidentally returned ceylon.language.Integer when it should have returned long. This worked, but wasn’t quite correct.
Then, with native support in Ceylon 1.2, runtime (along with some other objects) were rewritten as native Ceylon code. Since this is converted to Java by the Ceylon compiler, the method now gets the correct return type, long. Newly compiled modules will now call this method, but code that was compiled against an old ceylon.language will still try to call a method returning ceylon.language.Integer, which leads to your NoSuchMethodError.
What’s happening here, it seems, is that ceylon format runs ceylon.formatter/1.1.0, which was compiled against ceylon.language/1.1.0, and now can’t run with ceylon.language/1.2.0. ceylon run ceylon.formatter probably runs ceylon.formatter/1.2.0 for some reason, which works.
I’m not sure what you need to do to fix this. I changed the way the ceylon format plugin works recently, so you probably need to delete the old ceylon format script (a ceylon-format or ceylon-format.bat file somewhere in .ceylon/bin, I believe). Hopefully the new one is already there, ready to take over.
Try ceylon plugin uninstall format and see if that fixes things.
A second option would be to say ceylon plugin install ceylon.formatter/1.2.0
The reason why ceylon format doesn't work but ceylon run does is because your installed ceylon format will look for the hard-coded version 1.1 which isn't compatible anymore while ceylon run will look for any version that's compatible with the current Ceylon version you're using. (So it will find both 1.1.0 and 1.2.0 but it will discard 1.1.0 because it isn't compatible and therefore choose 1.2.0 automatically)
Related
i recently updated huge project from Scala 2.12 to 2.13 and switched form using
https://github.com/shogowada/scala-json-rpc
to:
https://github.com/nawforce/scala-json-rpc
And few methods - jsonRPCServer.{bindApi, receive} and jsonRPCClient.createAPI - started giving me this error:
value pretty is not a member of io.circe.Printer
It didn't appear in the former version of the library. I tried to examine the sources, but failed to find the problematic calls.
Do, by any chance, any of you had similiar problem?
Looking at Scaladex and looking at the circe dependency for both packages (Scaledex for the original, Scaladex for the fork you are using), it has been upgraded from 0.8.0 to 0.13.0. Looking at this commit it looks like pretty has been deprecated in 0.12.0 (and judging from your post, probably dropped in 0.13.0) and replaced by printWith, which is likely what you want to use.
I’m having a problem with printing figures in octave when the figure’s visibility is set to false. For example, the following code produces a “panic: segmentation fault” in Octave version 4.2.2:
t = 1:10;
fh = figure(“visible”, false);
plot(t,sin(t))
print(“fig.png”)
If I run the above code in Octave version 5.2.0, there is no problem. Is this a bug that was fixed in the Octave 5 update? If so, is there a workaround that I can use for Octave 4? I would prefer to use Octave 4 if possible.
Other notes:
I am running this in Ubuntu 16.04.6 LTS and I installed octave 4 using apt.
The answer to your question is, yes. Here is the relevant line from the v5.1.0 NEWS:
Dependencies:
The GUI requires Qt libraries. The minimum Qt4 version supported is Qt4.8. Qt5 of any version is preferred.
The OSMesa library is no longer used. To print invisible figures when using OpenGL graphics, the Qt QOFFSCREENSURFACE feature must be available and you must use the qt graphics toolkit.
Apparently the now deprecated OSMESA dependency and the printing of invisible figures was a long-standing pain-in-the-butt. Maybe you'll have some luck going through bug comments (e.g. someone says that if you make it visible at least once, it may be possible to print).
But as people have said in the comments, the best thing to do would be to upgrade your octave version, and recompile your mexfiles for the new version.
I have a Cython extension which I've compiled on Ubuntu 14 and uploaded as an Anaconda package. I'm trying to install the package on another machine which is running Scientific Linux (6?) which ships with an older version of glibc. When I try to import the module I get an error that looks (something like) this:
./myprogram: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./myprogram)
When I say "something like" - the "myprogram" is actually the .so name of the extension.
From what I understand this error is because I have a newer version of glibc on the build system which has an updated version of the memcpy function.
This page has a good description of the problem, and some rather impractical solutions: http://www.lightofdawn.org/wiki/wiki.cgi/NewAppsOnOldGlibc
There is also a much simpler answer proposed here: How can I link to a specific glibc version?
My question is: how to I apply this solution to my Cython extension? Assuming the __asm__ solution works (as given in the second link) what's the best way to get it into the C generated by Cython?
Also, more generally, how to other modules avoid this issue in the first place? For example, I installed and ran a pre-built copy of numpy without any issues.
This turned out to be quite simple.
Create the following header, glibc_fix.h:
__asm__(".symver memcpy,memcpy#GLIBC_2.2.5")
Then include it by using CFLAGS="-include glibc_fix.h". This can be set as an environment variable, or defined in setup.py.
Additionally, it turns out numpy doesn't do anything special in this regard. if I compile it myself it links with the newer version on my system.
I am using Delphi XE6 and using Datasnap and JSON in my project. There is a bug I want to correct in the VCL unit System.JSON.pas (in the TJSONString.ToString function) where it should be escaping backslash characters as well as quotes. In order to fix this I carried out the following :
Copied System.JSON.pas from the standard VCL source folder to my project source folder
Added System.JSON.pas to my project (using the newly copied file)
Fixed the bug and attempted to compile
I get the error 'Unit Data.DBXCommon was compiled with a different version of System.JSON.TJSONObject'
I can see that the Data.DBXCommon unit references System.JSON, so I guess the compiler is now seeing 2 versions - my fixed version and the standard VCL version.
What is the correct way to implement VCL changes to avoid this problem?
There are two common reasons for this issue:
You made changes to the interface section of the unit. You cannot do this without also re-compiling all units that use the unit you are modifying.
You re-compile the unit with different compiler options from those used to build it originally. Deal with that by ensuring the compiler options used to compile the unit you modify are the same as used by Embarcadero. Typically Embarcadero compiles with default options. Impose these directly in the source file being modified, right at the very top of the file.
Having said this, a recent question here on a similar topic could not be resolved using option 2 above. In that question, under XE6 only, the unmodified Classes unit could not be re-compiled and linked at all. Which makes me wonder if this particular technique has had its day. Perhaps it's not even possible. Before you give up, see if you can compile and link the unmodified unit.
More broadly, using a detour is generally an easier way to solve such problems as you face. Using a detour rather than re-compiling makes the management of the fix cleaner and simpler.
Update 1
I cannot get the unmodified System.JSON unit to re-compile and link. Which I think means that the issue raised in that other question is broader than just the Classes unit. I think you will find this a tricky hurdle to overcome and recommend the use of a detour.
Update 2
The problem that appears to have been introduced in XE6, seems to have been resolved by the release of XE7. The unmodified System.JSON unit will compile and link in XE7.
What if Delphi XE6 original System.JSON.dcu wasn't compiled with Delphi XE6 but it was compiled with one of the previous versions of Delphi.
You claim that you managed to implement your fix in Delphi XE2 using same approach by changing source and then recompiling System.JSON. SO I suggest you first make a comparison between original System.JSON files that ship with both Delphi XE2 and Delphi XE6.
If they are the same then the changed System.JSON.dcu that you managed to recompile with Delphi XE2 might also work with Delphi XE6.
I resolved a similar issue by :
Deleting the .dcu files which are on different versions ( i.e. conflicting files).
Re-build the project to create new .dcu files.
After quite a bit of searching and trying different things, I am stumped on how to get mym to work (as found here: http://sourceforge.net/projects/mym/). I was wondering if anyone has a very simple list of actions needed to get this to work. I think my main trouble is installing zlib. I don't understand how to actually install it or work with it. I have tried to use Microsoft Visual C++ Express 2010 but then only the debug versions are compiled. That means when I try to use the mex function in matlab it gives me the error:
Error: Could not detect a compiler on local system
which can compile the specified input file(s)
I just don't understand the process and everywhere I look it says something different. I have tried multiple versions of each all of the programs involved and nothing seems to work. Any help would be greatly appreciated.
Do:
mex -setup
from the command line to define your compiler on your system. Once you do that then Matlab will correctly locate the compiler and build the mex libraries it needs.
See:
http://www.mathworks.com/help/matlab/matlab_external/building-mex-files.html