What's the best route to request new haXe features?

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: What's the best route to request new haXe features?

Simon Krajewski
We have to keep apart static/dynamic libraries on the one hand and
distribution/usage on the other. Let me summarize:

1. Distribution of dynamic libraries makes no sense due to the reasons
you mentioned (one runtime per platform per compiler switch etc.).

2. Distribution of static libraries (static in terms of the haxe
compiler) is currently haxelib. Extension to some precompiled format
makes sense for closed source purposes, but has the problem of
conditional compilation not working on expression level.

3. Usage of static libraries is compile-time linking of haxelib libs,
which is currently not really linking but including an additional class
path. If a precompiled distribution format existed, the compilation of
the lib could be replaced with that, either from a library or from a
previous compilation step if it's still up to date. The latter is
basically just caching and seems to be tackled by Nicolas already. The
former is easy as well, but the underlying problem of 2. is not.

4. Usage of dynamic libraries is two-fold. Creation at compile time is
possible because the compiler has the target platform context, so it
would know which format (swf, js, php, ndll, dll etc.) to create. The
runtime linking itself has varying difficulty per platform, but can be
done as well (js and php are mere file inclusions, dll and ndll are just
put next to the executable, swf can be loaded into another swf etc.).
Does it make sense? I don't really know.

Regards
Simon

Am 22.12.2011 10:24, schrieb Juraj Kirchheim:

> Unfortunately, conditional compilation is only incidentally about targets.
>
> You'd have to compile for every target and for almost any combination
> of compiler switches and custom switches you encounter (such as -D
> spod_rtti etc.). You could then in theory attempt to throw out
> duplication (otherwise this explodes exponentially), but if speed is
> what this is about, I doubt this is the right way to go :)
>
> On Thu, Dec 22, 2011 at 12:54 AM, Baluta Cristian
> <[hidden email]>  wrote:
>> you probably want all the targets compiled and zipped, then we could invent
>> a new extension like hwc from swc. makes no sense to me, haxe is too fast to
>> count.
>>
>>
>> On Wed, Dec 21, 2011 at 11:30 PM, Raoul Duke<[hidden email]>  wrote:
>>>
>>> On Wed, Dec 21, 2011 at 3:20 PM, Juraj Kirchheim
>>>> Still the question remains: Why exactly you would need that?
>>>
>>> because otherwise things can get arbitrarily slow?
>>>
>>> i know haxe compilation is relatively fast for *some* targets, but it
>>> can be painful for others at first e.g. generating the c++ files.
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>>
>>
>>
>> --
>> Băluță Cristian
>> http://ralcr.com
>> http://imagin.ro
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

RE: What's the best route to request new haXe features?

David Arno
In reply to this post by Juraj Kirchheim
There seems to be a degree of confusion over what I was requesting. As Juraj points out, compiling to target libraries would not be practical, due to all of the different compiler switch combinations that would need to be supported.

What I was describing, and what I honestly thought ought to be self-evident, is a library of partially compiled haXe code. Not a SWF, C++, PHP or whatever code, just the haXe code before any targets get involved. Assuming the compiler acts in a normal fashion, it will presumably have a lexical analyser, token parser and parser tree/graph generator. The parser tree then presumably gets used to generate target-specific output. Therefore saving the parser tree as a "library" both removes the need to distribute source code with a library and would speed up compilation.

I appreciate the parser is fast compared with the snail-paced mxmlc compiler. However I did a test to get an idea of just what sort of overhead compiling from source every time with a haXe version of the Flex SDK would be. As Flex is around 250,000 lines of code, I generated 10,000 files of 20 lines each, with a main class that referenced them all. I ran the whole lot through the compiler. First I targeted neko and the compiler fell over with a stack overflow. I then targeted AS3 and the haXe compiler took between 100 and 110 seconds to compile everything over 10 test runs.

Obviously trying to judge how representative of compile times for Flex my test would be is difficult. Flex consists of far fewer classes, but many are huge (5000+ lines) and there is lots of inheritance between classes. It seems fair to assume that recompiling the haXe Flex library source files every time would add many seconds, even tens of seconds, to the compilation time though. If that time can be drastically reduced through the use of a haXe library, then haXe libraries are clearly a long overdue feature.

Maybe the core haXe team aren't interested in the language being used for large Flex-style projects and are happy to keep it as a language that targets smaller projects only. If so, then clearly there is no real need for compiled libraries as the compiler is fast enough to avoid such a requirement. That approach doesn't scale, but if it's only targeting small projects only, then that isn't an issue. It would be useful to know whether this is the case as I can save myself considerable time by abandoning my experiments sooner rather than later if it is.

Regards,
David.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Juraj Kirchheim
Sent: 22 December 2011 09:24
To: The haXe compiler list
Subject: Re: [haXe] What's the best route to request new haXe features?

