Welcome to the public discussion channel for the Ceylon programming language (https://ceylon-lang.org)
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?
Should I continue to report here?
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
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
I added some comments in the dev channel
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.
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
@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
is it right
@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).
` public interface Condition {
Condition FALSE = facts -> false;
Boolean evaluate(Fact<?> fact);
default Condition and(Condition other) {
return fact -> this.evaluate(fact) && other.evaluate(fact);
}
default Condition or(Condition other) {
return fact -> this.evaluate(fact) || other.evaluate(fact);
}
default Condition not() {
return fact -> !this.evaluate(fact);
}} @Test
public void testCondition() {
String str = "A String";
Condition a = fact -> !str.isBlank();
Condition b = fact -> str.contains("A");
a.and(b);
}`
interface Condition<Fact>{
shared static Condition<Fact> falseCondition => object satisfies Condition<Fact> {
shared actual Boolean evaluate(Fact fact) => false;
};
shared static Condition<Data >create<Data>(Boolean(Data) evala)=> object satisfies Condition<Data>{
shared actual Boolean evaluate(Data fact) => evala(fact);
};
shared formal Boolean evaluate(Fact fact);
shared default Condition<Fact> and(Condition<Fact> other)=> object satisfies Condition<Fact>{
shared actual Boolean evaluate(Fact fact) => this.evaluate(fact) && other.evaluate(fact);
};
shared default Condition<Fact> or(Condition<Fact> other)=> object satisfies Condition<Fact>{
shared actual Boolean evaluate(Fact fact) => this.evaluate(fact) || other.evaluate(fact);
};
shared default Condition<Fact> not=> object satisfies Condition<Fact>{
shared actual Boolean evaluate(Fact fact) => !this.evaluate(fact);
};
}
shared test void testConditions(){
value a=Condition.create<String>((String fact) => !fact.empty);
value b=Condition.create<String>((String fact)=> fact.contains("A"));
value result=a.and(b).evaluate("A string");
assert(result);
}
You may take out
Condition.create as top level function so You don't have to prefix it
It could be simplified a bit if You would not pass condition to
and and or but function reference like in create so it would be: interface Condition<Fact>{
shared static Condition<Fact> falseCondition => object satisfies Condition<Fact> {
shared actual Boolean evaluate(Fact fact) => false;
};
shared static Condition<Data >create<Data>(Boolean(Data) evala)=> object satisfies Condition<Data>{
shared actual Boolean evaluate(Data fact) => evala(fact);
};
shared formal Boolean evaluate(Fact fact);
shared default Condition<Fact> and(Boolean(Fact) other)=> object satisfies Condition<Fact>{
shared actual Boolean evaluate(Fact fact) => this.evaluate(fact) && other(fact);
};
shared default Condition<Fact> or(Boolean(Fact) other)=> object satisfies Condition<Fact>{
shared actual Boolean evaluate(Fact fact) => this.evaluate(fact) || other(fact);
};
shared default Condition<Fact> not=> object satisfies Condition<Fact>{
shared actual Boolean evaluate(Fact fact) => !this.evaluate(fact);
};
}
shared test void testConditions(){
value a=Condition.create<String>((String fact) => !fact.empty);
value b=((String fact)=> fact.contains("A"));
value result=a.and(b).evaluate("A string");
assert(result);
}