Start thinking about post-1.2

[Stephane Epardaud]

Here are some of the things we should discuss on the roadmap for the post 1.2 phase. None of them are set in stone and most are frankly just my own opinion and just putting it out there for discussion.

Short term:

- OBR move of the dist repos into a single repo. I will give all the parts I was responsible for to Tako, it makes no sense to split the work on something that must be done atomically. This is the very first thing we should do, so it has top priority.

- Figuring out a build procedure for a 1.2.1 release. Given that we want to make backward-compatible point releases every so often, we should start making sure we know how to. That involves starting to branch the 1.2 release and making a testing 1.2.1 release to make sure it's possible and all goes to plan. Which means that binaries produced for 1.2.0 must work as-is on a 1.2.1 distrib and vice-versa. I expect problems with the language module or distrib dependencies for user modules that depend on them, which may lead to situations where a user module compiled for 1.2.1 will depend on ceylon.language/1.2.1 and ceylon.collection/1.2.0 which depends on ceylon.language/1.2.0. We need to figure this out ASAP. I think this can go on in parallel to the OBR work, because most of the outcome will be knowledge rather than code. I'd volunteer Tom if he's up for it ;)

- Planning the face2face where we'll discuss all this, but mostly just celebrate.

Mid term:

- Android, which means discussing Java 8 as well, and the possibility of producing one binary for J7 and one for J8. I'll attack Android myself.

- Java 8. We still need a story for being able to pass our lambdas to Java 8, and possibly back as well. We also need to figure out if we can/want to turn our Callable into J8 lambdas, and our mixins into J8 mixins. As a starting point we should rebase on Java 8 javac, once we've checked that it does not _depend_ on J8 (which would be logical given that it need to be bootstrapped on J7). That will still make us work on J7 while giving us the means to output/consume proper J8 jars. I can deal with the rebasing, once the OBR is done. I plan to try the J8 git export that David Lloyd maintains on GitHub, that will save me the hassle of remembering how to use that non-git CVS they use whose name I can't remember.

- Integration with things like Hibernate. We need ORM to understand how to deal with Ceylon platform types, such as our own boxing types (Integer) and collections. Basic ORM support works, and we can plug in custom converters for most things except IDs (which we need to fix by extending Hibernate. JPA says we can't have converters for ID but Steve from Hibernate team was open to relaxing this restriction in JPA, possibly leading to a change in the next spec to allow it if we can convince them), and collections (all collection handling seems hard-coded in Hibernate (by Gavin at the time, haha) to JDK collections, so even if we can add custom converters for collections they still have to be JDK collections. again we will have to extend Hibernate). Frankly this is something I'd love to delegate to someone. I'll try to find someone unless one of you begs to take it.

- OpenShift v3 cartridge: we need to make a v3 cartridge, which is based on Docker. Aslak has made docker plugins for Ceylon in the past, they can probably be used to bootstrap it.

- Herd: I need to do a new release of Herd to fix high-priority issues. This should take a week max, but will mean URLs are going to change. I expect the repo will stay where it is (because tools are using it), but the logged-in UI will move to herd.ceylon-lang.org.

- Blogging. I plan to blog about the OpenShift cartridge, the Hibernate/Cayla demo I wrote for last Devoxx.fr, the tagging of the language module ceylondoc, the Maven overrides and flags, and whatever other thing I can think of. I think we should throttle it to one post per week to keep people coming back regularly. I think we should have a queue where we put our titles and reserve weeks so we don't all blog at the same time and leave weeks empty. I suggest you all contribute and find any reason to blog. Like the IDE new features, or the Ceylon CLI plugin support, or native, serialisation, IntelliJ plugin. We MUST use the blog more regularly, it drives a massive number of people to our site.

Eclipse IDE: I still want better incremental editing, especially for package/module descriptors ;) I also want it to be able to push to Herd more easily, it should be a breeze. Other than that it's already pretty rad. We should seriously consider integration with JBoss Tools, as we would benefit from every JBoss Tools IDE user having Ceylon already installed. The JBoss Tools people can help with this but I expect someone (David) would have to take the lead, if only to make sure it happens.

