[ceylon-dev] ceylon.html5

[Tomáš Hradec]

Hi,

I would like to introduce module ceylon.html5, it is built on base of
experiences from module ceylon.html and try to improve some areas, mainly

- type hierarchy is more close to html5 and content restrictions are based
on categories, as defined in specification (discussed in #358)
- support for lazy evaluation for attribute values and element content
(discussed in context of cayla templating engine)

I recommend to start with documentation http://thradec.github.io/index.html,
the sources are here https://github.com/thradec/ceylon.html5.

The module doesn't contain all elements yet, because I would like to
process your feedback first.

Thanks for your comments
Tomas

[Gavin King]

Awesome!!

Post by Tomáš Hradec
Hi,
I would like to introduce module ceylon.html5, it is built on base of
experiences from module ceylon.html and try to improve some areas, mainly
- type hierarchy is more close to html5 and content restrictions are based
on categories, as defined in specification (discussed in #358)
- support for lazy evaluation for attribute values and element content
(discussed in context of cayla templating engine)
I recommend to start with documentation http://thradec.github.io/index.html,
the sources are here https://github.com/thradec/ceylon.html5.
The module doesn't contain all elements yet, because I would like to process
your feedback first.
Thanks for your comments
Tomas
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Gavin King]

My initial impression is that it looks really fantastic. And very
well-documented which matters here.

Post by Tomáš Hradec
Hi,
I would like to introduce module ceylon.html5, it is built on base of
experiences from module ceylon.html and try to improve some areas, mainly
- type hierarchy is more close to html5 and content restrictions are based
on categories, as defined in specification (discussed in #358)
- support for lazy evaluation for attribute values and element content
(discussed in context of cayla templating engine)
I recommend to start with documentation http://thradec.github.io/index.html,
the sources are here https://github.com/thradec/ceylon.html5.
The module doesn't contain all elements yet, because I would like to process
your feedback first.
Thanks for your comments
Tomas
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tako Schotanus]

Looks really good Tomas.

I have perhaps one questions/suggestion:

why not take this code as the successor for `ceylon.html`?
Any reason why we would want to continue maintaining `ceylon.html` (besides
compatibility)?




-Tako

Post by Gavin King
My initial impression is that it looks really fantastic. And very
well-documented which matters here.

Post by Tomáš Hradec
Hi,
I would like to introduce module ceylon.html5, it is built on base of
experiences from module ceylon.html and try to improve some areas, mainly
- type hierarchy is more close to html5 and content restrictions are

based

Post by Tomáš Hradec
on categories, as defined in specification (discussed in #358)
- support for lazy evaluation for attribute values and element content
(discussed in context of cayla templating engine)
I recommend to start with documentation

http://thradec.github.io/index.html,

Post by Tomáš Hradec
the sources are here https://github.com/thradec/ceylon.html5.
The module doesn't contain all elements yet, because I would like to

process

Post by Tomáš Hradec
your feedback first.
Thanks for your comments
Tomas
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit

https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com
.

Post by Tomáš Hradec
For more options, visit https://groups.google.com/d/optout.

--
Gavin King
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/CAP7PoCf%2B6dmCWgXN7VKY3weJ3aB1z%3D1Z-tK086iT-w-Ch1bDFw%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.

[Gavin King]

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

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

[David Festal]

+1

By the way, is there any reason why
https://github.com/drochetti/ceylon-style had not been continued ?

Post by Gavin King

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

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

[Tomáš Hradec]

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

I agree, just it is not backward compatible (even the migration should be
pretty straightforward) so I wanted permission from others.

Post by Tako Schotanus
+1
By the way, is there any reason why
https://github.com/drochetti/ceylon-style had not been continued ?

Post by Gavin King

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

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

--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/1456845686.2071.2.camel%40gmail.com
.
For more options, visit https://groups.google.com/d/optout.

[Tomáš Hradec]

Post by Gavin King
My initial impression is that it looks really fantastic.

Thanks.

Post by Gavin King

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

I agree, just it is not backward compatible (even the migration should be
pretty straightforward) so I wanted permission from others.

Post by Tako Schotanus
+1
By the way, is there any reason why
https://github.com/drochetti/ceylon-style had not been continued ?

Post by Gavin King

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

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

--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/1456845686.2071.2.camel%40gmail.com
.
For more options, visit https://groups.google.com/d/optout.

[Tomáš Hradec]

Post by David Festal
By the way, is there any reason why

https://github.com/drochetti/ceylon-style had not been continued ?

No idea, probably because Daniel stop care about these pet projects.

Post by David Festal

Post by Gavin King
My initial impression is that it looks really fantastic.

Thanks.

Post by Gavin King

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

I agree, just it is not backward compatible (even the migration should be
pretty straightforward) so I wanted permission from others.

Post by Tako Schotanus
+1
By the way, is there any reason why
https://github.com/drochetti/ceylon-style had not been continued ?

Post by Gavin King

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

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

--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/1456845686.2071.2.camel%40gmail.com
.
For more options, visit https://groups.google.com/d/optout.

[Tako Schotanus]

But do you see any use for it? As a companion to `ceylon.html`?
So the `style` attribute could for example be a reference to a `Style`
class (or `Style|String`).

-Tako

Post by David Festal

Post by David Festal
By the way, is there any reason why

https://github.com/drochetti/ceylon-style had not been continued ?
No idea, probably because Daniel stop care about these pet projects.

Post by David Festal

Post by Gavin King
My initial impression is that it looks really fantastic.

Thanks.

Post by Gavin King

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

I agree, just it is not backward compatible (even the migration should
be pretty straightforward) so I wanted permission from others.

Post by Tako Schotanus
+1
By the way, is there any reason why
https://github.com/drochetti/ceylon-style had not been continued ?

Post by Gavin King

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

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

--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/1456845686.2071.2.camel%40gmail.com
.
For more options, visit https://groups.google.com/d/optout.

--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDS1%2BMdnAi6AEOYP1xKVo-3qW5q6VDY8LS%3DvYRoZwzUZRQ%40mail.gmail.com
<https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDS1%2BMdnAi6AEOYP1xKVo-3qW5q6VDY8LS%3DvYRoZwzUZRQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Tako Schotanus]

To me it seems like a good idea.

Like I mentioned before, we'd need to figure out what version to give it.
Right now we always go with the Ceylon version, but to me this warrants a
2.0 version.

(A possible rule might be that each time we need to bring out new SDK
modules because of changes to Ceylon we increase the SDK modules by the
same amount as Ceylon, so if Ceylon goes from 1.2.1 to 1.2.2 the SDK
modules go from X.Y.Z to X.Y.(Z+1) and if Ceylon goes from 1.2.3 to 1.3
then the SDK modules go from X.Y.Z to X.(Y+1).0. It's more work af course,
but it could work)

-Tako

Post by Tomáš Hradec

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

I agree, just it is not backward compatible (even the migration should be
pretty straightforward) so I wanted permission from others.

Post by Tako Schotanus
+1
By the way, is there any reason why
https://github.com/drochetti/ceylon-style had not been continued ?

Post by Gavin King

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

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

--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/1456845686.2071.2.camel%40gmail.com
.
For more options, visit https://groups.google.com/d/optout.

--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDQsBYmpMkknaaRwhQK7NO5SBrRVSkWNFe8kuYzi0oBEwQ%40mail.gmail.com
<https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDQsBYmpMkknaaRwhQK7NO5SBrRVSkWNFe8kuYzi0oBEwQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Tako Schotanus]

