I'm new in Kotlin, nowadays there is a problem disturbed me for a long time. I find we didn't import any packages or classes when we use functions such as let which defined in kotlin-stdlib.jar. I'm curious about how it works in such way.
It works the same was as it works in Java for the java.lang package: some Kolin packages are automatically imported.
See the documentation
Related
I'm using SQ 7.3-alpha1 with sonar-kotlin-plugin-1.0.1.965.jar. However, I cannot deactivate a special warning inside my Kotlin code for repositories in Spring Data where I need an "_" in a method name.
I tried both //NOSONAR and #Suppress("kotlin:S100") and #SuppressWarnings("kotlin:S100"). Any hint is appreciated.
You're not able to deactivate that issue because none of the mechanisms you're trying to use have been implemented for Kotlin.
Instead, you'll have to do this from the UI side.
Great news, https://jira.sonarsource.com/browse/SONARSLANG-373 is fixed in version 1.6 of Sonarslang. So an update to that version might improve the situation. I’ve not tested it yet, hence the cautious wording.
I'm trying to create a Kotlin Vert.x language support module and I need a way to compile Kotlin files and load the results with a ClassLoader. I've tried using kotlin-compiler library and found K2JVMCompiler class, but it seems to support only command-line-style arguments with its exec method. Is there a way to compile a Kotlin file in runtime (possibly without having to save and read .class files) and immediately load the generated classes? (Kind of like Groovy does.) If not, do you have any useful compiler arguments suggestions or pretty much any advices?
This feels like an XY Problem. You want to know how to compile Kotlin on the fly so that you can more easily use Vert.x by running from Kotlin source files instead of compiled code. But really the recommended path for Vert.x usage is to create a simple bit of code that deploys your verticle within compiled code.
In the question, your link for language support says Vert.x 2 in the path "vertx.io/vertx2/language_support.html"; which is different than how it is now done in Vert.x 3. I think you are merging two thoughts into one. First that Vert.x 3 wants you to run Java/Kotlin files from source (it doesn't really; that was a Vert.x 2 thing they moved away from for compiled languages), and second that you need custom language support (you don't).
You should try to use Vert.x 3 by running compiled code. To do so, build your classes and run your own main() that deploys a verticle programatically. Your code would be simple as:
import io.vertx.core.Vertx
fun main(args: Array<String>) {
val vertx = Vertx.vertx()
vertx.deployVerticle(SomeVerticleOfMine())
}
Alternatively, the docs for running and deploying from the command-line say:
Vert.x will compile the Java source file on the fly before running it. This is really useful for quickly prototyping verticles and great for demos. No need to set-up a Maven or Gradle build first to get going!
And really it is indeed just for prototyping and quick testing, and it isn't any faster than letting your IDE do the same and running from the compiled classes. You also then have debugging features of the IDE which are infinitely valuable.
For a few helper libraries for using Kotlin with Vert.x, view these options:
Vert.x 3 module for Klutter - I am the author, one of my libraries
Vert.x 3 helpers for Kotlin - by Cy6erGn0m
Kovert, a REST framework for Vert.x 3 - I am the author, one of my libraries
Vert.x nubes - not Kotlin specific, but makes Vert.x-Web friendlier for JVM languages.
There is a full sample project of running Vert.x + Kovert (specifically start with the App class). You can look at the code of Kovert to do your own similar work of starting and running Vert.x nicely, with Promises or however you wish. The docs for Kovert have links to code for starting Vertx and also starting a Verticle to use Vert.x-Web, so more sample code you can read. But it helps to understand Injekt (light-weight dependency registry), Kovenant (promises library), and Klutter configuration injection to understand the complete sample.
Other quick note, Vert.x has codegen support for other languages, but since you can call all of the Java version directly, it does not need to support Kotlin either.
Kotlin 1.1 comes with javax.script (JSR-223) support, which means you can use it as scripting engine similarly to JavaScript with Nashorn.
What does this warning mean?
It is appeared in version 1.0.0-beta-3595 for all usages of kotlin android extensions in my code.
I think they did this to support multiple build variants. For example when you have a flavour proversion and you want to use a layout from that flavour you have to use
import kotlinx.android.synthetic.proversion.activity_main.*
For the main build variant you have to use
import kotlinx.android.synthetic.main.activity_main.*
Not strictly the answer to the question 'why did they do that', but that's how to eliminate warning.
Change
import kotlinx.android.synthetic.activity_main.*
to
import kotlinx.android.synthetic.main.activity_main.*
implying that you already bumped version in build.gradle and updated IDEA (or AS) kotlin plugins.
Hi I've been playing a little bit with Frege and I just noticed in some examples that package and module are used interchangeably:
package MyModuleOne where
and sometimes:
module MyModuleTwo where
When importing from one or the other I don't see any difference in the behavior of my program. Is there something I should keep in mind when using package or module keywords ?
Yes. It used to start out with package, but later I realized this was an obstacle when porting Haskell code which uses module. Hence I added module, and thus currently module and package are the same keyword, just spelled differently.
But the intention is, of course, to retire package sooner or later. So my advice would be to use module only.
(This reminds me that I probably have to update the lang spec with regard to this. Never mind.)
I'm attempting to install Pieradmin on a clean image of Pharo 1.4 (Summer), using the commands:
Gofer it
renggli: 'pier2addons';
package: 'ConfigurationOfPierAdmin';
load.
ConfigurationOfPierAdmin loadBleedingEdge.
It progresses for a while and comes up with the error:
This package depends on the following classes:
ImageSegment
You must resolve these dependencies before you will be able to load these definitions:
writeKernel:on:
You can proceed and it will finish installing all its dependencies.
I have two questions:
Where can I get the class ImageSegment?
Or, if I can't, does it matter that writeKernel:on: isn't there?
Nathan,
The dependency on ImageSegment is almost certainly coming from the package Pier-Pharo-Persistency defined in ConfigurationOfPier2>>baseline2060: where it is included as part of Core group for Pier ... which at first glance makes it appear that the Pier-Pharo-Persistency is pretty much required for Pier.
You could fiddle with the ConfigurationOfPier2>>baseline2060: and remove Pier-Pharo-Persistency from the Core group, then try the load again, but you may just be creating another more subtle problem for yourself. It's probably a good idea to ask this question on the Pier mailing list
OTOH, I'm pretty sure that Pier-Admin works in Pharo-1.3 so that would be your best option.
Dale
Yes, ImageSegment was removed from Pharo 1.4. And ReferenceStream was also removed from Pharo 2.0. The idea was to rely on new and better tools like Fuel serializer (see http://rmod.lille.inria.fr/web/pier/software/Fuel).
Yanni and me have done 2 things: Pier persistence and kernel export/import based on Fuel. You can find the code in:
Gofer it
squeaksource3: 'pierfuel';
package: 'Pier-FuelPersistence-Core';
package: 'Pier-FuelPersistence-Test';
load.
Then you can do, for example:
PRFuelExporterImporter new exportKernelNamed: 'pierDBX' toFilename: 'pierDBX.fuel'
And:
PRFuelExporterImporter new importNewKernelNamed: 'pierDBX' fromFilename: 'pierDBX.fuel'