IntelliJ IDE: obviously that's going to be the main focus of the IDE team.

- Push for Linux distributions to ship Ceylon deb/rpm. It's been long enough, we should lobby for their integration in Ubuntu/Debian/Fedora/RHEL. It should not be a lot of work. We could delegate the RH part to some RH people we know who have helped in the past.

Unicorn term:

- CI (waiting for OBR)

- Performance benchmark suite, to tell us when we improve, when we lose, which is a pre-requirement for any perf work we do. We can't go and continue attacking perf in the dark where any subsequent work can invalidate what we spend weeks fixing.

- Perf improvements in compile/run/IDE time. NOT before we have a bench suite.

I reserve the right to add things to that list later ;)

Of course all of this is only out there for discussion.

--

Stéphane Épardaud

[Gavin King]

On Fri, Oct 30, 2015 at 10:55 AM, Stephane Epardaud
<stephane...@gmail.com> wrote:

> - Android, which means discussing Java 8 as well, and the possibility of
> producing one binary for J7 and one for J8. I'll attack Android myself.

One things you need to think very hard about here, upfront:

1. The notion of a "client" language module which is just
ceylon.language with no ceylon.language.meta. Either the language
module gets split into two modules, or there is a "1.2.0-client"
version of the language module which is missing some bits. This is
relevant to both Android and to browser-based JS clients.

2. Self-bootstrapping .cars. I have long thought that classes should
be responsible for bootstrapping whatever static information is
necessary for their correct functioning via a static initializer. I
think the current approach of having to call an API to initialize the
module is only going to make more work for us on the integration
front, and make stuff like Android support more difficult.

> - Java 8. We still need a story for being able to pass our lambdas to Java
> 8, and possibly back as well. We also need to figure out if we can/want to
> turn our Callable into J8 lambdas, and our mixins into J8 mixins. As a
> starting point we should rebase on Java 8 javac, once we've checked that it
> does not _depend_ on J8 (which would be logical given that it need to be
> bootstrapped on J7). That will still make us work on J7 while giving us the
> means to output/consume proper J8 jars. I can deal with the rebasing, once
> the OBR is done. I plan to try the J8 git export that David Lloyd maintains
> on GitHub, that will save me the hassle of remembering how to use that
> non-git CVS they use whose name I can't remember.

I don't think we should start on this work until later next year. We
need to take a break and spend some type developing example apps, etc.

> - Integration with things like Hibernate. We need ORM to understand how to
> deal with Ceylon platform types, such as our own boxing types (Integer) and
> collections. Basic ORM support works, and we can plug in custom converters
> for most things except IDs (which we need to fix by extending Hibernate. JPA
> says we can't have converters for ID but Steve from Hibernate team was open
> to relaxing this restriction in JPA, possibly leading to a change in the
> next spec to allow it if we can convince them), and collections (all
> collection handling seems hard-coded in Hibernate (by Gavin at the time,
> haha) to JDK collections, so even if we can add custom converters for
> collections they still have to be JDK collections. again we will have to
> extend Hibernate).

Actually no. Steve and I discussed this here in Barcelona a couple of
weeks ago, and it turns out Collections are abstracted in Hibernate
(by me, many years ago). And so basic support for Ceylon is something
I can build pretty quickly.

Now, if we wanted to have our own set of ORM mapping annotations, that
would be something that is a whole lot more work, since apparently
building a new Binder for Hibernate is a famously difficult thing to
do. But it's not clear we really desperately need such a thing at this
stage. The Java annotations will work perfectly fine.



--
Gavin King
ga...@ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org

[Stephane Epardaud]

On 30 October 2015 at 12:17, Gavin King <gavin...@gmail.com> wrote:

1. The notion of a "client" language module which is just
ceylon.language with no ceylon.language.meta. Either the language
module gets split into two modules, or there is a "1.2.0-client"
version of the language module which is missing some bits. This is
relevant to both Android and to browser-based JS clients.