NB: this does show, to me at least, that we can't just go on endlessly
giving all the SDK modules the same version as Ceylon.
There will be times, like this, that an SDK module will make a jump in
features etc, that would warrant a 2.0, 3.0, etc version




-Tako

Post by Gavin King

Post by Tako Schotanus
why not take this code as the successor for `ceylon.html`?

+1
--
Gavin King
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/CAP7PoCcUSpLrcgf0HJSFCXVK3MWKPGjn1sYw-G8C%3DH6FMj_v6g%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.

[John Vasileff]

Looks great!

Coincidentally, just yesterday I was just looking at optimizing ceylon.html, since it can be a bit slow for large files (especially on JS). On idea I had was to use classes for attributes, just like elements. So you’d have, roughly, '{Content<PhrasingCategory | SpanAttribute>*} children = []’.

The reasoning for this, is that for each element, there are at least 15 attributes. So, with ceylon.html5, the *minimum* processing of each element includes:

- 15 new instances of Entry in “Element”
- 15 calls to “resolveAttribute”, each involving from 1 to 8 “if (is 
)” tests
- “coalesced” on the result, which iterates at least 15 items
- Additional attribute-type-specific conditions and logic (i.e. allowing String[] for clazz), which could be more efficiently handled polymorphically (similar to the work in resolveAttribute).

