ceylon/user

Welcome to the public discussion channel for the Ceylon programming language (https://ceylon-lang.org)

Pedro Lamarão

@pedrolamarao

I'll investigate.

My objective in this case is just to demonstrate an application of jnr-ffi to define native bindings.

John Vasileff

@jvasileff

Folks, towards our goal of a 1.3.4 release that is basically 1.3.3 + fixes, I have automated development builds of the Ceylon distribution and Eclipse IDE. They are available at https://github.com/eclipse/ceylon/actions?query=workflow%3Aintegration-build.

Click on the latest successful build and download "ceylon-build-artifacts" which includes a zip file of the Ceylon distribution & IDE.

While these builds should be usable, they currently contain some unwanted new features and compatibility breaks, such as un-curried versions of fold(), etc. Over time, we will improve feature equivalence and compatibility with 1.3.3.

The current build of course includes the fix for the Maven Central URL

Pedro Lamarão

@pedrolamarao

What version of Eclipse is usable? Is it still on Photon?

John Vasileff

@jvasileff

@pedrolamarao Yes, as I understand, Photon is the latest eclipse that will work. (I responded a couple days ago, but I guess Gitter ate my message?)

Pedro Lamarão

@pedrolamarao

@jvasileff ok, thanks! I'll try it out soon.

Pedro Lamarão

@pedrolamarao

I've installed the snapshot IDE.
It fails compiling projects with import ceylon.test "1.3.3";.
There seems to be many missing dependencies:

cannot find module source artifact 'ceylon.collection-1.3.3.osgi-5(.car|.jar|.src|.js)'
    - dependency tree: 'peu.ceylon.tui/1.0.0' -> 'ceylon.test/1.3.3' -> 'ceylon.collection/1.3.3.osgi-5'    module.ceylon    /ceylon-tui/src/main/ceylon/peu/ceylon/tui    line 5    Ceylon Module Dependency Error
cannot find module source artifact 'ceylon.file-1.3.3.osgi-5(.car|.jar|.src|.js)'
    - dependency tree: 'peu.ceylon.tui/1.0.0' -> 'ceylon.test/1.3.3' -> 'ceylon.file/1.3.3.osgi-5'    module.ceylon    /ceylon-tui/src/main/ceylon/peu/ceylon/tui    line 5    Ceylon Module Dependency Error
cannot find module source artifact 'ceylon.language-1.3.3.osgi-5(.car|.jar|.src|.js)'
    - dependency tree: 'peu.ceylon.tui/1.0.0' -> 'ceylon.test/1.3.3' -> 'ceylon.language/1.3.3.osgi-5'    module.ceylon    /ceylon-tui/src/main/ceylon/peu/ceylon/tui    line 5    Ceylon Module Dependency Error
cannot find module source artifact 'ceylon.runtime-1.3.3.osgi-5(.car|.jar|.src|.js)'
    - dependency tree: 'peu.ceylon.tui/1.0.0' -> 'ceylon.test/1.3.3' -> 'ceylon.runtime/1.3.3.osgi-5'    module.ceylon    /ceylon-tui/src/main/ceylon/peu/ceylon/tui    line 5    Ceylon Module Dependency Error
cannot find module source artifact 'com.redhat.ceylon.dist-1.3.3.osgi-5(.car|.jar|.src|.js)'
    - dependency tree: 'peu.ceylon.tui/1.0.0' -> 'ceylon.test/1.3.3' -> 'com.redhat.ceylon.dist/1.3.3.osgi-5'    module.ceylon    /ceylon-tui/src/main/ceylon/peu/ceylon/tui    line 5    Ceylon Module Dependency Error

I tried updating the version to 1.3.4 and 1.3.4-SNAPSHOT, but, these version were not found.

I intend to continue investing on Ceylon for quite some time.
Should I continue to report here?

John Vasileff

@jvasileff

@pedrolamarao yeah, although there isn't a ton of activity in this channel, it is the best place for support and feedback

I'll have to take a look at the errors. @davidfestal any idea why the osgi-5 suffix is present on the module names? This happens at the cli as well. Perhaps there's a problem with my build script.

As for not finding 1.3.4-SNAPSHOT modules, the Ceylon SDK ships separately from the dist, so you'll need to make the repository (directory) holding the sdk available to the compiler, or copy the modules to ~/.ceylon/repo

John Vasileff

@jvasileff

To configure repository paths for a project, you can use PROJECTDIR/.ceylon/config

John Vasileff

@jvasileff

Oh, and thanks for giving the build a try!

John Vasileff

@jvasileff

So the answer is... for now at least you need to use 1.3.4-SNAPSHOT modules with the 1.3.4-SNAPSHOT build. There is a compatibility break with move of the project to the Eclipse Foundation causing all prior modules to no longer work.

David Festal

@davidfestal

the osgi-5 is expected to be added in the OSGI name of the module.

You see it here because, after trying to resolve the module with the Ceylon module resolver, and not finding dependencies, it tries to resolve it as an osgi module and doesn't find the dependencies as well, so writes this message

afair

the osgi-5 naming is not the cause of the error. It's more a confusing message related to the fact that the osgi dependency resolver is used at some point

John Vasileff

@jvasileff

@davidfestal thanks, makes sense. It seems 1.3.4 can't read 1.3.3 metadata, so it is falling back to non-Ceylon module resolution of some sort.

I added some comments in the dev channel

David Festal

@davidfestal

yeah, probably

Pedro Lamarão

@pedrolamarao

I'll try to adjust .ceylon/config soon.

Pedro Lamarão

@pedrolamarao

There is no /.ceylonb clean, is that really so?

Pedro Lamarão

@pedrolamarao

Also: I have found my original problem with resources. Ceylon is ignoring META-INF/services/some.file located in "resources" root.

Pedro Lamarão

@pedrolamarao

I tried --resouce and --resource-root: the above is not inserted in the module.

John Vasileff

@jvasileff

@pedrolamarao all resources must be in a directory structure that matches the module name. But the special subdirectory ROOT can be used for root-level resources

see the line ./resource/com/example/thing/ROOT/META-INF/MANIFEST.MF in https://ceylon-lang.org/documentation/1.3/reference/tool/project/

I had trouble with this exact thing the first time I tried to add a root-level resource.

kiti_Nomad

@Kiti-Nomad

i cant download ceylon ide

Pedro Lamarão

@pedrolamarao

@jvasileff thanks! I'll get that into some of my core samples soon.

Pedro Lamarão

@pedrolamarao

I think I may be hitting a fundamental incompatibility here.
Using the ROOT technique I was able to insert META-INF/services/foo.Service inside the .car module.

But ServiceLoader can't find it.

Stepping into its implementation, I've found a point where CeylonModuleClassLoader.getResources returns an empty enumerator.

The service and the user are defined in separate modules.

Se the user evaluates ServiceLoader.load(``Service``) which delegates to ServiceLoader.load(Service.class, Service.class.getClassLoader()) which eventually calls CeylonModuleClassLoader.getResources

Pedro Lamarão

@pedrolamarao

(Or something like that)

Pedro Lamarão

@pedrolamarao

Maybe I'm approaching my use case wrong. Fudamentally, I need to define a service in a module and expose this service through ServiceLoader to another module. Is there a sample for this use case somewhere?

John Vasileff

@jvasileff

@pedrolamarao I don't remember all the details, but you might want to check out https://ceylon-lang.org/documentation/1.3/tour/interop/#interoperation_with_java_s_serviceloader

Pedro Lamarão

@pedrolamarao

Thanks for the tip! This was sufficient to complete my sample!

Pedro Lamarão

@pedrolamarao

Documetation seems complete but curiously difficult to index.

kiti_Nomad

@Kiti-Nomad

I want to ask you a question, are JIT and AOT the characteristics of the VM language? I never encountered such a concept when I was learning C ++ and D

kiti_Nomad

@Kiti-Nomad

The JVM language is JIT, but I also saw the concept of AOT

kiti_Nomad

@Kiti-Nomad

Someone told me that the jvm language takes AOT when compiled into bytecode, and JIT when run in a virtual machine. Languages like cpp directly generate executables, so it takes AOT

is it right

John Vasileff

@jvasileff

@kiti-nomad this channel is for discussions about the Ceylon language. I believe you'll find better responses to questions regarding Java and specific JVMs in forums dedicated to those technologies

kiti_Nomad

@Kiti-Nomad

Roland Tepp

@luolong

@kiti-nomad what John told is correct, but in short, AOT stands for “Ahead of Time” compilation and JIT stands for “Just in time compilation”.
The main difference is when the compiler generates specific machine code instructions and performs optimisations.

With AOT, the compiler generates architecture specific binary before a single line of code is executed—i.e. Ahead of (execution) Time. The optimizations that a compiler can do at that time are extensive, but can not accout for runtime characteristics of the particular program.

With JIT, the compiler starts out by interpreting the code when first executed and as it gets more info on the runtime characteristics of the code, it starts replacing bits of the interpreted runtime with architecture specific machine instructions, applying optimizations as it is running the code. Effectively, creating optimized set of instructions Just in the time (of execution).

Where communities thrive

People

Repo info

Activity