Unfortunately, conditional compilation is only incidentally about targets.

You'd have to compile for every target and for almost any combination of compiler switches and custom switches you encounter (such as -D spod_rtti etc.). You could then in theory attempt to throw out duplication (otherwise this explodes exponentially), but if speed is what this is about, I doubt this is the right way to go :)

On Thu, Dec 22, 2011 at 12:54 AM, Baluta Cristian <[hidden email]> wrote:

> you probably want all the targets compiled and zipped, then we could
> invent a new extension like hwc from swc. makes no sense to me, haxe
> is too fast to count.
>
>
> On Wed, Dec 21, 2011 at 11:30 PM, Raoul Duke <[hidden email]> wrote:
>>
>> On Wed, Dec 21, 2011 at 3:20 PM, Juraj Kirchheim
>> > Still the question remains: Why exactly you would need that?
>>
>> because otherwise things can get arbitrarily slow?
>>
>> i know haxe compilation is relatively fast for *some* targets, but it
>> can be painful for others at first e.g. generating the c++ files.
>>
>> --
>> haXe - an open source web programming language http://haxe.org
>
>
>
>
> --
> Băluță Cristian
> http://ralcr.com
> http://imagin.ro
>
> --
> haXe - an open source web programming language http://haxe.org

--
haXe - an open source web programming language http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: What's the best route to request new haXe features?

Franco Ponticelli
I don't know about your benchmark but I know that I have a quite impressive (in term of line of codes) project I am working on with hundreds of classes and still my compilation time is stable at around 0.5secs, 0.4 when I turn the cache on.
I think you should try a more realistic case scenario before claiming that without that feature haxe is a "toy".

Franco

On Thursday, December 22, 2011, David Arno <[hidden email]> wrote:
> There seems to be a degree of confusion over what I was requesting. As Juraj points out, compiling to target libraries would not be practical, due to all of the different compiler switch combinations that would need to be supported.
>
> What I was describing, and what I honestly thought ought to be self-evident, is a library of partially compiled haXe code. Not a SWF, C++, PHP or whatever code, just the haXe code before any targets get involved. Assuming the compiler acts in a normal fashion, it will presumably have a lexical analyser, token parser and parser tree/graph generator. The parser tree then presumably gets used to generate target-specific output. Therefore saving the parser tree as a "library" both removes the need to distribute source code with a library and would speed up compilation.
>
> I appreciate the parser is fast compared with the snail-paced mxmlc compiler. However I did a test to get an idea of just what sort of overhead compiling from source every time with a haXe version of the Flex SDK would be. As Flex is around 250,000 lines of code, I generated 10,000 files of 20 lines each, with a main class that referenced them all. I ran the whole lot through the compiler. First I targeted neko and the compiler fell over with a stack overflow. I then targeted AS3 and the haXe compiler took between 100 and 110 seconds to compile everything over 10 test runs.
>
> Obviously trying to judge how representative of compile times for Flex my test would be is difficult. Flex consists of far fewer classes, but many are huge (5000+ lines) and there is lots of inheritance between classes. It seems fair to assume that recompiling the haXe Flex library source files every time would add many seconds, even tens of seconds, to the compilation time though. If that time can be drastically reduced through the use of a haXe library, then haXe libraries are clearly a long overdue feature.
>
> Maybe the core haXe team aren't interested in the language being used for large Flex-style projects and are happy to keep it as a language that targets smaller projects only. If so, then clearly there is no real need for compiled libraries as the compiler is fast enough to avoid such a requirement. That approach doesn't scale, but if it's only targeting small projects only, then that isn't an issue. It would be useful to know whether this is the case as I can save myself considerable time by abandoning my experiments sooner rather than later if it is.
>
> Regards,
> David.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Juraj Kirchheim
> Sent: 22 December 2011 09:24
> To: The haXe compiler list
> Subject: Re: [haXe] What's the best route to request new haXe features?
>
> Unfortunately, conditional compilation is only incidentally about targets.
>
> You'd have to compile for every target and for almost any combination of compiler switches and custom switches you encounter (such as -D spod_rtti etc.). You could then in theory attempt to throw out duplication (otherwise this explodes exponentially), but if speed is what this is about, I doubt this is the right way to go :)
>
> On Thu, Dec 22, 2011 at 12:54 AM, Baluta Cristian <[hidden email]> wrote:
>> you probably want all the targets compiled and zipped, then we could
>> invent a new extension like hwc from swc. makes no sense to me, haxe
>> is too fast to count.
>>
>>
>> On Wed, Dec 21, 2011 at 11:30 PM, Raoul Duke <[hidden email]> wrote:
>>>
>>> On Wed, Dec 21, 2011 at 3:20 PM, Juraj Kirchheim
>>> > Still the question remains: Why exactly you would need that?
>>>
>>> because otherwise things can get arbitrarily slow?
>>>
>>> i know haxe compilation is relatively fast for *some* targets, but it
>>> can be painful for others at first e.g. generating the c++ files.
>>>
>>> --
>>> haXe - an open source web programming language http://haxe.org
>>
>>
>>
>>
>> --
>> Băluță Cristian
>> http://ralcr.com
>> http://imagin.ro
>>
>> --
>> haXe - an open source web programming language http://haxe.org
>
> --
> haXe - an open source web programming language http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: What's the best route to request new haXe features?