There would of course be pros and cons with this api change. But I think performance should be a strong consideration.

My recent testing has been with Lucas’s ColorTrompon project, altered to use ceylon.html. Entire processing of `Iterable.ceylon` (taking the source and outputting html), takes the following amount of time on the JVM on the 10th run:

0.19s using ceylon.html5
0.13s using ceylon.html
0.02s using a StringBuilder

Certainly attribute processing only accounts for a portion of the difference.

John

On Mar 1, 2016, at 9:13 AM, Tomáš Hradec <***@gmail.com<mailto:***@gmail.com>> wrote:

Hi,

I would like to introduce module ceylon.html5, it is built on base of experiences from module ceylon.html and try to improve some areas, mainly

- type hierarchy is more close to html5 and content restrictions are based on categories, as defined in specification (discussed in #358)
- support for lazy evaluation for attribute values and element content (discussed in context of cayla templating engine)

I recommend to start with documentation http://thradec.github.io/index.html, the sources are here https://github.com/thradec/ceylon.html5.

The module doesn't contain all elements yet, because I would like to process your feedback first.

Thanks for your comments
Tomas




--
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<mailto:ceylon-dev+***@googlegroups.com>.
To post to this group, send email to ceylon-***@googlegroups.com<mailto:ceylon-***@googlegroups.com>.
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com<https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

[Tomáš Hradec]

Very good point John. I changed [1] how attributes are stored, so now there
shouldn't be entries which hold null value.

Could you please rerun your test (or better share it anywhere). Thanks.

[1]
https://github.com/thradec/ceylon.html5/commit/ab072c94817f4042686344efb8bcf050408d46ae

T.

Post by John Vasileff
Looks great!
Coincidentally, just yesterday I was just looking at optimizing
ceylon.html, since it can be a bit slow for large files (especially on JS).
On idea I had was to use classes for attributes, just like elements. So
you’d have, roughly, '{Content<PhrasingCategory | SpanAttribute>*} children
= []’.
The reasoning for this, is that for each element, there are at least 15
attributes. So, with ceylon.html5, the *minimum* processing of each element
- 15 new instances of Entry in “Element”
- 15 calls to “resolveAttribute”, each involving from 1 to 8 “if (is 
)”
tests
- “coalesced” on the result, which iterates at least 15 items
- Additional attribute-type-specific conditions and logic (i.e. allowing
String[] for clazz), which could be more efficiently handled
polymorphically (similar to the work in resolveAttribute).
There would of course be pros and cons with this api change. But I think
performance should be a strong consideration.
My recent testing has been with Lucas’s ColorTrompon project, altered to
use ceylon.html. Entire processing of `Iterable.ceylon` (taking the source
and outputting html), takes the following amount of time on the JVM on the
0.19s using ceylon.html5
0.13s using ceylon.html
0.02s using a StringBuilder
Certainly attribute processing only accounts for a portion of the difference.
John
Hi,
I would like to introduce module ceylon.html5, it is built on base of
experiences from module ceylon.html and try to improve some areas, mainly
- type hierarchy is more close to html5 and content restrictions are based
on categories, as defined in specification (discussed in #358)
- support for lazy evaluation for attribute values and element content
(discussed in context of cayla templating engine)
I recommend to start with documentation
http://thradec.github.io/index.html, the sources are here
https://github.com/thradec/ceylon.html5.
The module doesn't contain all elements yet, because I would like to
process your feedback first.
Thanks for your comments
Tomas
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com
<https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/C7113ACF-E365-4852-8C51-1B19E686D452%40vasileff.com
<https://groups.google.com/d/msgid/ceylon-dev/C7113ACF-E365-4852-8C51-1B19E686D452%40vasileff.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Tomáš Hradec]

I'll start to implement the rest of elements (it shouldn't take too much
time) and then I'll replace the original ceylon.html module.

What should be the version? 1.2.2 as the rest of SDK or 2.0.0 or ...

T.

Post by Tomáš Hradec
Very good point John. I changed [1] how attributes are stored, so now
there shouldn't be entries which hold null value.
Could you please rerun your test (or better share it anywhere). Thanks.
[1]
https://github.com/thradec/ceylon.html5/commit/ab072c94817f4042686344efb8bcf050408d46ae
T.

Post by John Vasileff
Looks great!
Coincidentally, just yesterday I was just looking at optimizing
ceylon.html, since it can be a bit slow for large files (especially on JS).
On idea I had was to use classes for attributes, just like elements. So
you’d have, roughly, '{Content<PhrasingCategory | SpanAttribute>*} children
= []’.
The reasoning for this, is that for each element, there are at least 15
attributes. So, with ceylon.html5, the *minimum* processing of each element
- 15 new instances of Entry in “Element”
- 15 calls to “resolveAttribute”, each involving from 1 to 8 “if (is 
)”
tests
- “coalesced” on the result, which iterates at least 15 items
- Additional attribute-type-specific conditions and logic (i.e. allowing
String[] for clazz), which could be more efficiently handled
polymorphically (similar to the work in resolveAttribute).
There would of course be pros and cons with this api change. But I think
performance should be a strong consideration.
My recent testing has been with Lucas’s ColorTrompon project, altered to
use ceylon.html. Entire processing of `Iterable.ceylon` (taking the source
and outputting html), takes the following amount of time on the JVM on the
0.19s using ceylon.html5
0.13s using ceylon.html
0.02s using a StringBuilder
Certainly attribute processing only accounts for a portion of the difference.
John
Hi,
I would like to introduce module ceylon.html5, it is built on base of
experiences from module ceylon.html and try to improve some areas, mainly
- type hierarchy is more close to html5 and content restrictions are
based on categories, as defined in specification (discussed in #358)
- support for lazy evaluation for attribute values and element content
(discussed in context of cayla templating engine)
I recommend to start with documentation
http://thradec.github.io/index.html, the sources are here
https://github.com/thradec/ceylon.html5.
The module doesn't contain all elements yet, because I would like to
process your feedback first.
Thanks for your comments
Tomas
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com
<https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/C7113ACF-E365-4852-8C51-1B19E686D452%40vasileff.com
<https://groups.google.com/d/msgid/ceylon-dev/C7113ACF-E365-4852-8C51-1B19E686D452%40vasileff.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Tako Schotanus]

Post by Tomáš Hradec
I'll start to implement the rest of elements (it shouldn't take too much
time) and then I'll replace the original ceylon.html module.
What should be the version? 1.2.2 as the rest of SDK or 2.0.0 or ...

I tend towards "2.0.0", but I think this is something where Stephane and
Tom should weigh in on as well.

Post by Tomáš Hradec
T.

Post by Tomáš Hradec
Very good point John. I changed [1] how attributes are stored, so now
there shouldn't be entries which hold null value.
Could you please rerun your test (or better share it anywhere). Thanks.
[1]
https://github.com/thradec/ceylon.html5/commit/ab072c94817f4042686344efb8bcf050408d46ae
T.

Post by John Vasileff
Looks great!
Coincidentally, just yesterday I was just looking at optimizing
ceylon.html, since it can be a bit slow for large files (especially on JS).
On idea I had was to use classes for attributes, just like elements. So
you’d have, roughly, '{Content<PhrasingCategory | SpanAttribute>*} children
= []’.
The reasoning for this, is that for each element, there are at least 15
attributes. So, with ceylon.html5, the *minimum* processing of each element
- 15 new instances of Entry in “Element”
- 15 calls to “resolveAttribute”, each involving from 1 to 8 “if (is 
)”
tests
- “coalesced” on the result, which iterates at least 15 items
- Additional attribute-type-specific conditions and logic (i.e. allowing
String[] for clazz), which could be more efficiently handled
polymorphically (similar to the work in resolveAttribute).
There would of course be pros and cons with this api change. But I think
performance should be a strong consideration.
My recent testing has been with Lucas’s ColorTrompon project, altered to
use ceylon.html. Entire processing of `Iterable.ceylon` (taking the source
and outputting html), takes the following amount of time on the JVM on the
0.19s using ceylon.html5
0.13s using ceylon.html
0.02s using a StringBuilder
Certainly attribute processing only accounts for a portion of the difference.
John
Hi,
I would like to introduce module ceylon.html5, it is built on base of
experiences from module ceylon.html and try to improve some areas, mainly
- type hierarchy is more close to html5 and content restrictions are
based on categories, as defined in specification (discussed in #358)
- support for lazy evaluation for attribute values and element content
(discussed in context of cayla templating engine)
I recommend to start with documentation
http://thradec.github.io/index.html, the sources are here
https://github.com/thradec/ceylon.html5.
The module doesn't contain all elements yet, because I would like to
process your feedback first.
Thanks for your comments
Tomas
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com
<https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/C7113ACF-E365-4852-8C51-1B19E686D452%40vasileff.com
<https://groups.google.com/d/msgid/ceylon-dev/C7113ACF-E365-4852-8C51-1B19E686D452%40vasileff.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDQP1g8LPXm2%3Dt-L1nDdoPA%2BVxLTxX%3DhvmRBgV8bptfZNw%40mail.gmail.com
<https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDQP1g8LPXm2%3Dt-L1nDdoPA%2BVxLTxX%3DhvmRBgV8bptfZNw%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Bastien Jansen]

Nice work Tomáš!

I also think that this should replace ceylon.html and use the version 2.0 because it’s a complete rewrite of the module. The only drawback is that it does not show which version of the language it depends on.

I'll start to implement the rest of elements (it shouldn't take too much time) and then I'll replace the original ceylon.html module.
What should be the version? 1.2.2 as the rest of SDK or 2.0.0 or ...
I tend towards "2.0.0", but I think this is something where Stephane and Tom should weigh in on as well.
T.
Very good point John. I changed [1] how attributes are stored, so now there shouldn't be entries which hold null value.
Could you please rerun your test (or better share it anywhere). Thanks.
[1] https://github.com/thradec/ceylon.html5/commit/ab072c94817f4042686344efb8bcf050408d46ae <https://github.com/thradec/ceylon.html5/commit/ab072c94817f4042686344efb8bcf050408d46ae>
T.
Looks great!
Coincidentally, just yesterday I was just looking at optimizing ceylon.html, since it can be a bit slow for large files (especially on JS). On idea I had was to use classes for attributes, just like elements. So you’d have, roughly, '{Content<PhrasingCategory | SpanAttribute>*} children = []’.
- 15 new instances of Entry in “Element”
- 15 calls to “resolveAttribute”, each involving from 1 to 8 “if (is 
)” tests
- “coalesced” on the result, which iterates at least 15 items
- Additional attribute-type-specific conditions and logic (i.e. allowing String[] for clazz), which could be more efficiently handled polymorphically (similar to the work in resolveAttribute).
There would of course be pros and cons with this api change. But I think performance should be a strong consideration.
0.19s using ceylon.html5
0.13s using ceylon.html
0.02s using a StringBuilder
Certainly attribute processing only accounts for a portion of the difference.
John