Well, yes that means splitting the metamodel from the runtime reified generics.

 

2. Self-bootstrapping .cars. I have long thought that classes should
be responsible for bootstrapping whatever static information is
necessary for their correct functioning via a static initializer. I
think the current approach of having to call an API to initialize the
module is only going to make more work for us on the integration
front, and make stuff like Android support more difficult.

Sure, that's also something I want to try to do.

 

Actually no. Steve and I discussed this here in Barcelona a couple of
weeks ago, and it turns out Collections are abstracted in Hibernate
(by me, many years ago). And so basic support for Ceylon is something
I can build pretty quickly.

I did not find that. At least not with annotation-based Hibernate. The code I found was indeed abstracted but still had to adhere to JDK's List/Map/Set interfaces.

 

Now, if we wanted to have our own set of ORM mapping annotations, that
would be something that is a whole lot more work, since apparently
building a new Binder for Hibernate is a famously difficult thing to
do. But it's not clear we really desperately need such a thing at this
stage. The Java annotations will work perfectly fine.

No, I'd much rather stick to plain old JP annotations. 

[Gavin King]

On Fri, Oct 30, 2015 at 12:34 PM, Stephane Epardaud
<stephane...@gmail.com> wrote:

> I did not find that. At least not with annotation-based Hibernate. The code
> I found was indeed abstracted but still had to adhere to JDK's List/Map/Set
> interfaces.

Ah, perhaps the JPA annotation Binder is not abstracted. That's
Emmanuel's code so you can blame him :-)

But the actual persistence code *is*.

[Tako Schotanus]

On 30 October 2015 at 10:55, Stephane Epardaud <stephane...@gmail.com> wrote:

- Push for Linux distributions to ship Ceylon deb/rpm. It's been long enough, we should lobby for their integration in Ubuntu/Debian/Fedora/RHEL. It should not be a lot of work. We could delegate the RH part to some RH people we know who have helped in the past

Actually  this *is* a lot of work, I tried it a couple of times now and asked RH (first Mark, then Bob) to find someone to help me.

Then they put me in touch with Marek as *the* RPM expert we have on our team but who never has time to do anything except point out where the documentation is.

The rules for packages are very strict, so none of the things we distribute can go in and have to exist as packages themselves.

Unfortunately we have a couple of things that are not available as packages in RH/Fedora, so it would not only mean making a RPM for Ceylon (not the one we have now, it breaks all kinds of RH/Fedora acceptance rules) but also for the other JARs.

And of course our `maven-support` library is a big no-no (it's a hodgepodge of all kinds of other libraries) so we would have to start using the official components.

And then they didn't want me to use "alternatives" because it was "no good anymore" and told me to use some new system that wasn't complete yet and nobody could tell me how it worked.

You also *have* to be subscribed to a bunch of mailing lists where your RPM will be vetted for inclusion. But for that you need a "mentor". Etc etc

In the end it would make you a full-fledged contributor when the thing I was hoping for was somebody who already *is* a contributor willing to help out in creating an official RPM. I'm sure that once we have it keeping it up-to-date will be easy enough.

So that's when I gave up.

If we can find someone who's actually willing to make their hands dirty and make a valid RPM I'd be more than willing to help out.

-Tako

[Stephane Epardaud]

Damn.

--
You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-dev+...@googlegroups.com.
To post to this group, send email to ceylo...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAOJRyvpm-FCK1ufUuCt4zE073-yydCQ4oGyohmOBRpZWJMPuTQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Stéphane Épardaud

[Lucas Werkmeister]

Re Blogging: I agree, more blogging would be good. For organization, I’d suggest creating a Github issue for a topic you want to blog about, and eventually a Pull Request that adds the actual blog and closes that issue. This also provides a good place for discussion on the post.

Re Linux: I plan on creating an AUR package once OBR is done.

[Enrique]

Regarding Linux distros: Honestly I think it's more important to integrate with things like homebrew (already done) and sdkman (underway). If sdkman is included in distros (I have no idea if it is), it can be used to install all sorts of JVM-related stuff, including Ceylon.