Cauê W.
In reply to this post by David Arno
Hi David!

There seems to be a degree of confusion over what I was requesting. As Juraj points out, compiling to target libraries would not be practical, due to all of the different compiler switch combinations that would need to be supported. 

What I was describing, and what I honestly thought ought to be self-evident, is a library of partially compiled haXe code. Not a SWF, C++, PHP or whatever code, just the haXe code before any targets get involved. Assuming the compiler acts in a normal fashion, it will presumably have a lexical analyser, token parser and parser tree/graph generator. The parser tree then presumably gets used to generate target-specific output. Therefore saving the parser tree as a "library" both removes the need to distribute source code with a library and would speed up compilation.

Actually the haxe parser will not parse #if directive blocks that aren't defined, so what you're requesting would also have to remain invariant to compiler switches. 

Obviously trying to judge how representative of compile times for Flex my test would be is difficult. Flex consists of far fewer classes, but many are huge (5000+ lines) and there is lots of inheritance between classes. It seems fair to assume that recompiling the haXe Flex library source files every time would add many seconds, even tens of seconds, to the compilation time though. If that time can be drastically reduced through the use of a haXe library, then haXe libraries are clearly a long overdue feature. 

Maybe the core haXe team aren't interested in the language being used for large Flex-style projects and are happy to keep it as a language that targets smaller projects only. If so, then clearly there is no real need for compiled libraries as the compiler is fast enough to avoid such a requirement. That approach doesn't scale, but if it's only targeting small projects only, then that isn't an issue. It would be useful to know whether this is the case as I can save myself considerable time by abandoning my experiments sooner rather than later if it is.

I appreciate your effort to create big libraries with haXe, and I'm sure this kind of project size is desired to be achieved by haxe. A solution can be developed with the community - and there are lots of solutions that Nicolas has developed in response to requests/problems the community brought - actually very eagerly. So maybe you should just review your tone, and before calling haxe "a toy" and being alarmist about it, try to develop a solution together. I'm pretty sure you won't have to drop what you're doing, and in the end there will be a good way to deal with your case.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

RE: What's the best route to request new haXe features?

David Arno

Surely #if directives are rarely if ever used though, especially in library code? And on those rare occasions they are needed, any such code should be carefully segregated off into a separate library or libraries and referenced strictly via interfaces only. So I don’t see why this should be an issue to be honest.

 

David.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Cauê Waneck
Sent: 22 December 2011 13:05
To: The haXe compiler list
Subject: Re: [haXe] What's the best route to request new haXe features?

 

Hi David!

 

There seems to be a degree of confusion over what I was requesting. As Juraj points out, compiling to target libraries would not be practical, due to all of the different compiler switch combinations that would need to be supported. 


What I was describing, and what I honestly thought ought to be self-evident, is a library of partially compiled haXe code. Not a SWF, C++, PHP or whatever code, just the haXe code before any targets get involved. Assuming the compiler acts in a normal fashion, it will presumably have a lexical analyser, token parser and parser tree/graph generator. The parser tree then presumably gets used to generate target-specific output. Therefore saving the parser tree as a "library" both removes the need to distribute source code with a library and would speed up compilation.

 

Actually the haxe parser will not parse #if directive blocks that aren't defined, so what you're requesting would also have to remain invariant to compiler switches. 


Obviously trying to judge how representative of compile times for Flex my test would be is difficult. Flex consists of far fewer classes, but many are huge (5000+ lines) and there is lots of inheritance between classes. It seems fair to assume that recompiling the haXe Flex library source files every time would add many seconds, even tens of seconds, to the compilation time though. If that time can be drastically reduced through the use of a haXe library, then haXe libraries are clearly a long overdue feature. 


Maybe the core haXe team aren't interested in the language being used for large Flex-style projects and are happy to keep it as a language that targets smaller projects only. If so, then clearly there is no real need for compiled libraries as the compiler is fast enough to avoid such a requirement. That approach doesn't scale, but if it's only targeting small projects only, then that isn't an issue. It would be useful to know whether this is the case as I can save myself considerable time by abandoning my experiments sooner rather than later if it is.

 

