Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 05 20:47
    ericdriggs commented #7454
  • Feb 11 03:56
    dependabot[bot] labeled #7472
  • Feb 11 03:56
    dependabot[bot] opened #7472
  • Feb 11 03:56

    dependabot[bot] on maven

    Bump json-smart from 1.3.1 to 1… (compare)

  • Feb 11 03:55
    dependabot[bot] labeled #135
  • Feb 11 03:55
    dependabot[bot] opened #135
  • Feb 11 03:55

    dependabot[bot] on maven

    Bump json-smart from 1.1.1 to 1… (compare)

  • 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
Stéphane Épardaud
@FroMage
Guys, sorry to spoil the fun, but I'm sure Eclipse will not accept a release with non-eclipse package names
They told us that much from the start
We would not have renamed it otherwise
As for using the redhat package name for an independent release we would have to check that with our legal department first :(
I think it'd be really great if you could resume work on the Eclipse master branch, that would give you a better standing
Especially if Red Hat complains at the package name if you do another release, because in both cases you'll have to rename
Wojciech Potiopa
@Voiteh
In this case we should concentrate to provide minimal amount of changes and concentrate to provide only what has been finished and all breaking changes that were planed to be included. All other stuff should be excluded
Stéphane Épardaud
@FroMage
That's up to you
Wojciech Potiopa
@Voiteh
I think we should create release/1.4.0 branch from master and revert commits which are WIP and include minimal BC changes and fixes, so that we could work on it togather
Wojciech Potiopa
@Voiteh
we could have another issue like #7460 for tracking what commits we exclude/include
Roland Tepp
@luolong
:+1:
John Vasileff
@jvasileff

That’s too bad. My intention was to help create a backwards compatible release with minimal changes, primarily motivated by the Maven https issue, but also to create a base to (potentially) build on for additional preservation work, such as Java 9+ compatibility.

But, I didn’t realize that a making a compatible release within the Eclipse Foundation was totally out of the question. I’m not interested in forking the project (i.e. new website, branding, etc.), and I’m also not interested (at least for now) in spending time on a compatibility breaking release. IMHO, that would be much less valuable.

We do at least now have a working GitHub Actions build (https://github.com/eclipse/ceylon/actions?query=workflow%3Aintegration-build), so perhaps I’ll add a branch in my GitHub account to build the full 1.3.3 release + maven https url patch. I’m not sure what else there is left for me to do/offer at this point.

Wojciech Potiopa
@Voiteh
Alone I have no chance to prepare the release...
Wojciech Potiopa
@Voiteh
but I will try...
kiti_Nomad
@Kiti-Nomad
加油
Wojciech Potiopa
@Voiteh
@FroMage #7263 do You know if support for Java 9 has been compleated ? Should we include this into 1.4.0 ?
Stéphane Épardaud
@FroMage
according to this issue it was
Wojciech Potiopa
@Voiteh
I looked in all the commits of master branch and they seems all fine we need to decide what else would we want to have in 1.4.0
There are few other issues labeled with Breaking change
https://github.com/eclipse/ceylon/labels/breaking%20change I don't see in most of them the agreement that we wan't them to be included. Only #7409 this I see as includable.
momomo
@momomo
@Voiteh At this point I would not be too concerned with breaking changes. Is that more important than giving it a fresh start, even if that might break backwards compatibility for the few that have projects depending on it? The alternative is they might never have an update and would still continue to live with the version they are running now.
If mistakes were made in the language before, like Gavin has hinted, this might be an opputonity to fix them. I also don't know why so fuck focus was put into making ceylon code compile to javascript. i personally would not consider using it or any other language for that purpose.
Wojciech Potiopa
@Voiteh
@momomo We have minor version change so it would be good to include all the breaking changes into the release, that we agree on. Then in 1.4.x fixes we would just improve what would need to be, as bugs naturally occures. We are trying to give it a fresh start. As for JS, this wild beast need to be tamed somehow. I work in my daily job with Typescript and it's quirky . Kotlin - limited typing. Dart - didn't checked.
MikhailMalyutin
@MikhailMalyutin
@momomo Absolutely agree. It is almost impossible to force frontent javascript developer to use other language than javascript or at least Typescript. We use ceylon in production but in JVM backend only. Modern JS frontend is a very unstable thing, a lot of JS frameworks is created and died. Compiling to JS must be optional expererimental feature, most developers will never use it. But for JVM and backend development ceylon language was very good.
momomo
@momomo
Yes, it must have been an immense job and waste of time working on that. The best thing this project could do is to strip it bare, to a minimum to maintain and let community then build libraries for it. This is the best for maintainance later. Everything that is not essential I would recommend to just hit delete. If you don't, you will always have to maintain those parts for refactoring, always run those tests, always go into those code pieces that are irrelevant and just update minor things to make them continue to compile and test.
It is a time waster. I have lots of code, even for things i've rewritten in new better ways, and old projects. When my code base change, I still always have to go in and ensure those libraries and project doesn't get destroyed. So even when my code is improving, changing it now, i have to take into consideration all those old projects and libraries that I might or might not need in the future. But I keep thinking I might return to those projects but they do cost additional time.
momomo
@momomo
And i would do much better if I just was able to discard them.
Wojciech Potiopa
@Voiteh
Let's concentrate on this release first. Then we can think what we want to remove etc. Maybe we could find someone to maintain JS part.
Wojciech Potiopa
@Voiteh
Someone needs to review what is essential for release on IDE's part and on SDK. I can give more details if anyone interested
momomo
@momomo

I found this thread with Gavin commenting:

https://news.ycombinator.com/item?id=8437363

He traded off features in ceylon because they could not be ported to JS. What a mistake. Probably the biggest thing is to even having that as a priority or on the list at all.
Roland Tepp
@luolong
I think if we ever should target web front-end, it should be WebAssembly rather than compiling to JavaScript.
But Wojciech is right. Lets get this release out first and worry about future later.
Casey Dahlin
@sadmac7000
I was always more frustrated by features that were missing because of Java compatibility than ones that were missing for JavaScript compatibility.
David Festal
@davidfestal
I assume future direction would be basing Ceylon Backend in graalvm / truffle, which might give Java interop for free as well as interop with other languages such as JavaScript.
Roland Tepp
@luolong
Yes. Seconded!
Suminda Sirinath Salpitikorala Dharmasena
@sirinath
Graal cannot be used in OpenJ9 and non-OpenJDK JVMs
Any way a common backend which can target Graal and ECJ would be a better choice
Suminda Sirinath Salpitikorala Dharmasena
@sirinath
Maybe you can fork the Kotlin 1.4+ backend and adapt it for Ceylon where you only maintain the front end. Maybe they might accommodate some Ceylon specifics also
The alternative may be used, Scala TASTy
Suminda Sirinath Salpitikorala Dharmasena
@sirinath
kiti_Nomad
@Kiti-Nomad
GraalVM
很多年前,出现过一个类似的虚拟机,parrot。他具有和GraalVM类似的功能
不过它运行的基本上都是动态的脚本语言
Tako Schotanus
@quintesse

Resurrecting a past discussion for a bit, but I actually agree, to some point at least, with what @momomo said back in April:

The best thing this project could do is to strip it bare, to a minimum to maintain

One of the last suggestions I made for the project was that perhaps we had tried to bite of more than we could chew with the CMR, the Ceylon Module Resolver. Yes it could have been really nice if it had all worked out, but IMO it's one of the things that a) sucked up a lot of our time b) was unnecessarily complex (and trying to simplify it would take precious resources away from other important issues) and c) it made interop with Java way more difficult than it needed to be.

My suggestion was to forget about backwards compatibility, create a version 2.0 and mercilessly rip out the CMR part of Ceylon (and I'm saying that as the one who has done the most work on it ;-) ) and just use the native solutions of each platform (Maven artifacts, NPMs, etc). We'd just keep the language, which after all is the nicest part of Ceylon by far.

Now, that didn't mean I wanted to get rid of Ceylon being able to obtain dependencies for compilation/execution automatically, but I was thinking of something much more simple, perhaps a frontend that would make sure all dependencies got downloaded and would be available locally. (In the way JBang https://jbang.dev/ is doing it right now for Java for example).

Anyway, sorry for being late to the party, just wanted to chime in a for a bit ;-)

David Festal
@davidfestal
Hi @quintesse ! Nice to see you here ! I was recently thinking it would be great to have a way to make modules be docker images. And have the ceylon module system be container-native ... But maybe it's just an unfeasible dream.
Luke deGruchy
@lukedegruchy
I’ve been lurking/watching but not participating. What does this mean for the semantics of shared, exposing functions/etc within a package, Herd, etc? Does this mean the language machinery remains but there’s no such thing as Ceylon native modules anymore? I’m interested in knowing more
Oh, and, what does it mean for IDE support?
Oh, and FWIW I have zero issues with breaking backward compatibility
And, FWIW, I have zero issues with breaking backward comcompatibility
Sorry for the double-post
Tako Schotanus
@quintesse
Hehe, guys, this were just ideas of mine. I don't represent any official plans. Just me and my opinions :-)