Today i decided to see up Groovy source code and to built up my programming muscles in Groovy. I downloaded the Groovy Source code 1.8 from this link. But how do i proceed? In sense which folder first i have to see, so that i can understand better how groovy works(because there are many folders like benchmarks,bootstraps, src etc). May be this seems to be stupid question but i wanna to ask it.
Correct me if am worng.
The source code is inside src/main.
The unit tests all live inside src/test.
I found a good place to start looking was inside the huge class:
src/main/org/codehaus/groovy/runtime/DefaultGroovyMethods.java
This is where a lot of the extra Groovy methods are defined, so you can pick your favourite function (such as String.capitalize for example) and find the definition of that method (around line 9561, but that might be different in the version of the code you have downloaded)
You should then be able to (for example) change how something works, and check that the unit tests still function by calling
ant test
from the root folder, then you should see it build and test reports should be created and placed in the target folder
I tend to use a combination of find and grep to locate the area in the source that I am interested in, then slowly expand out from that class as I find other things that relate to it...
Hope this helps...it's a bit of a big question to try and cover
Related
I was learning Haxe. And I found that a code that is in the official manual doesn't be compiled in https://try.haxe.org/. and I wonder why and how to fix the code?
the code is the one in here: https://haxe.org/manual/types-enum-using.html
try.haxe.org assumes that the class that contains the entry point main() is called Test, while the code example you linked uses Main.
It appears to work fine once you change class Main to class Test in the code snippet: https://try.haxe.org/#68274
Note that some other code examples from the manual may not compile because try.haxe.org still runs Haxe 3.4.4, while the current release is 4.0.5. To work around this, people usually use this fork of try.haxe that lets you specify the Haxe version to use in the options tab:
http://try-haxe.mrcdk.com/
I am attempting to convert parts of an Android app to iOS using Doppl, and I am getting a strange result: Doppl keeps trying to pull in android.arch.lifecycle:reactivestreams, even though I don't want it to.
Specifically, in app/build/j2objcSrcGenMain/android/arch/lifecycle/, there is a reactivestrams/ subdirectory with R.h and R.m files in it. This seems to make Xcode cranky and may explain why I had some oddities with pod install.
My app/build.gradle has compile "android.arch.lifecycle:reactivestreams:$archVer", because my activity is using LiveDataReactiveStreams.fromPublisher(). However:
The activity is not in the translatePattern (and since its code is not showing up in app/build/j2objcSrcGenMain/, I have to assume that the translatePattern is fine)
I do not have a doppl statement related to reactivestreams, because there does not appear to be a Doppl conversion of this library (nor should it be needed here)
AFAIK, nowhere else in this app am I referring to LiveDataReactiveStreams, which AFAIK is the one-and-only public class from the reactivestreams library
So, the questions:
What determines whether Doppl creates R.h and R.m files for some dependency? It's not the existence of a doppl statement, as I have doppl statements for a lot of other dependencies (RxJava, RxAndroid, Retrofit) and those do not get R.h and R.m files. It's not whether the dependency is referenced from generated code, as my repository definitely uses RxJava and Retrofit, yet there are no R files for those.
How can I figure out why Doppl generates R.h and R.m for reactivestreams?
Once I get this cleared up... do I re-run pod install, or is there some other pod command to refresh an existing pod with a new implementation?
Look into 'app/build/generated/source/r/debug' and confirm there's an R.java being created for the architecture component. It'll be under 'android/arch/lifecycle/reactivestrams'.
I think there are 2 problems here.
Problem 1
Somehow Doppl/J2objc is of the opinion that this file should be transpiled. It could be either that 'translatePattern' matches with it, or that something in the shared code is referencing it. If you can't figure out which, please post a comment and I'll try to help (or post in slack group).
Problem 2
Regardless of why that 'R.java' is being sucked into the translate step, because of how stock J2objc is configured, the code is being generated with package folders instead of creating One Big Name. That generated file should be called 'AndroidArchLifecycleReactivestramsR.h' (and AndroidArchLifecycleReactivestramsR.m). Xcode really doesn't like package folders. That's why there's a slightly custom J2ojbc being used with Doppl, so we can have files with big names instead of folders.
In cases where you intentionally use package names that match with what J2objc considers to be "system" classes, you need to provide a header mapping file to force long names. The 'androidbase' doppl library needs to add a lot of files that are in the 'android' package, which J2objc considers "system". We override those names in the mapping file.
build.gradle
https://github.com/doppllib/core-doppl/blob/master/androidbase/build.gradle#L19
mapping file
https://github.com/doppllib/core-doppl/blob/master/androidbase/src/main/java/androidbase.mappings
I screwed up.
In my dopplConfig, I have:
translatePattern {
include '**/api/**'
include '**/arch/**'
include '**/RepositoryTest.java'
}
In this case, **/arch/** not only matches my arch package, but also the arch package from the Architecture Components.
Ordinarily, this would not matter, because the Architecture Components source code is not in my project. But, R.java gets generated, due to resources, and the translatePattern includes generated source code in addition to lovingly hand-crafted source code. So, that's where my extraneous Objective-C was coming from.
Many thanks to Kevin Galligan for his assistance with this, out on the #newbiehelp Doppl Slack channel!
I am unable to get the --sourcepath option of groovyc to work at all. Can someone furnish a trivial example of it actually doing anything?
Ultimately I want to use "groovyc" at the command line with a directory a packaged organized tree of mixed groovy and java source. I don't want to reference each source file explicitly. And I don't want to use an ant or maven task either, on grounds of both principle (hey is there a bug here?) and because the production scenario that I might want to tweak the source in has neither but will have groovy. I know I could use unix find but must I resort to that?!
sourcepath isn't used anymore. It's only there for backwards compatibility and will be removed in the future.
The Groovy documentation is currently rewritten, you can find a snapshot including the documentation for groovyc here: https://dl.dropboxusercontent.com/u/20288797/groovy-documentation/index.html#ThegroovycAntTask-groovyc
I am trying to learn CMake. I have the Mastering CMake book and I'm trying to go through my first "easy" tutorial. Using CMake: Hello World Example
I made it through the first part alright, but when I tried to add the sub folders for the "Building a library" part of the tutorial I'm just not getting it. I followed the instructions all the way to the very end.
**We've seen an example of how to build a program. Now let's make a library as well. The library will be called "namer" and it will have a single function "getWorld" that returns the name of the nearest planet. We choose to put this library in a subdirectory called "namer" - it doesn't really matter where we put it, this is just an example.
I made it a subfolder in my HelloWorld project. Should I be making this a separate project?
**One way we can help CMake find the Namer package (which will be our namer library) is by writing a helper script called FindNamer.cmake. This is just another file written in the CMake language that pokes around in all the places our library might be hiding. Here is an example (put this in "hello/FindNamer.cmake"):
This is my FindNamer.cmake file:
find_path(Namer_INCLUDE_DIRS world.h /usr/include "$ENV{NAMER_ROOT}")
find_library(Namer_LIBRARIES namer /usr/lib "$ENV{NAMER_ROOT}")
set(Namer_FOUND TRUE)
if (NOT Namer_INCLUDE_DIRS)
set(Namer_FOUND FALSE)
endif (NOT Namer_INCLUDE_DIRS)
if (NOT Namer_LIBRARIES)
set(Namer_FOUND FALSE)
endif (NOT Namer_LIBRARIES)
**The important parts here are the "find_path" and "find_library" commands, which look for the header file world.h and the namer library.
I followed the next instructions and at the very end the tutorial includes this:
**If we try again, configuration will still fail since the search path we gave for "find_path" and "find_library" doesn't actually include the needed files. We could copy them, or have added a hard-coded directory to find_path and find_library pointing to where the files are on our hard drive - but better, in the CMake GUI on windows or by running "ccmake ." on Linux, we can just fill in the directories there.
At this point I am completely confused (Newbie!!!!). I don't have a NamerConfig.cmake or namer-config.cmake file and I don't know what the find_path and find_library is supposed to be pointing to.
Thank you in advance for your help,
Severely Confused :-(
I said I was a newbie. I guess I'm a little tired too! Yes, these must be in two separate projects.
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'
}
}
}