Post by John Vasileff
Hi,
I would like to introduce module ceylon.html5, it is built on base of experiences from module ceylon.html and try to improve some areas, mainly
- type hierarchy is more close to html5 and content restrictions are based on categories, as defined in specification (discussed in #358)
- support for lazy evaluation for attribute values and element content (discussed in context of cayla templating engine)
I recommend to start with documentation http://thradec.github.io/index.html <http://thradec.github.io/index.html>, the sources are here https://github.com/thradec/ceylon.html5 <https://github.com/thradec/ceylon.html5>.
The module doesn't contain all elements yet, because I would like to process your feedback first.
Thanks for your comments
Tomas
--
You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
Visit this group at https://groups.google.com/group/ceylon-dev <https://groups.google.com/group/ceylon-dev>.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com <https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDTo4N-sdY28ZHy6%2B%2B8nqX08paR-bkWtR4wg_9PYqrt_qA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

--
You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
Visit this group at https://groups.google.com/group/ceylon-dev <https://groups.google.com/group/ceylon-dev>.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/C7113ACF-E365-4852-8C51-1B19E686D452%40vasileff.com <https://groups.google.com/d/msgid/ceylon-dev/C7113ACF-E365-4852-8C51-1B19E686D452%40vasileff.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
Visit this group at https://groups.google.com/group/ceylon-dev <https://groups.google.com/group/ceylon-dev>.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDQP1g8LPXm2%3Dt-L1nDdoPA%2BVxLTxX%3DhvmRBgV8bptfZNw%40mail.gmail.com <https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDQP1g8LPXm2%3Dt-L1nDdoPA%2BVxLTxX%3DhvmRBgV8bptfZNw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
Visit this group at https://groups.google.com/group/ceylon-dev <https://groups.google.com/group/ceylon-dev>.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAOJRyvqX9%3D5EO3Cx83xu_31hjDDO4HodkpGJjAUxNTxw4pQLPw%40mail.gmail.com <https://groups.google.com/d/msgid/ceylon-dev/CAOJRyvqX9%3D5EO3Cx83xu_31hjDDO4HodkpGJjAUxNTxw4pQLPw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Tako Schotanus]

Post by Bastien Jansen
The only drawback is that it does not show which version of the language
it depends on.

Although I understand why you say that I would reply by saying "isn't that
true for most modules?".
I fact I think the SDK modules are "weird" in this way, following the
language module versions.

-Tako

[John Vasileff]

Should there be an issue for the discussion on sdk module versioning?

In theory I really like the idea of sdk module versions being fully independent, but in practice this will make it much more difficult to add or upgrade dependencies. This can already be time consuming since versions must be listed in each module.ceylon, and would be much more so without being able to search&replace, and if you have to use Herd to determine the correct version for each dependency. Autocomplete in the IDE helps in some cases, but is not a general solution.

On Mar 1, 2016, at 3:43 PM, Tako Schotanus <***@codejive.org<mailto:***@codejive.org>> wrote:


On Tue, Mar 1, 2016 at 9:32 PM, Bastien Jansen <***@gmail.com<mailto:***@gmail.com>> wrote:
The only drawback is that it does not show which version of the language it depends on.

Although I understand why you say that I would reply by saying "isn't that true for most modules?".
I fact I think the SDK modules are "weird" in this way, following the language module versions.

-Tako

--
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<mailto:ceylon-dev+***@googlegroups.com>.
To post to this group, send email to ceylon-***@googlegroups.com<mailto:ceylon-***@googlegroups.com>.
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAOJRyvo8p%3Dq6EVwFiMv0PtMy0%2BVn4fCEsuqZDpgBEquK58-Bcw%40mail.gmail.com<https://groups.google.com/d/msgid/ceylon-dev/CAOJRyvo8p%3Dq6EVwFiMv0PtMy0%2BVn4fCEsuqZDpgBEquK58-Bcw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

[Tomáš Hradec]

About SDK versioning, I share same concerns as John. In theory it is good
to have them independent, but in real live it can be pain.

Post by John Vasileff
Should there be an issue for the discussion on sdk module versioning?
In theory I really like the idea of sdk module versions being fully
independent, but in practice this will make it much more difficult to add
or upgrade dependencies. This can already be time consuming since versions
must be listed in each module.ceylon, and would be much more so without
being able to search&replace, and if you have to use Herd to determine the
correct version for each dependency. Autocomplete in the IDE helps in some
cases, but is not a general solution.

Post by Bastien Jansen
The only drawback is that it does not show which version of the language it depends on.

Although I understand why you say that I would reply by saying "isn't that
true for most modules?".
I fact I think the SDK modules are "weird" in this way, following the
language module versions.
-Tako
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/CAOJRyvo8p%3Dq6EVwFiMv0PtMy0%2BVn4fCEsuqZDpgBEquK58-Bcw%40mail.gmail.com
<https://groups.google.com/d/msgid/ceylon-dev/CAOJRyvo8p%3Dq6EVwFiMv0PtMy0%2BVn4fCEsuqZDpgBEquK58-Bcw%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/EFDA1D08-2F4B-4793-A8CB-0CFD971B6EB2%40vasileff.com
<https://groups.google.com/d/msgid/ceylon-dev/EFDA1D08-2F4B-4793-A8CB-0CFD971B6EB2%40vasileff.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Tako Schotanus]

Post by John Vasileff
Should there be an issue for the discussion on sdk module versioning?

Indeed:

https://github.com/ceylon/ceylon-sdk/issues/520

Let's take it there.


-Tako

[Tomáš Hradec]

Post by Tomáš Hradec
Very good point John. I changed [1] how attributes are stored, so now
there shouldn't be entries which hold null value.
Could you please rerun your test (or better share it anywhere). Thanks.
[1]
https://github.com/thradec/ceylon.html5/commit/ab072c94817f4042686344efb8bcf050408d46ae

I did basic measurement and for repetitive creation and rendering of HTML
document with aprox. 8000 characters the total time is about 50% better.

[Tomáš Hradec]

FYI

I finished missing tags and replaced the original sdk module (as agreed
before). I didn't change version, because there is ongoing discussion #520
without any conclusion yet.

https://github.com/ceylon/ceylon-sdk/commit/7fd0bc1e67d4199ca30eb107b93785430d810b20

Post by Tomáš Hradec
Very good point John. I changed [1] how attributes are stored, so now

Post by Tomáš Hradec
there shouldn't be entries which hold null value.
Could you please rerun your test (or better share it anywhere). Thanks.
[1]
https://github.com/thradec/ceylon.html5/commit/ab072c94817f4042686344efb8bcf050408d46ae

I did basic measurement and for repetitive creation and rendering of HTML
document with aprox. 8000 characters the total time is about 50% better.

[John Vasileff]

I haven’t had time to test yet, but that sounds like a nice improvement.

I was actually raising the possibility of going a step further, and making *each* attribute a class, so the caller would pass in just what is needed instead of each Element having to check for the presence of each attribute. But that would arguably make the api worse, and I haven’t tried it yet. But what does seem to be a problem, is that at least with the original ceylon.html and the initial ceylon.html5, my test on javascript took forever, like 20s. I’m not sure how much this can be optimized, or if it’s just inevitable with JS’s slowness.

John

On Mar 2, 2016, at 10:56 AM, Tomáš Hradec <***@gmail.com<mailto:***@gmail.com>> wrote:

Very good point John. I changed [1] how attributes are stored, so now there shouldn't be entries which hold null value.

Could you please rerun your test (or better share it anywhere). Thanks.

[1] https://github.com/thradec/ceylon.html5/commit/ab072c94817f4042686344efb8bcf050408d46ae

I did basic measurement and for repetitive creation and rendering of HTML document with aprox. 8000 characters the total time is about 50% better.



--
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<mailto:ceylon-dev+***@googlegroups.com>.
To post to this group, send email to ceylon-***@googlegroups.com<mailto:ceylon-***@googlegroups.com>.
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDQJkedWx_-YKwaMQ36hooavBHQpzuAHGDbjZmLT0FudbA%40mail.gmail.com<https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDQJkedWx_-YKwaMQ36hooavBHQpzuAHGDbjZmLT0FudbA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

[Tomáš Hradec]

John, can you share your test, so I could look at it.

T.

Post by John Vasileff
I haven’t had time to test yet, but that sounds like a nice improvement.
I was actually raising the possibility of going a step further, and making
*each* attribute a class, so the caller would pass in just what is needed
instead of each Element having to check for the presence of each attribute.
But that would arguably make the api worse, and I haven’t tried it yet. But
what does seem to be a problem, is that at least with the original
ceylon.html and the initial ceylon.html5, my test on javascript took
forever, like 20s. I’m not sure how much this can be optimized, or if it’s
just inevitable with JS’s slowness.
John
Very good point John. I changed [1] how attributes are stored, so now

Post by Tomáš Hradec
there shouldn't be entries which hold null value.
Could you please rerun your test (or better share it anywhere). Thanks.
[1]
https://github.com/thradec/ceylon.html5/commit/ab072c94817f4042686344efb8bcf050408d46ae

I did basic measurement and for repetitive creation and rendering of HTML
document with aprox. 8000 characters the total time is about 50% better.
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDQJkedWx_-YKwaMQ36hooavBHQpzuAHGDbjZmLT0FudbA%40mail.gmail.com
<https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDQJkedWx_-YKwaMQ36hooavBHQpzuAHGDbjZmLT0FudbA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
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
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ceylon-dev/11CA5244-DC26-4162-947D-B2BF3C77125D%40vasileff.com
<https://groups.google.com/d/msgid/ceylon-dev/11CA5244-DC26-4162-947D-B2BF3C77125D%40vasileff.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[John Vasileff]

Tomas, I finally posted the test code at https://github.com/jvasileff/ceylon.parser/tree/topic-benchmark-ceylon-html . This is a fork of Lucas’s ceylon.parser module.

In the run() function, you can use 'colorTrompon2’ to test string concatenation (instead of ceylon.html).

With ceylon.html, the JVM and Dart backends both run in under 1s for the first iteration, and 20s for JS. The JVM gets much faster after warmup.

With string concatenation, JVM and Dart run in 0.2s and 0.1s, and for JS, 1s. After warmup, jVM and Dart are both close to 0.01s.

John

p.s. There’s a dependency on 'ceylon.ast/1.2.2’ that can be ignored if you compile only `ceylon.lexer.core`.

On Mar 7, 2016, at 2:12 PM, Tomáš Hradec <***@gmail.com<mailto:***@gmail.com>> wrote:

John, can you share your test, so I could look at it.

T.

2016-03-07 20:06 GMT+01:00 John Vasileff <***@vasileff.com<mailto:***@vasileff.com>>:
I haven’t had time to test yet, but that sounds like a nice improvement.

I was actually raising the possibility of going a step further, and making *each* attribute a class, so the caller would pass in just what is needed instead of each Element having to check for the presence of each attribute. But that would arguably make the api worse, and I haven’t tried it yet. But what does seem to be a problem, is that at least with the original ceylon.html and the initial ceylon.html5, my test on javascript took forever, like 20s. I’m not sure how much this can be optimized, or if it’s just inevitable with JS’s slowness.

John

On Mar 2, 2016, at 10:56 AM, Tomáš Hradec <***@gmail.com<mailto:***@gmail.com>> wrote:

Very good point John. I changed [1] how attributes are stored, so now there shouldn't be entries which hold null value.

Could you please rerun your test (or better share it anywhere). Thanks.

[1] https://github.com/thradec/ceylon.html5/commit/ab072c94817f4042686344efb8bcf050408d46ae

I did basic measurement and for repetitive creation and rendering of HTML document with aprox. 8000 characters the total time is about 50% better.



--
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<mailto:ceylon-dev+***@googlegroups.com>.
To post to this group, send email to ceylon-***@googlegroups.com<mailto:ceylon-***@googlegroups.com>.
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDQJkedWx_-YKwaMQ36hooavBHQpzuAHGDbjZmLT0FudbA%40mail.gmail.com<https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDQJkedWx_-YKwaMQ36hooavBHQpzuAHGDbjZmLT0FudbA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.


--
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<mailto:ceylon-dev+***@googlegroups.com>.
To post to this group, send email to ceylon-***@googlegroups.com<mailto:ceylon-***@googlegroups.com>.
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/11CA5244-DC26-4162-947D-B2BF3C77125D%40vasileff.com<https://groups.google.com/d/msgid/ceylon-dev/11CA5244-DC26-4162-947D-B2BF3C77125D%40vasileff.com?utm_medium=email&utm_source=footer>.

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


--
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<mailto:ceylon-dev+***@googlegroups.com>.
To post to this group, send email to ceylon-***@googlegroups.com<mailto:ceylon-***@googlegroups.com>.
Visit this group at https://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDSBHixmwPkj_ZdiD%3DWhu%2BK%3DhhRPaBnGaGT6U2Qy6BVYFQ%40mail.gmail.com<https://groups.google.com/d/msgid/ceylon-dev/CAF_jaDSBHixmwPkj_ZdiD%3DWhu%2BK%3DhhRPaBnGaGT6U2Qy6BVYFQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

[Tomáš Hradec]

Thanks John,

just my update, unfortunately I wasn't able to profile the node.js
execution (Enrique, if you know how to do it, please let me know), but by
me measurements, the escaping takes around 12s from total time (20s), so
I'll look how to reduce it.

T.

[Enrique]

The problem is most likely a native String method.

The easiest way to profile for node is the classic way:

value t0=system.milliseconds;
//do stuff
value t1=system.milliseconds;
print(t1-t0);

Post by Tomáš Hradec
Thanks John,
just my update, unfortunately I wasn't able to profile the node.js
execution (Enrique, if you know how to do it, please let me know), but by
me measurements, the escaping takes around 12s from total time (20s), so
I'll look how to reduce it.
T.