I would like to use the old codegen capabilities (before Xcode 8) for core data: Therefor I am setting the Tools Versions at the File Inspector to Xcode 7.3 but no success. Using "Editor -> CreateNSManagedObject Subclass" still generates files Recipe+CoreDataClass.h/m and Recipe+CoreDataProperties.h/m in my example and not as expected Recipe.h/m
It makes no different if I am choosing "Class Definition" or "Category/Extension" at Class -> Codegen at the Data Model inspector.
To use the manual triggered NSManagedObjectsubclass code generation like used to in older Xcode versions (<= Xcode7), set Codegen to none.
You can find details in this answer.
Related
I stumbled into an issue where all my unit test classes fail to run, providing the following error:
java.lang.IllegalStateException: Failed to transform class with name <my class name>. Reason: toPrettyPrint (Ljava/lang/String;)Ljava/lang/String; in <my class name>: inconsistent stack height -1
One user commented on the following github thread for powermock, that the same error first happened to them after updating their kotlin plugin:
https://github.com/powermock/powermock/issues/779
After reading this, I have checked with my colleagues to see maybe they have a different kotlin version, and saw that their kotlin plugin version is
203.1.6.0-release-798-AS7717.8, whereas mine is 1.4.32-release-Studio4.1-1.
What I find peculiar abbout this, is that these versions dont follow the same conventions, they look more like two completely different sofware. Is there any way for me to get the same version for my kotlin plugin ?
Any help or clarification is much appreciated, thanks!
They probably just changed the naming scheme for the plugin. Looks like you have one that is about one and a half years out of date.
Anyway, go to File -> Settings -> Languages & Frameworks -> Kotlin and click the Install button.
In IntelliJ-based IDEs like Android Studio, in Java source codes, there is an option to extract things as constants when possible (final static). It is in Refactor -> Extract -> Constant and is accessible via Ctrl+Alt+C.
But I can't find it for Kotlin source codes!
Note 1: I can do it manually as you can see about NUMBER in the above screenshot (by defining it as a const val in companion object).
Note 2: The reverse-action is accomplishable by IDE; it means you can inline NUMBER with Ctrl+Alt+N.
Unfortunately, this is a known missing feature for now. It's being tracked on the official issue tracker. You can vote for it there =)
RedHawk installs JARs for eclipse plugins from redhawk-yum-1.10.2-5-el6-x86_64.tar.gz. In RedHawk 1.9 it only installed 4 JARs for IDL parsing and editing, but in RedHawk 1.10 it installs these 4 but also 2 from Eclipse Corba Package.
gov.redhawk.eclipsecorba.idl_7.1.0.201501292343.jar
gov.redhawk.eclipsecorba.idl.source_7.1.0.201501292343.jar
gov.redhawk.eclipsecorba.idl.edit_4.1.0.201501292343.jar
gov.redhawk.eclipsecorba.idl.edit.source_4.1.0.201501292343.jar
net.sf.eclipsecorba.idl_0.7.0.218.jar
net.sf.eclipsecorba.idl.edit_0.7.0.218.jar
Many java files have the same names but there are also many differences.
From comments in the source java files it appears that the gov jars used JavaCC to build the parser while those from ECP used SableCC.
Which ones are actually used in RedHawk 1.10 or are they both used for different purposes?
I am trying to look into a parser bug and would like to know which parser to look at.
Sorry, I am not familiar with Eclipse plugin development and have not figured out how to tell what plugins are actually loaded or how they are used.
Redhawk uses the Eclipse Corba Plugin (ECP) project to provide an editor for IDL files:
http://eclipsecorba.sourceforge.net/
The editor does not support constant IDL expresions (e.g. const foo = bar + 1). Unfortunately, the project is not maintained any more (last release in 2008).
For all other IDL functions in the IDE, such as displaying IDLs under the "Target SDR" in the explorer view, the Redhawk IDE has its own parser code which handles this. The IDE's parser currently has the same limitation - it does not recognize constant IDL expressions.
RedHawk uses three distinct IDL parsers. 1) omnicpp (omniorbs version of idl2cpp) uses its own parser. 2) the code that builds a tree for the IDL Repository in Target SDR uses a plugin in gov.redhawk.eclipsecorba.idl.* which has a parser based on JavaCC compiler-compiler. 3) the IDL editor that was introduced in RedHawk 1.9 uses a different plugin in net.sf.eclipsecorba.idl.* which as a parser based on SableCC, a different compiler-compiler.
I am trying to develop a simple project in Pharo, and I would like to add its dependencies in Metacello. My project depends on Glamour, Roassal and XMLSupport.
A way to cleanly install my project is to install the dependencies by hand first. Following the book Deep into Pharo one can do
Gofer new
smalltalkhubUser: 'Moose' project: 'Glamour';
package: 'ConfigurationOfGlamour';
load.
(Smalltalk at: #ConfigurationOfGlamour) perform: #loadDefault.
Gofer new smalltalkhubUser: 'ObjectProfile'
project: 'Roassal';
package: 'ConfigurationOfRoassal';
load.
(Smalltalk at: #ConfigurationOfRoassal) load.
Gofer new
squeaksource: 'XMLSupport';
package: 'ConfigurationOfXMLSupport';
load.
(Smalltalk at: #ConfigurationOfXMLSupport) perform: #loadDefault.
and then my project will work fine.
I have tried to create a ConfigurationOfMyProject using the Versionner, and I have added Glamour, Roassal and XMLSupport as dependencies, using the version that are currently installed in my image (2.6-snapshot, 1.430 and 1.2.1 respectively).
The problem is that I am not able to load my project using Metacello in a fresh image. The project loads fine, but whenever I try to load my classes I get method missing errors in Glamour. Moreover, it is apparent that something is different, because even the world menu has different entries.
I have tried other combinations of versions, including using the stable Glamour (2.1) but I have obtained more errors, including not even being able to open the project in the Versioner (it complains about a missing Roassal name).
What is the correct way to add these dependencies cleanly?
First of all I want to highlight that if configuration is in class ConfigurationOf<proj-name> you can load it as using #configuration message:
Gofer new
smalltalkhubUser: 'Moose' project: 'Glamour';
configuration;
load.
(Smalltalk at: #ConfigurationOfGlamour) perform: #loadDefault.
A I don't see your project, I can just suggest you to write configuration by hand. There is an easy tutorial called Dead simple intro to Metacello.
According to your description it should be something like:
baseline01: spec
<version: '0.1'>
spec for: #common do: [
spec blessing: #release.
spec repository: 'your repo url'.
spec
package: 'YourPackage' with: [
spec requires: #('Glamour' 'Roassal' 'XMLSupport') ].
"also maybe you have a couple of packages that depend on different projects"
spec project: 'Glamour' with: [
spec
className: 'ConfigurationOf Glamour';
repository: 'http://smalltalkhub.com/mc/Moose/Glamour/main';
version: #'2.6-snapshot' ].
spec project: 'Roassal' with: [
spec
className: 'ConfigurationOfRoassal';
repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal/main';
version: #'1.430' ].
"and same for XMLSupport" ].
Also you can try to load #development versions, as I have an impression that projects like Roassal and Glamour have very outdated stable versions. Also please note that Roassal2 is actively developed and will replace original Roassal in Moose platform, maybe you want to consider using it.
I would seriously discourage writing configs by hand - that is the assembly code of Metacello ;) Unless you are working on cross-Smalltalk-platform projects with platform-specific code (e.g. code for Pharo 1.4 vs Squeak 4.5) - an area which hasn't been explored yet, Versionner is the tool for you. I have written dozens of configs with it and have yet to run into a roadblock.
When you say you added them as dependencies, did you just add them as projects in the "Dependent projects" pane?
If so, you also have to specify which of your project's packages depend on them. To do this, you select the relevant package of your project on the "Packages" pane.
Now, click on the edit button with the pencil icon that just became enabled. In the dialog that appears, click the green + button and add the external projects of interest.
It looks like you are trying this in an old version of Pharo?
Roassal has been superseded by Roassal2, and the support for XML is on smalltalkhub, split into ConfigurationOfXMLWriter and ConfigurationOfXMLParser, both in PharoExtras.
If you load the right groups from Glamour you don't need to describe the dependencies on Roassal, as Glamour already depends on Roassal(2). That explains your cyclic dependency.
You have also run into the problem we've recently talk about on the pharo mailing lists
that #stable is not a usable symbolic version name. In the Seaside/Magritte/Grease projects we've changed to using #'release3.1' style symbolic version names. That ensures that there is less of a ripple effect when progressing stable.
Snapshot versions should never be a dependency, they just describe what is loaded at the moment, and are basically not upgradable.
[edit]
Metacello by default tries to be smart about not installing older versions over newer. This works pretty well as long as things are not moved to different packages. So it's a bit of bad luck there that you ended up with a non-working combination.
Metacello support complex workflows, and different smalltalk projects (need to) use different workflows. It often takes some time to reach consensus on the best way to do things.
Roassal does not depend on Glamour, but you can create the cycle in your own configuration :)
Packages were moved from squeaksource to ss3 and smalltalkhub because the server had had stability problems. More recently, those problems seem to have been fixed. The xml support was split as it was noted that a lot of applications actually don't need both writing and reading of xml.
Once you have a working configuration, it might be a good idea to build and test it on the continuous integration server of pharo: http://ci.inria.fr/pharo-contribution
If not your actually application, at least the open source parts as used by you. That way the Pharo, Glamour & Roassal teams can know if a change they make breaks something.
I have IntelliJ 12 and some groovy code (along with a pile of java code) in a project.
In intelliJ, i can see class A's import of some groovy code, and i have also included the library that has that code.
However, while the package itself is in one colour (for the import), the actual class being imported is in red, which implies an issue of some sort. Hovering the mouse over it reveals no issue though.
When i run a "make" or a "rebuild project" is where the problems start - i get
Groovyc: unable to resolve class com.blah.blah.blah.A
How can i resolve this?
Currently, my project setup is like so:
Under "Libraries" in (Project Structure -> Project Settings -> Libraries) I have:
the jar file with all the groovy code
the src jar file with all the groovy code
In the "Modules" section i have the - well, i don't know what to call it, the column isn't labelled - the library name from the libraries section associated with the src and class files, and the little "export" button beside it is ticked.
Incidentally, opening the class in intelliJ never shows the source code, which given the source is included struck me as weird.
Is there anything else I should need to do?
I've worked this one out, but if anybody knows why groovy cannot be in the "Resource Patterns" list and wants an upvote, do chime in
Oh, right.
I removed the !?*.groovy entry from the list of, um, entries in the File : Settings -> Compiler -> Resource Patterns thingy.
It doesn't seem to matter if "use external build" is on or off for this, but the !?*.groovy; entry cannot be there.
I wonder if anybody knows why?
I had the same problem and had to Add Framework Support and add Groovy to the project to get round this problem.
I created the project using gradle.
I just got your question in my Google results as I had a similar issue. My problem was that I was able to get the groovy code in my IntelliJ 12 project to compile ok, but it wasn't getting wired in properly when I tried to run unit tests within the IDE.
After some investigation, I uncovered that groovy and logback libraries were all set up in the project to be available in the runtime stage of the Maven build of the project, but that resulted in them not being available in the test stage. To fix this, I ended up manually updating the groovy-all and the logback libraries scope from runtime to provided under File->Project Structure->Modules->Dependencies. This allowed me to both compile and test within the IDE while including the Groovy modules as well as the Java modules.
Perhaps you had something similar going on in your project?
Six years later, I also just got this question near the top of my search results.
In my project my Unable to load class 'groovy.text.SimpleTemplateEngine' problem was actually due to a codenarc issue. I was able to resolve the issue by adding the following to build.gradle:
// codenarc version issue work-around
configurations.codenarc {
resolutionStrategy.eachDependency { DependencyResolveDetails d ->
if (d.requested.group == 'org.codehaus.groovy') {
d.useVersion '2.4.7'
}
}
}