I appreciate your effort to create big libraries with haXe, and I'm sure this kind of project size is desired to be achieved by haxe. A solution can be developed with the community - and there are lots of solutions that Nicolas has developed in response to requests/problems the community brought - actually very eagerly. So maybe you should just review your tone, and before calling haxe "a toy" and being alarmist about it, try to develop a solution together. I'm pretty sure you won't have to drop what you're doing, and in the end there will be a good way to deal with your case.


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: What's the best route to request new haXe features?

François Nicaise
In reply to this post by Nicolas Cannasse
Le 22/12/2011 07:08, Nicolas Cannasse a écrit :

> Le 22/12/2011 00:00, David Arno a écrit :
>> Today I have unfortunately uncovered an aspect of haXe that, if true,
>> renders it (at least to my mind) as a toy language, and not something
>> that
>> can be taken seriously.
> To answer your mail question, the best route to request new haXe
> features is to do what you did : post a mail on the mailing list,
> while maybe highlighting more the benefits of what it would bring
> instead of telling you can't use a language that don't have a given
> feature... People on this list have used haXe for years and are happy
> without it.

That's not right, Nicolas ! Not you... I can't believe it !
After all these years, I have struggled to live without HaXe and every
time I tried another language, I haven't been happy.
Once, for a wekk I trid not to use it. I even started to drink a lot (of
water of course) and eat burgers (vegan, of course ). A lot of them...
But I failed miserably. I came back to it.
No, I cannot be happy without it !
Once you've started to use it, you cannot go back and all you wish is
that any other language do the same.
Once you've buttered your slice of bread, you cannot refrain from
chewing it and feel happy.

No, Nicolas...

'People on this list have used haXe for years and are [not] happy
without it' ! ;)

François

> Best,
> Nicolas
>
>
>
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: What's the best route to request new haXe features?

Nicolas Cannasse
In reply to this post by Cauê W.
Le 22/12/2011 14:05, Cauê Waneck a écrit :

> Hi David!
>
>     There seems to be a degree of confusion over what I was requesting.
>     As Juraj points out, compiling to target libraries would not be
>     practical, due to all of the different compiler switch combinations
>     that would need to be supported.
>
>
>     What I was describing, and what I honestly thought ought to be
>     self-evident, is a library of partially compiled haXe code. Not a
>     SWF, C++, PHP or whatever code, just the haXe code before any
>     targets get involved. Assuming the compiler acts in a normal
>     fashion, it will presumably have a lexical analyser, token parser
>     and parser tree/graph generator. The parser tree then presumably
>     gets used to generate target-specific output. Therefore saving the
>     parser tree as a "library" both removes the need to distribute
>     source code with a library and would speed up compilation.
>
>
> Actually the haxe parser will not parse #if directive blocks that aren't
> defined, so what you're requesting would also have to remain invariant
> to compiler switches.

What I'm doing in current compiler cache is to have a cache for each set
of defined variables. We could improve that by having a cache for each
variable actually used in the parsed file, but anyway it works well
enough so far.

However, this does not solve the issue : most (~70%) of the time is
usually spent typing the program. That will convert the parsed AST into
a full type-inferred AST that will then be passed to the code generator.
And caching type-inferred AST is a lot more complex.

Best,
Nicolas






--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: What's the best route to request new haXe features?

Nicolas Cannasse
In reply to this post by François Nicaise
Le 22/12/2011 14:21, François Nicaise a écrit :

> Le 22/12/2011 07:08, Nicolas Cannasse a écrit :
>> Le 22/12/2011 00:00, David Arno a écrit :
>>> Today I have unfortunately uncovered an aspect of haXe that, if true,
>>> renders it (at least to my mind) as a toy language, and not something
>>> that
>>> can be taken seriously.
>> To answer your mail question, the best route to request new haXe
>> features is to do what you did : post a mail on the mailing list,
>> while maybe highlighting more the benefits of what it would bring
>> instead of telling you can't use a language that don't have a given
>> feature... People on this list have used haXe for years and are happy
>> without it.
>
> That's not right, Nicolas ! Not you... I can't believe it !
> After all these years, I have struggled to live without HaXe and every
> time I tried another language, I haven't been happy.
> Once, for a wekk I trid not to use it. I even started to drink a lot (of
> water of course) and eat burgers (vegan, of course ). A lot of them...
> But I failed miserably. I came back to it.
> No, I cannot be happy without it !
> Once you've started to use it, you cannot go back and all you wish is
> that any other language do the same.
> Once you've buttered your slice of bread, you cannot refrain from
> chewing it and feel happy.
>
> No, Nicolas...
>
> 'People on this list have used haXe for years and are [not] happy
> without it' ! ;)

Let me reassure you : "it" in that case was the given feature proposal,
not the language itself ;) I'm myself not happy when I have to write
something else than haXe. Hopefully it rarely happens ;)

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
12