Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 08 2021 10:05
    supersache opened #7471
  • Oct 01 2021 12:51
    l7rf1i82 commented #7464
  • Oct 01 2021 12:51
    l7rf1i82 commented #7464
  • Oct 01 2021 12:49
    l7rf1i82 commented #7464
  • Sep 30 2021 08:21
    l7rf1i82 closed #528
  • Sep 30 2021 08:21
    l7rf1i82 commented #528
  • Sep 29 2021 08:05
    l7rf1i82 opened #528
  • Sep 10 2021 06:34
    codeMonkey404 opened #671
  • Jun 19 2021 01:40
    kingjon3377 opened #527
  • Jun 19 2021 01:35
    kingjon3377 opened #526
  • Jun 04 2021 01:23

    dependabot[bot] on maven

    (compare)

  • Jun 04 2021 01:23
    dependabot[bot] closed #7456
  • Jun 04 2021 01:23
    dependabot[bot] commented #7456
  • Jun 04 2021 01:23
    dependabot[bot] labeled #7470
  • Jun 04 2021 01:23
    dependabot[bot] opened #7470
  • Jun 04 2021 01:23

    dependabot[bot] on maven

    Bump httpclient from 4.3.2 to 4… (compare)

  • May 06 2021 15:49
    jvasileff closed #7469
  • May 06 2021 15:49
    jvasileff commented #7469
  • May 05 2021 06:11
    CretinHo opened #7469
  • Apr 07 2021 08:41
    ShalokShalom commented #7454
Tako Schotanus
@quintesse
I just know that right now there already exists a "flat" classloader that would just ignore any modularity restrictions imposed by the language. So technically it is definitely possible to run Ceylon without a modular classloader.
(Btw, just out of curiosity I created a branch where I ripped out everything related to CMR to see how much code would be affected and it's quite a lot. I need to find more time to take a closer look)
Enrique Zamudio
@chochos
maybe instead of ripping it out completely, a replacement CMR can be made that simply delegates to Java's new module system... module.ceylon could still be used to define the module, but package it like a regular java module, adding the required ceylon dependencies...
Tako Schotanus
@quintesse
It's indeed something that could be considered. But I wonder if that would get us closer to the desired simplicity (that some of us seem to want).
I'm assuming for example that Java modules won't work on Android, so we'd have to have two systems again. Given that the one for Android would also work on the JVM (but without any module visibility/access guarantees) it would probably just be easier to focus on that one.
For me the interesting part, like @luolong also mentioned, would be to figure out if we'd also want to get rid of the whole idea of modules completely, even at the language level, or if that's still a valuable feature. (In the latter case the Java modules would still be a viable option in the future)
Enrique Zamudio
@chochos
I'd get rid of them completely and use the standard java module system. It also facilitates integration with build systems like maven or gradle
Tako Schotanus
@quintesse
Ok, let me try to understand that better, what would the Java modules be used for then? Without modules in the language wouldn't plain class files be sufficient?
Enrique Zamudio
@chochos
yes
fill0llif
@fill0llif
I really like ceylon module as a user, and I understand it has brought unnecessary complexity into the whole language, I think it's ok ripping it off its module system, but I guess java module system is going to be important in the near future, how would you address this development?
Roland Tepp
@luolong
to be honest, I too liked the language module system, but perhaps the whole machinery of the module resolution was a bit overboard.
I would not mind treating module.ceylon as a build time module metadata container and ignore the module resolution bits.
For java, it could compile to Java modules. For OSGi it could compile to OSGI metadata, for node/js, the relevant bits would be compiled into package.json or something similar.
Leave the module resolution (if any) be handled by the runtime platform&container if wants to.
Would that bring enough simplification while keeping the “good parts”?
Tako Schotanus
@quintesse
No idea, I guess that's something that would have to be figured out :-)
David Festal
@davidfestal
I also prefer the idea of keeping the basics of module declarations in the language, but with the requirement to provide the module resolution by external tools, or have an option to completely disable it.
modules as they are declared today could also be useful to have an integration with containers: having modules be produced as container images.
So having a way, in the language, to declare module dependencies, and module boundaries, seems still very useful to me as long as it is seen as modularity guidelines, and is not required to match a too-limited number of module implementations.
John Vasileff
@jvasileff
I believe that to have first class classpath support, the first step would be to totally remove everything having to do with modules and module resolution. This would involve spec changes to deal with the lack of structure. Anything short of complete removal of the existing module system would compromise classpath support. I agree with Tako that this would be a lot of work. Then, as step two, introduce support for jpms including compile time checking for visibility restrictions, and for convenience, a grapes style maven module resolver for scripts and lightweight projects in which you don't want to use gradle/ant/mvn.
Step two would be fairly straight forward, and, as with Java, wouldn't fundamentally alter the programming language
As for complex osgi style runtime classloading, I think that could be left for existing third party tools for the few people who find it useful. And, frankly, osgi not the direction the Java ecosystem is heading - the trend is a 180 from that, where linking is done at compile time with graal native-image
Roland Tepp
@luolong

I agree with ditching runtime aspects of module system. I would keep the compile time (visibility restrictions) of the module system – I believe they offer a very useful design constrint that makes you think hard about your dependencies.

As to how we get to that state … maybe we do need to rip out everything before adding the compile time stuff back in. I don’t really know how, but the intuition says that rip out everything and then re+add only relevant bits sounds like a better and more straight forward plan.

Joost Morsink
@joost-morsink
Good to see Ceylon reviving again, if only the intention. Is there any actual funding for the work to be done, or is this going to be a non-paying community effort?
Tako Schotanus
@quintesse
@joost-morsink I'm afraid none of us are funded. I guess the only way that would ever happen again is when Ceylon gets a much larger community and is recognized outside its small circle of devs and users.
Stéphane Épardaud
@FroMage
Hi, please note that the Ceylon module repository is likely to be taken offline real soon. Let me know if you find this unacceptable and want to discuss hosting options. Sorry about this.
Tako Schotanus
@quintesse
Does it still receive any real amount of traffic?
Stéphane Épardaud
@FroMage
I don't actually know
I could check
Tako Schotanus
@quintesse
Look, it would only have taken Ceylon until 2022 to have Integer performance on par with Java int (they're finally adding performance improvements to long): https://www.youtube.com/embed/B8k9QGvPxC0?start=2029&end=2038
John Vasileff
@jvasileff
Nice. From the video: "More APIs are cropping up where long indices are going to be used." Surprising this hasn't been recognized as a bigger issue before
Tako Schotanus
@quintesse
In the video they mention that so far only int were necessary/available for memory access. Array indices were always just ints and the Buffer class was made in a time where they didn't think they'd ever need to access more memory than that provider by int. But at least they've come to their senses :-)